In the following sections you will learn how to structure your app's logic to better handle receiving push notifications.
When the app is in the background, the received push notifications sent through Telerik Platform are handled on operating system (OS) level—an OS-specific notification is shown as follows:
- a Banner or an Alert on iOS
- a Tile or a Toast on Windows Phone
- the sending app's notification icon in the notification tray on Android
You don't need to take additional steps to display those OS-specific notifications.
However, you may want to take further actions with the push notification when your app is brought to the foreground. To facilitate that, a pending event is available in the native part of your app for each received push notification. The following sections explain in what cases and how you can catch this event.
The push notification event (or events in case of multiple push notifications) is not always available for processing. Its availability depends on the state of the application at the moment of receiving the application and the underlying OS.
You can access the push notification event in the following cases:
- On iOS: When the user brings the app to the foreground by tapping the OS notification or when the app is in the foreground when the push notification arrives. Note that you don't have access to the event when the user brings the app by tapping its app icon even though it wears a badge with the notification count.
- On Android: When the user brings the app to the foreground by tapping the notification in the Android notification drawer or when the app is in the foreground when the push notification arrives. Note that you don't have access to the event when the user brings the app by tapping its app icon.
- On Windows Phone: When the app is in the foreground and a Toast notification is received. Note that you don't have access to the event when the app is opened through a notification Tile or Toast.
notificationCallbackWP8 callback function on iOS, Android, or Windows Phone respectively.
To ensure that the callback functions are supplied to the native code, you need to invoke
el.push.register(pushSettings) each time the application starts.
- For hybrid apps this is best achieved by placing it in the
devicereadyevent handler or in a suitable place in your code after this event has been handled.
- For NativeScript, invoke it after your app has started, for example in the
If the application is cold-started from a notification, any pending notification events will be dispatched immediately after
Interactive push notifications on iOS feature buttons or text input that rely on application code. When the user interacts with these controls, you need to ensure that your code is executed, even if the application is closed or in the background.
To do that, call the
notificationProcessed callback at the end of the handler specified using the
content-available iOS-specific option that enables the so called silent push notifications can be very useful if used properly. However, you need to explicitly enable it to work with Hybrid apps. This adds the "Background App Refresh" setting to your application. Keep in mind that the app user can disable the setting at any time, preventing your push notifications from reaching the device.
Enabling Background App Refresh on Hybrid apps may cause your app to be declined by the Apple App Store because of its potential for abuse. Even if approved, iOS may block all push notifications to the app if you abuse the feature.
To enable silent push notifications:
- If you are using AppBuilder, enable the Remote Notification option under Background Mode. See iOS Properties for more information.
If you are not using AppBuilder, add the following snippet to your app's property list (
.plist) file. Ensure that you are using the Telerik Push Plugin from the verified plugins marketplace.
<key>UIBackgroundModes</key> <array> <string>remote-notification</string> </array>