Alternative Cross-Platform Hub/Protocol For Notifications?

Is there a known alternative hub/protocol to traditional push notifications that would provide 100% guaranteed delivery to an cross-platform app that needs to be in a background sleep state and woke up upon notification receipt or delivered upon device on. I just recently discovered that current cross-platform push notifications via the different notification hubs don't have this capability.

The notifications need to be specific device deliverable with a small payload. The hub needs to be scalable to handle 50M/sec notifications on a global data center network like Azure with device location capabilities like a cell phone network. The app can participate in enabling that capability similar to a mobile phone with its carrier.

Best Answer

Answers

  • LandLuLandLu Member, Xamarin Team Xamurai

    What do you mean

    a background sleep state

    If you want to fire the app when it has quit, it can't be achieved on iOS.
    You can only fire the app when it was on the background state.
    For iOS, you could use silent notification:
    https://stackoverflow.com/a/36695473/8354952
    Add the "content-available" : 1 in your payload.
    For Android:
    Use Data Messages. These messages trigger the onMessageReceived() callback even if your app is in foreground/background/killed: https://stackoverflow.com/a/37845174/8354952
    It isn't based on what hub you are using. Actually, Azure is also consuming FCM on Android. It depends on what sort of notifications you are sending from your hub.

  • alaskanroguealaskanrogue USMember ✭✭✭
    edited April 11

    I am not speaking of not running. There are both active and inactive(sleep) states possible for app in the background; the later being not performing any activity, just perceived by the OS as running.

    Per a recent Apple support case (hence my question):

    Your push notifications are silent. They only have content-available, and no user visible content (sound, alert, or badge).

    Push notifications with user-visible keys such as alert, sound, or badge sent at high priority (priority 10) are always displayed. However, if the notification also contains the content-available key, the notification may be throttled and thus not be sent to the app in the background unless the user taps the notification.

    Notifications sent at low priority (priority 5) are throttled, regardless of payload. Silent push notifications should always be sent at low priority (although I see that you are setting the priority to 10)

    You may expect up to several silent push notifications per hour across all apps on a device. But it is entirely possible and appropriate that you may receive none at all.

    The purpose of the throttle is to predict when the user will launch an app and thus allow background activity to update the app’s content in an energy-efficient manner. It also serves to prevent apps from consuming too much of the user’s battery or cellular data with background traffic.

    ** Once the device-wide battery or data budgets have been exhausted, no more background push notifications will be delivered until the budgets are reset. **The budgets are reset every 24 hours, and this schedule cannot be changed by user or developer action.

    Since these budgets apply across all apps on a device, it’s possible that an app other than your own has exhausted the budgets. You can check the overall battery usage of an app in Settings > General > Usage > Battery Usage.

    **The throttle also tracks when the device has poor network connectivity, because repeated attempts to connect to APNs when network connectivity is spotty can cause significant power drain. This is by far the most common reason why push notifications do not reach a device. **To check if poor network connectivity is affecting your push notifications, you can use the steps in Observing Push Status Messages.

    To test background push notifications, follow these steps.

    1. Attach your device to your Mac.
    2. Start your app from Xcode.
    3. When it has launched, stop your app from within Xcode by clicking the Stop button (square icon at upper left).
    4. In Xcode, do Debug -> Attach to Process -> [Fill in Process Name to wait for] -> Attach
    5. Send the push notification with content-available:1 and your app will receive the notification every time.

    You can use the process list in Instruments to confirm that your app is running in the background.

    You can also test using Wi-Fi and a device that is plugged in to wall power.

    If you’re sending silent push notifications, be sure you use the API described in Sending Notification Requests to APNs or the Binary Provider API so you can set the notification priority to 5. (The default priority is 10.)

    If you believe throttling is not working properly, please file a bug report at https://developer.apple.com/bug-reporting. The details of how throttling works are not public API, but iOS Engineering looks at these bug reports and can determine if notifications are being throttled as expected.

    The important point is that apps should never be designed expecting that every push notification will be received. This is not how APNs is intended to work; it is intended to inform the user or app that some event of interest has occurred. Apps are expected to work properly, albeit perhaps with degraded functionality, if push notifications are not received. The user can turn off push notifications or background app updates at any time, and of course push notifications will not be received if the device doesn’t have Internet connectivity.

    It is expected behavior that an app will not be woken in the background by a push notification if the app had previously been force-quit. (Background location and VoIP apps are exceptions to this.) Force quit is a drastic choice by the user to say that they do not want the app to run, often because it misbehaved in some unrecoverable manner. This is discussed in Understanding When Your App Gets Launched into the Background.

    I suggest looking into using a notification service extension as discussed in Modifying Content in Newly Delivered Notifications. Note that your notification payloads need to be crafted as outlined in the documentation (with visible content) so that your service extension is called when a notification arrives for your app.

    Other than that, I see that your notifications are reaching the device (even if not your app). If you are unsure about your push server or network settings, you can test those by sending user visible content to make sure the infrastructure is configured correctly.

    In response to the above, I made my notifications not silent and with visible content and still didn't have 100% delivery, with alerts not generated.

  • LandLuLandLu Member, Xamarin Team Xamurai

    Yes, you are right. Apple can't guarantee your messages are 100% received by your devices. It depends on your device's network quality. If it is offline, apparently, it can't receive the notifications from APNS.
    Refer to this thread for more discussion about APNS: https://stackoverflow.com/questions/13897575/apns-apple-push-notification-service-reliability.
    You could also get more information about APNS through this guideline: https://developer.apple.com/library/archive/documentation/NetworkingInternet/Conceptual/RemoteNotificationsPG/APNSOverview.html#//apple_ref/doc/uid/TP40008194-CH8-SW1
    It says:

    Apple Push Notification service includes a Quality of Service (QoS) component that performs a store-and-forward function. If APNs attempts to deliver a notification and the destination device is offline, APNs stores the notification for a limited period of time and delivers it when the device becomes available again. This component stores only the most recent notification per device and per app. If a device is offline, sending a notification request targeting that device causes the previous request to be discarded. If a device remains offline for a long time, all its stored notifications in APNs are discarded.

    The old messages could be deleted. So it is not 100% reliable. And we could do nothing about this as we have to use Apple service to deliver notifications.

  • alaskanroguealaskanrogue USMember ✭✭✭
    edited April 12

    This has turned in to a long discussion about the current push notification world and not answering my original query, "Is there an alternative?", to meet my needs.

  • JamesLaveryJamesLavery GBBeta, University ✭✭✭✭✭

    @alaskanrogue said:
    I am not speaking of not running. There are both active and inactive(sleep) states possible for app in the background; the later being not performing any activity, just perceived by the OS as running.

    I think the short answer is 'no'.

    You can't guarantee the the app will remain in the state you mention above. The OS may terminate the app due to memory or other constraints, and therefore it will then. not be running. This is where the current Push Notification architectures for iOS and Android come in - if they are received by the device, then the OS will restart the app. Other solutions (like SignalR for example) won't work in this scenario because the app isn't running.

    However, as @LandLu says, Apple (and I think Google) don't guarantee that Push Notifications will be delivered 100%. They usually are - but there's no hard guarantee!

  • alaskanroguealaskanrogue USMember ✭✭✭
    edited April 14

    James, are you saying that there are no operational cross-platform notification protocols/hubs that assure 100% delivery and wakeup?

Sign In or Register to comment.