General Mechanism for Scheduling Notification in Android

This article is more of a quick note about what’s involved when your Android app needs to create a notification and schedule it to appear at some time in the future. There’s a lot of articles out there that goes in details about the implementation. Think of this article as more of a summary.

The main components and concepts

On the notification side:

  • NotificationCompat. This is the main class for building the actual notification.
  • Notification Channel. Starting from Android 8.0, every notification must belong to a Notification Channel. It’s essentially categories for notifications, and in fact in the user-facing setting area within Android, it is called “Categories”. Different channels can be set to have different notification behaviors (importance, sound, vibration, and so on). The categories usually are created within the starting activity’s onCreate.
  • Notification Manager. This class manages both Notification and Notification Channel creation, as the name suggests. It’s available as a systems-level service and has methods for registering channels, and to actually post/display the notifications, among other things.

On the scheduling side:

  • Alarm Manager. This is another systems-level service like Notification Manager. Essentially, its purpose is to let you wake up your application at a specific time, and then make it do something at that time, even if the app is not currently running. In this article’s context, that “do something” is to make our app build and display notification(s).
  • A Pending Intent. To understand Pending Intent, first we need to understand what an Intent is. Intent, crudely speaking, is like a request for something to be done. What should fulfill the request? Generally, the four main Android Components (Activities, Services, Broadcast Receivers, and Content Providers). We can enter some data inside the Intent, so that the receiving component can do something specific with them.

    A Pending Intent is a way to wrap an ordinary Intent and give it to foreign applications, so that at some point they can use it to request our application to do something, as if the request comes from our app itself. In our case with Notifications, we’re giving/registering the Pending Intent containing some data about what the Notification should say, to the Alarm Manager.

    As part of the Android system, Alarm Manager communicates with our app in a specific way called a broadcast. To handles broadcast properly, according to the Intent documentation, the Pending Intent has to be created using a specific PendingIntent.getBroadcast() method. More about Broadcast Receiver below.
  • A Broadcast Receiver. If Pending Intent is the key to access something inside our app, Broadcast Receiver acts the keyhole. Like the name says, this part will accept the Pending Intent that is sent as a broadcast by the Alarm Manager. In our case, the Broadcast Receiver receives the data from the Pending Intent and constructs a Notification out of it, to be displayed right away.

Here is a quick sketch on how everything can be connected together (click the image for larger version):

Mechanism for scheduling notification in Android development

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s