Search code examples
androidsocketsandroid-activityandroid-serviceread-unread

Android - Keep global track of unseen notifications, best practices

In Android, i have a socket keeping real-time communication with the server. This app socket is being controlled by a service, that starts on boot and / or whenever a request is being emitted by the app.

Because I cannot depend on Google PlayStore, I fully control the sending + receving of push-messages manually.

Whenever a new push-message arrives from the server, the socket-service sends a local broadcast message and the listening activities can follow there own action.. If no activities are found, a default android notification is given to the user, saying '[ap] You have {n} new message(s)'...

This has its stability problems (the service can be shut down by the OS when low on memory for example) but its okay.

Now, consider the following:

I have multiple activities that listens-for and shows a count of unread messages.

  • HomePage
  • ConversationsOverviewPage
  • 'The' conversation page (chatpage)

Each activity can be on the foreground, but can also be in memory for when the user back-presses and goes back 1 activity. So in Theory, there can be a situation where you want to update different/multiple activities at once.. This prevents having to 're-load' the unread messages from the server when the user gets back to a 'savedInstance'. So the broadcast pattern works best I think.

What is best practise for keeping global track of unread messages, while minimising the server trip on every activity instance:

  1. Very simpel: Make a server request on each and every activity instance, and write update code again for every activity. But this results in the user seeing a delay, as it takes a second before the app receives data from the server and show the 'unread-messages' balloon.

  2. Simpel: Have a global class.. Holding the unread messages for each conversation, But I feel this can give problems with data being incomplete.. Especially when the app is not 'active'

  3. My old vote: Have another service thats keeping track of the unread messages, that starts on boot (just like the socket).. Only when the service starts / boots, it will requests all unread-messages data from the server. Each activity can than 'ask' for the unread-messages data and don't have to worry about it anymore. But this could be overkill?

  4. My new vote: Keep the socket-service, and add a separate class to this service.. That holds the unread-data.. But this also does not feel to be right.. As the activity would have to ask the service something out-of-scope.. Its not the sockets concern to manage unread messages (separation of concerns), right?

Any thanks from experienced developers is much appreciated!

Solution

  • Third options is ok. Not sure where is overkill exactly. Obviously you shouldn't download all unread messages on every boot or socket reconnection. The most important rule of thumb is to load data when the app really needs it. Few moments about how I've developed about the same app:

    • there is socket Service which handles connecting, disconnecting, sending data(messages) and receiving data.
    • there is Notification manager which receives events from SocketService. It saves new data which comes from server and decides which broadcast notification should be sent.
    • when socket is connected it receives state data from server:
      1. dates(timestamp) of last update for every chat. For instance if local database contains that chat A was updated yesterday but freshly received data from server says that the chat A was updated few seconds ago you need to broadcast event like chat A has been updated since last connection and save update date. If there there is any activity which somehow show the chat A it loads(through http or whatever) new data.
      2. last messages for every chat. The app just compares locally saved last messages and freshly received. If there is new one the app again broadcast event like there is unread message/messages from user x. If there is visible activity which shows updated chat it updates data otherwise the app shows notification.

    So the basic flow of handling unread messages is next: connect to the server > check if there is data about unread messages > save new data to the local database > broadcast events about new data.

    And I would recommend you to use GCM and socket connection simultaneously. GCM really helps to keep data updated. It wakes up a phone and sometimes delivers data when socket connection just could not be established due to network problems.