diff options
author | Peter Burgess <pete.burgess@isode.com> | 2018-07-24 15:43:55 (GMT) |
---|---|---|
committer | Kevin Smith <kevin.smith@isode.com> | 2018-07-26 13:43:37 (GMT) |
commit | 86fb79cb628fd830232603105c115ebec0cb7bcb (patch) | |
tree | 2394330ab0b9f807f293ff2d2e2fd009dbee9592 /COPYING | |
parent | d3bbd300be4480c0a3b7285c91b3b27e82ca9c2f (diff) | |
download | swift-86fb79cb628fd830232603105c115ebec0cb7bcb.zip swift-86fb79cb628fd830232603105c115ebec0cb7bcb.tar.bz2 |
Handle changes in the new roster model properly
The new roster was temporarily resetting the model every
time there was a change, this patch sets it up properly
to use beginXxxRows, endXxxRows and dataChanged instead.
Test-Information:
Unit test created to check the onBeginAdd and onAdded signals
get called at the correct time and that data is stored
properly when a JID is added. Also tested live on test server,
checked what happens when the user first logs in, and when
contacts log on and off.
There was some concern over the new setState function, and
its impact on populating the new roster on login. I ran
multiple tests, swift-4 vs swift-5 with the new roster,
I tested having 3000 users with and without presence in the
roster, 100 users and 3000 users split into 30 groups of 100.
We tested both the time to populate the roster (pre presence)
and the time from login until the roster become responsive
and usable. The results weren't terribly different between
swift-4 and swift-5 with the new roster, and swift-5 was
populating both the old and new rosters, therefore we concluded
that the new roster is not causing a significant slowing down
during login.
Change-Id: I2aba5cbcd81296b49d36c54ee7f07453f1b2db08
Diffstat (limited to 'COPYING')
0 files changed, 0 insertions, 0 deletions