Tag and Broadcast Notifications in Native Android Applications
improve this page | report issueOverview
Prerequisite: Make sure that you read the Push notifications in native Android applications tutorial first.
Tag notifications are notification messages that are targeted to all the devices that are subscribed to a particular tag.
Tags represent topics of interest to the user and provide the ability to receive notifications according to the chosen interest.
Broadcast notifications are a form of tag push notifications that are targeted to all subscribed devices. Broadcast notifications are enabled by default for any push-enabled MobileFirst application by a subscription to a reserved Push.all
tag (auto-created for every device). Broadcast notifications can be disabled by by unsubscribing from the reserved Push.all
tag.
Agenda
Notifications configuration
Tag Notifications configuration
Setting up tags
Tags are defined in the application-descriptor.xml
file:
Notifications API
API methods for tag notifications
Client-side API
WLPush.subscribeTag(tagName,options)
- Subscribes the device to the specified tag nameWLPush.unsubscribeTag(tagName,options)
- Unsubscribes the device from the specified tag nameWLPush.isTagSubscribed(tagName)
- Returns whether the device is subscribed to a specified tag name
Common API methods for tag and broadcast notifications
Client-side API
WLNotificationListener
Defines the callback method to be notified when the notification arrives.client.getPush().setWLNotificationListener(listener)
This method sets the implementation class of theWLNotificationListener
interface.client.getPush().setOnReadyToSubscribeListener(listener)
This method registers a listener to be used for push notifications. This listener should implement the onReadyToSubscribe() method.- The
onMessage(props,payload)
method ofWLNotificationListener
is called when a push notification is received by the device.- props - A JSON block that contains the notifications properties of the platform.
- payload - A JSON block that contains other data that is sent from MobileFirst Server. The JSON block also contains the tag name for tag-based or broadcast notification. The tag name appears in the "tag" element. For broadcast notification, the default tag name is
Push.ALL
.
Server-side API
WL.Server.sendMessage(applicationId,notificationOptions)
This method submits a notification that is based on the specified target parameters.
applicationId
- (mandatory) The name of the MobileFirst applicationnotificationOptions
- (mandatory) A JSON block containing message properties
For a full list of message properties, refer to the WL.Server.sendMessage API in the API reference of user documentation
Sample application
Click to download the MobileFirst project.
Click to download the Native project.
- The
TagNotifications
project contains a MobileFirst native API that you can deploy to your MobileFirst Server instance. - The
TagNotificationsAndroid
project contains a native android application that uses a MobileFirst native API library to subscribe to push notifications and receive notifications from GCM. - Make sure to update the
wlclient.properties
file in the native project with the relevant server settings.
Sending a notification
To test the application is able to receive a push notification you can perform one of the following:
- From MobileFirst Studio, right-click the adapter folder, select Call MobileFirst Adapter and:
- If selecting the "sendBroadcastNotification" procedure, provide the application ID and notification text in quotation marks.
- If selecting the "sendTagNotification" procedure, provide the application ID, notification text and tag name in quotation marks.
- The application ID can be determined from the
id
attribute inapplication-descriptor.xml
:
- If using the CLI:
Or:
Inclusive terminology note: The Mobile First Platform team is making changes to support the IBM® initiative to replace racially biased and other discriminatory language in our code and content with more inclusive language. While IBM values the use of inclusive language, terms that are outside of IBM's direct influence are sometimes required for the sake of maintaining user understanding. As other industry leaders join IBM in embracing the use of inclusive language, IBM will continue to update the documentation to reflect those changes.