Altova MobileTogether Designer

This section lists the different parts of the Push Notification (PN) mechanism that are present in the receiving solution. While the mechanisms listed below are part of the receiving solution, note that the receiving solution can be the same solution as the sending solution. If this is the case, then the mechanisms of both the receiving and sending solutions are combined in one and the same solution.


Note:   The Big Content of standard MobileTogether solutions is displayed only on Android and Windows devices. If you want Big Content to be displayed on iOS devices, then compile the receiving solution as an AppStore App.


OnPushNotificationReceived event


At design time, the OnPushNotificationReceived event is accessed via the receiving solution's project properties. In the event's tab, you define the actions to carry out when the PN is received. When an action is added to this event at design time, the \$MT_PUSHNOTIFICATION page source is automatically created.

At run time, the OnPushNotificationReceived event is triggered when the user taps the PN or a button in the PN. When the event is triggered, the following happens: (i) the receiving solution is started if it is not already running; (ii) the PN's payload is automatically transferred to the \$MT_PUSHNOTIFICATION page source; if a PN button was pressed, then, additionally, the button's ID (which is a string) is passed to the page source; (iii) the event's actions will be executed; note that, by using the If-Then or If-Then-Else action, actions can be made dependent on what PN button was pressed (see next section below).



The \$MT_PUSHNOTIFICATION page source has the following fixed structure:




|   @button


|-- Entry

|      @key

|      @value


At run time:


If a PN button was tapped, then the button's ID is passed to the \$MT_PUSHNOTIFICATION/Root/@button node. The value of the @button attribute can be used for conditional processing by using the If-Then or If-Then-Else action. For example, if the @button node contains an Accept button's ID, then an acceptance SMS can be automatically sent or a database suitably modified; alternative actions can be defined for other button IDs.

The number of Entry elements is determined at run time and will be equal to the number of key–value pairs contained in the PN's payload. The data of each key–value pair will be passed to a corresponding Entry element. Data in the \$MT_PUSHNOTIFICATION page source can be processed in any way that you want, including to simply display the data in the design.


External PN keys

A PN-receiving mobile device can be registered by using one external PN key per solution. This key is a text string that is generated by the Register Ext PN-Key action (see screenshot below). If a PN is sent to a given external PN key, then all devices that are registered with that key will receive the PN.


The fact that one PN key can be registered per solution has two implications:


The device can be registered with different external PN keys, but each PN key is tied to a specific receiving solution. If two solutions on the device use the same PN key, then a push notification that targets this key will be delivered to both solutions on that device.  

Since the same key can be generated by the same solution on other mobile devices, the external PN Key serves to identify a particular set of mobile devices. If a push notification is sent to a particular PN key, then devices that were registered with this PN key will receive the push notification.

Note:External PN keys can also be used in AppStore Apps..


PN topics

A PN-receiving mobile device can be registered to receive PNs about one or more specific topics. A device is registered for one or more topics via the Register PN-Topics action (see screenshot below). At run time, if a PN is sent to a given PN topic, then all devices that are registered for that topic will receive the PN. If a PN is sent to multiple PN topics, then devices that are registered for any of the target topics will receive the PN.


In theory, any solution on a particular device can be used to register that device for a given topic. In practice, it is best that the registration for a topic be done from the solution that will be receiving the PN.


iOS PN button set definitons

When a PN containing a PN button arrives on a device and the button is tapped, then the receiving solution is started and the PN button's ID is passed to the \$MT_PUSHNOTIFICATION/Root/@button node of the solution's \$MT_PUSHNOTIFICATION page source. This is all that the PN button does. In effect, it provides a way to determine how the user wishes to react to the PN.


While PN buttons for non-iOS devices are defined in the Send Push Notification action of the sending solution, iOS PN button sets are defined in the receiving solution via the Project | iOS Push Notification Button Sets command.


The receiving solution as an AppStore App

If the receiving solution is being created as an AppStore App, please see Push Notifications in AppStore Apps for additional steps to take.


© 2017-2023 Altova GmbH