Android Notifications -How to handle millions of push notifications in a day?
It’s been found that 97.5% of the world’s population has sent a text at least once in their life, with the average person sending up to 16 texts a day, straight from their phones or through a chat application. I was working on a similar use case of Chat Application and came across a major issue.
What exactly the problem is?
While developing my Android application which was being used actively by 1000’s of users and they started to complain a lot about missing notification from important people. So I dug deeper and found that Android OS “Force Stops” my app after about 100 -110 notifications if I don’t interact with them for a while. It also ended up in showing the message “My App is draining power”
Looking for a solution
I started to post at various platforms about the issue and ended up with a suggestion to use Battery Historian to see what exactly is happening!! I checked out what was different in other chat apps and mine. I noticed there was a service running periodically which was decreasing the number of wake locks for their application.
How did I solve the problem?
I thought of a solution by using android Foreground Services. I had a bonus already that my backend had socket.io implemented already. So my solution will revolve around two things:
1. Socket .io
2. Android Foreground Service
Socket.io
The role of sockets was to detect if the person is active on the application or not. Whenever I used to open the app I would join a unique room to listen for the new notifications. So, by doing this we saved about 95% of notifications that were being delivered using FCM. Now you must be thinking about the notifications when the person is not online in the application.
What exactly happens when a message is sent to a user?🤔
Step 1: Check on the backend if the person is offline (i.e, not joined to that unique room user wise).
Step 2: Send the user a notification to subscribe to the room so that they can receive the new notifications.
What about the notification before that?😳
Don't worry they will be fetched from the backend using a foreground service in part 2 Android Foreground Service.
Step 3: Once the sockets are connected backend will check every time if the user is subscribed or not? And he will be subscribed and sent a socket data object and I will generate a local notification for the data object.
Step 4: If the user is inactive (App is in the background) for say x seconds (in my case it was 180 seconds) then I used to disconnect the socket and whenever I get a new message the same steps would be iterated.
Android Foreground Service
Say my app is killed or my socket is in a disconnected state.
Step 1: Backend checks if the user’s unique room is subscribed or not. (It is not)
Step 2: The device receives a notification to subscribe to the room.
Step 3: A foreground service runs(Checking for new messages) to fetch messages from the server through an API
and gives the user the messages that were received on the device while it was in the killed state and before the socket was connected. So now after every x seconds device checks if the user is in an active state (App is in foreground) or not. If active data is received through sockets otherwise the Foreground service flow iterates.
Yayyyy!!!
Now I need not worry about my application to use excessive battery hence, no message for battery draining hence, minimal loss of notifications. 😎😎😎😎
This concludes my article about creating a real-time chat application to incorporate the delivery of millions of notifications in a day.
Liked my work? Buy me a coffee.
