Show unread counts and add bankruptcy option.

[Sam1301]

Summary of changes

• shows unread counts

  • real-time sync with server using update_message_flags event
  • UI changes

• bankruptcy menu option

  • fetch all messages in batches of 200

• fetch 1000 messages on start-up (related discussion https://github.com/zulip/zulip-android/pull/283#issuecomment-273869004)

[timabbott]

So the main potential downside of fetching 1000 messages on startup is performance when on a slow network; to what extent have you tested that? It might actually be fine with compression, but we should be sure :)

[Sam1301]

I tested the difference between fetching 100 and 1000 messages. Here are the results: For 100 messages (current behaviour)

For 1000 messages

these results were obtained for a 35Mbps connection... i think we could fetch 1000 messages in batches of 200 or so and display them simultaneously?

[timabbott]

So I think with a 35Mbps connection, it'll be fine either way. For this, we want to test with a relatively slow connection.

We could do something simpler than doing 5 batches of 200, like fetch 200 at first (to show something) and then fetch the next 800. The thing that's really important to optimize here is the time-to-first-interaction, but there's not much reason to do 5 rounds over 2.

[Sam1301]

ok got it, I'll update the pr with fetching 200 first and displaying it. Following this, in the background 800 messages can be fetched and added to the bottom of the list. During this time, the user will be able to interact with those 200 messages in the list. These 800 messages loaded in background could probably be fetched in a single call. Would that be fine?

[timabbott]

Yep, fetching 800 in one call makes sense. FWIW the webapp does roughly that with 400 and 1000 as the parameters, so it's a pretty similar algorithm.

[saketkumar]

@Sam1301 Really nice work! :) Resolve the merge conflicts too. :+1:

[zulipbot]

@Sam1301, your pull request has developed a merge conflict! Please review the most recent commit (f791888) for conflicting changes and resolve your pull request's merge conflicts.

[zulipbot]

@Sam1301, your pull request has developed a merge conflict! Please review the most recent commit (470ade3) for conflicting changes and resolve your pull request's merge conflicts.