Android Mobile Push Notifications

PubNub Mobile Push Notifications gateway bridges native message publishing with third-party push notification services including Apple Push Notification service (APNs) and Firebase Cloud Messaging (FCM). The code below shows a sample implementation needed to register for remote notifications, receive the corresponding device token, register the device token to a PubNub channel, and publish a message.

Step 1: Configure Account Settings

Before you can use PubNub Mobile Push Notifications feature with Firebase Cloud Messaging, you must first configure your accounts. Follow these steps to configure both your Firebase Cloud Messaging and PubNub accounts for your application.

Step 1a: Create a Firebase Server Key

Log into your Firebase console and create a new project.

Firebase Login

Click Add Firebase to your Android app and follow the steps there.

Firebase Add Android App

Go to Project settings icon at the top left, next to Project overview. Click the Cloud messaging tab and find the Server key there.

Firebase App Settings

Step 1b: Add the Firebase Server Key to Your Admin Portal

On the Admin Portal, go to the Mobile Push Notifications section from the Keys page. Paste the Firebase Server Key into the field labeled FCM API Key, and click the Save Changes button that appears.

Set FCM API Key

Step 2: Requesting Device Token

To add Cloud Messaging support to your application, open your Android Studio project and switch to the Project view. Then add the google-services.json that was downloaded during step 1 into your Android app module root directory.

Set FCM API Key

Step 2a: Configure Gradle

The Google Services plugin will load the google-services.json file. To include this plugin, add the following to the project-level build.gradle file (<project>/build.gradle).

buildscript {
repositories {
// Check that you have the following line (if not, add it):
google() // Google's Maven repository
}
dependencies {
...
// Include this line
classpath 'com.google.gms:google-services:4.3.5'
}
}

allprojects {
...
repositories {
show all 20 lines

App-level build.gradle (<project>/<app-module>/build.gradle)

plugins {
id 'com.android.application'
// Include this line
id 'com.google.gms.google-services'
}
dependencies {
// Include this line
implementation platform('com.google.firebase:firebase-bom:26.5.0')
}

After detecting the changes made inside your Grande files, Android Studio should provide a prompt to Sync Now to pull in the new plugins.

Step 2b: Firebase Registration

The following code shows how to create a Firebase Installations ID from FirebaseMessaging. This can be done anywhere inside the app, but for this example, it's in the onCreate method of the AppCompatActivity to ensure it's always executed.

Read Firebase Docs for more details.

public class MainActivity extends AppCompatActivity {
@Override protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
SharedPreferencesManager.init(getApplicationContext())

FirebaseMessaging.getInstance().getToken().addOnCompleteListener(new OnCompleteListener<String>() {
@Override public void onComplete(@NonNull Task<String> task) {
if (!task.isSuccessful()) {
Log.w(TAG, "Fetching FCM registration token failed", task.getException());
return;
}
Log.d(TAG, getString(R.string.msg_token_fmt, task.getResult()));
}
});
}
show all 16 lines

Step 3: Receiving & Monitoring Device Token

To receive the Device Token (and updates to the token value) and mobile push notifications, you must create a custom class that extends FirebaseMessagingService.

The onNewToken callback fires whenever a new token is generated. After the initial FCM registration and device token has been delivered, new tokens will be delivered to this delegate method and your PubNub channel registrations will need to be updated.

public class MyFirebaseMessagingService extends FirebaseMessagingService {
@Override public void onNewToken(String token) {
String oldToken = SharedPreferencesManager.readDeviceToken();
if (token.equals(oldToken)) { return; }
SharedPreferencesManager.write(token);

updatePushNotificationsOnChannels(SharedPreferencesManager.readChannelList(), token, oldToken);
}
}

Step 3a: Caching Device Token & Registered channels

To ensure that an application can properly handle adding, updating, and removing registered push channels, there are two pieces of information that should be cached to avoid race-conditions: the Device Token and the list of registered channels. Not only will properly caching allow for easy access from anywhere inside the application, it will also prevent against race-conditions when multiple registration operations are queued at the same time.

SharedPreferences provides basic persistent storage, but can be replaced by more sophisticated storage as your use-case requires. The following code will ensure the accessing of the cached information will be thread-safe regardless of storage choice.

A new Device Token can be provided from the system at anytime, and should be stored whenever it's received. The list of registered channels should also be cached in a similar manner as the Device Token, and should be updated whenever registered channels are added or removed. Set is used for the convenience of ensuring there are no duplicate channels.

public class SharedPreferencesManager {
private static SharedPreferences sharedPref;
private SharedPreferencesManager() { }

public static void init(Context context) {
if(sharedPref == null)
sharedPref = context.getSharedPreferences(context.getPackageName(), Context.MODE_PRIVATE);
}

public static final String FCM_DEVICE_TOKEN = "PUBNUB_FCM_DEVICE_TOKEN";
public static @Nullable String readDeviceToken() {
return sharedPref.getString(FCM_DEVICE_TOKEN, null)
}
public static void writeDeviceToken(String value) {
SharedPreferences.Editor prefsEditor = sharedPref.edit();
show all 29 lines

Step 3b: Updating Existing Registrations

A simple helper method can be created to consolidate the remove-then-add functionality when updating your existing registered channels.

public void updatePushNotificationsOnChannels(String[] channels, String deviceToken, String oldToken) {
if (oldToken != null) {
pubnub.removeAllPushNotificationsFromDeviceWithPushToken()
.pushType(PNPushType.FCM)
.deviceId(oldToken)
.async(new PNCallback<PNPushRemoveAllChannelsResult>() {
@Override public void onResponse(PNPushRemoveAllChannelsResult result, PNStatus status) {
// Handle Response
}
});
}

pubnub.addPushNotificationsOnChannels()
.pushType(PNPushType.FCM)
.deviceId(deviceToken)
show all 22 lines

Step 4: Managing Device Registrations

Once a Device Token is obtained, it can be registered with list of channels to allow Mobile Push Notifications to be send to the device. Channels can be dynamically added and removed based on the use cases of the application, and the current registrations for a Device Token can also be viewed.

Step 4a: Register New Channels

When adding channels, it's recommended to obtain the Device Token and List of Registered Channels from a cached source. After successfully registering channels, the newly registered channels should be added to the cached list.

String cachedToken = SharedPreferencesManager.readDeviceToken();

pubnub.addPushNotificationsOnChannels()
.pushType(PNPushType.FCM)
.deviceId(cachedToken)
.channels(Arrays.asList("ch1", "ch2", "ch3"))
.async(new PNCallback<PNPushAddChannelResult>() {
@Override
public void onResponse(PNPushAddChannelResult result, PNStatus status) {
// Handle Response
}
});

Step 4b: List Registered Channels

Once device registrations are added, you can confirm the APNs registrations for the device by listing all channels that the device is registered with. Since the list on the server is the source-of-truth, we will update our cached list to reflect the channels currently registered on the server.

String cachedToken = SharedPreferencesManager.readDeviceToken();

pubnub.auditPushChannelProvisions()
.pushType(PNPushType.FCM)
.deviceId(cachedToken)
.async(new PNCallback<PNPushListProvisionsResult>() {
@Override
public void onResponse(PNPushListProvisionsResult result, PNStatus status) {
// handle response.
}
});

Step 4c: Remove Existing Registrations

When removing channels it's recommended to obtain the Device Token and List of Registered Channels from a cached source. After removing registering channels, the channels that were removed should be also removed from the cached source.

String cachedToken = SharedPreferencesManager.readDeviceToken();

pubnub.removePushNotificationsFromChannels()
.pushType(PNPushType.FCM)
.deviceId(cachedToken)
.channels(Arrays.asList("ch1", "ch2", "ch3"))
.async(new PNCallback<PNPushRemoveChannelResult>() {
@Override
public void onResponse(PNPushRemoveChannelResult result, PNStatus status) {
// handle response.
}
});

Step 5: Constructing the Push Payload

To send a push notification, include the appropriate push notification payload for FCM when you publish a message and PubNub will appropriately parse the message.

The structure of the pn_gcm payload is as follows:

FieldTypeRequiredDescription
notificationJSONNoThe dictionary sent to the Android device specify the type of interactions that you want the system to use when alerting the user. These messages are displayed automatically on behalf of the client app.

Refer to the Firebase documentation for more information.
dataJSONNoArbitrary key/value payload the client app is responsible for processing.

Refer to the Firebase documentation for more information.
pn_exceptions[String]NoA list of Device Tokens that should be excluded from receiving the notification.
pn_collapse_idStringNoAn identifier to join multiple notifications into a single notification. You can only add the custom pn_collapse_id to data messages which are non-collapsible by default.

It is not possible to set a user-specified collapse_id for notification messages payloads that have a notification key. These messages are always collapsible together using the package name.
priorityenumNoDetermines the priority level for delivering a push notification to mobile device. Takes either normal or high value.

Refer to the Firebase documentation. for more information.

You may identify the target of the notification. For more information refer to Firebase Documentation.

You can also add the following options as part of the root payload (not nested under pn_gcm), like so:

{
"pn_gcm": {
"notification": {
"title": "Chat Invitation",
"body": "John invited you to chat"
}
// or alternatively
//"data": {
// "title": "Chat Invitation",
// "body": "John invited you to chat"
//}
}
// other optional attributes
"pn_debug": true,
"pn_dry_run": true,
show all 17 lines
FieldTypeRequiredDescription
pn_debugbooleanNoA flag that enables push debugging info to the pndebug channel. For more information, refer to Mobile Push Troubleshooting.
pn_dry_runbooleanNoA flag that allows developers to test a request without actually sending a message.
pn_ttlintNoTime in seconds after which the notification expires.

If you want to make sure that your push notifications are delivered despite the target device being in Doze mode you can use the priority parameter, like so:

{
"pn_gcm": {
"notification": {
"title": "Chat Invitation",
"body": "John invited you to chat"
},
"priority": "high"
// other optional attributes
},
"pn_debug": true,
"pn_dry_run": true,
"pn_ttl": 60
}

Read Firebase Docs for more details.

{
"text": "John invited you to chat",
"pn_gcm": {
"notification": {
"title": "Chat Invitation",
"body": "John invited you to chat"
}
},
"pn_exceptions" : ["device-token1", "device-token2"]
}
}

Step 6: Publishing the Push Notification

Once the push payload is ready use the publish method to publish the message on a channel. When PubNub finds the pn_gcm payload, it will retrieve all device tokens that are associated for push on the target channel and forward a push notification request to the appropriate push service for those associated devices.

pubnub.publish()
.channel("ch1")
.message(pushPayload)
.async(new PNCallback<PNPublishResult>() {
@Override
public void onResponse(PNPublishResult result, PNStatus status) {
// Handle Response
}
});

For more information about push troubleshooting, refer to Mobile Push Troubleshooting.

Last updated on