Notifications are an essential component of any application. Almost every application on your mobile device will send some kind of notification. The WhatsApp notification is one of the best examples of this. Whenever you receive a message, it is displayed on your phone in the form of notifications. However, many developers find it difficult to send notifications to all of their users, resulting in only a few of their users receiving notifications. As a result, one of the most frequently asked questions I receive is “Why are some of the users not receiving the push notifications?” In a nutshell, the answer is: We don’t have complete control, but we can significantly increase the delivery rate. In this article, we’ll go over some methods for increasing notification delivery rates.
What exactly is the issue?
In this section of the article, we will discuss the issues that are impeding notification delivery rates. To begin with, the most common error that all developers make is using incorrect data about their app’s users. For example, if your app has 500 users, there is a chance that 20% of those 500 users have uninstalled your app. So, you may be collecting data for 500 users, but you only sent the notification to 100 of them (20% of 500 = 100). So, the very first thing you must do is determine the exact number of users. Only 30% of the users receive the notifications that we send, i.e. 30 out of 100. As a result, we are unable to send notifications to 70% of our customers. Let’s take a look at the reasons:
30 percent of users receive notifications: As previously stated, 30 percent of users receive notifications.
30% of the time, it is classified as DND: Because there are so many applications and so many notifications from those applications, 30% of users put that particular application in DND mode, i.e. in Do Not Disturb mode. As a result, no notifications will be displayed to users for that specific application in this case.
- OEM restrictions of 20%: To improve the performance of mobile devices, mobile manufacturers create a list of apps called whitelisted apps, such as WhatsApp, Twitter, Gmail, and so on, and all notifications from those apps are allowed because very few or no services are killed for these apps. However, for battery optimization, the services of those applications that are not on the whitelisted app list are frequently terminated, resulting in your user not receiving the notification.
- FCM GooglePlayServices not present or disconnected: 20% All notifications are sent with the assistance of FCM. As a result, in 20% of cases, this service is either not present or is disconnected from your user’s device.
What is the notification system’s operation?
In general, we have two choices for sending push notifications to our users. Directly from the website of the Firebase console: In this case, we register our app on the Firebase console and then receive a registration token that uniquely identifies a device. Now, the notification message is created using the Firebase console and sent to the FCM backend. The FCM backend receives the message and generates a message-id along with some other data before sending the message to the desired user using the registration token and receiving the message when the user is connected. The following image depicts the entire procedure
How can the issues be resolved?
So far, we’ve talked about the issues and how the Notification System works. Let’s look at how to solve the problems we discussed earlier in this blog:
The DND issue
For API levels 19+, you can write code to determine whether or not your user has disabled notifications for your app. You can use the code below:
NotificationManagerCompat.areNotificationsEnabled()
If notifications are enabled, the above method will return true; otherwise, it will return false. If the API level is less than 19, it will always return true. So, if the user blocks the notifications, you can show a message saying that the notifications from your app are very important, so please enable them to stay updated. Another option is to create channels based on the type of notification. Now, users will disable only the types of notifications from your app that they do not want, and there is a good chance that the user will not disable all notifications from all channels.
The OEM issue
You can check whether your application is on the device’s whitelist programmatically. If it isn’t, you can request that the user add your application to the whitelist. This can be accomplished by including the following permission:
<uses-permission android:name="android.permission.REQUEST_IGNORE_BATTERY_OPTIMIZATIONS"/>
and then code it this way to check:
if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.M) {
Intent intent = new Intent();
String packageName = getPackageName();
PowerManager pm
= (PowerManager)getSystemService(POWER_SERVICE);
if (!pm.isIgnoringBatteryOptimizations(packageName)) {
intent.setAction(
Settings
.ACTION_REQUEST_IGNORE_BATTERY_OPTIMIZATIONS);
intent.setData(Uri.parse("package:" + packageName));
startActivity(intent);
}
} |
The OEM can also disable the services to improve battery performance. In this case, you can retrieve the notification directly from the server. However, this approach will not work for instant notifications; however, for other notifications, we can use the WorkManager to retrieve the notification from the server and create a local notification. If the preceding approach does not work for your use case, you can create a separate notification center page in your application and keep all notifications in that location only. As a result, the user may develop the habit of opening that page to check all of the notifications they have received. Depending on your use case, you can always fetch the most recent notification data from the server when the user opens the app, the notification center page, or the WorkManager. Now, let’s talk about how you should handle things when you retrieve notification data from the server, though this will also be dependent on your use case.
- So, basically, you can create a table on your server that will store all of the information that the server sends to Google Server in order to receive notifications, such as the FCM id and notification data. Create a “status” column alongside these data to store the status of the notification, i.e. whether it is shown or not (this field will be updated by the client). The following steps will be taken
- The server will request notification from Google Server by sending the FCM Id and notification data. At the same time, these data will be saved in the server-created table.
- The Google Server will send the notification to the desired devices, but due to OEM restrictions, the notifications may not be delivered. As a result, we will employ the Work Manager.
- We will retrieve the notification from the server in batches using Work Manager. For example, if we have 20 notifications with ids ranging from 1 to 20, we can send the most recently received notification id to the server, and the server will return the next ten notifications.
- Assume Google Server sent the notification with id 7. As a result, we should not display this notification again.
- Whenever we pull a notification from the server or receive a notification from the Google Server, we check on the client-side to see if it is displayed on the device. If it is displayed, we will disregard that notification and will not display it.
- Also, some notifications are only valid for a limited time, such as a restaurant offer notification from a food delivery app. In that case, you can add another field to the database table, such as the expiration date or time. Now, whenever the WorkManger retrieves that notification, we will check to see if it is expired or not. We will not show it to the user if it has expired.
- There may be instances where you only want to display the notification at a specific time, such as in Quiz App, where you need to display the notification that the quiz is about to begin at 8 p.m. or so. You must display the notification only at that time, not before or after. To handle these types of situations, add a new field to the database table and name it “display time.”
- The Work Manager may also fail to work in some cases. As a result, whenever the app is launched, you can retrieve the notification from the server. To improve on this approach, you can write some logic to fetch the notification only after a certain amount of time has passed, rather than every time the app is launched.
The FCM issue
If your app is in the messaging category, you can use WebSocket to establish a lightweight persistent connection between your client (Android App) and the server, and the server will be able to send data to the client and display notifications based on that data. If your application is not a messaging app, it is not a good idea to use WebSocket. As a result, you can use the previously discussed approach, i.e. Work Manager.