Straight to your questions:
1. The "Devices" column of the grid takes a while to aggregate and reflects the count of devices the push notification was sent to.
2. It is right that pushes are sometimes referred to as "best effort". However, the push notification services could be relied on, in terms to know that messages created through Backend Services will be sent immediately to the corresponding server. Each disruption in Backend Services is shown at the status
page. In regard to Apple-specific notifications, the Apple Push Notification servers await the response from the device for its availability, before continuing to process the queue of incoming messages. The following doc
is considered to be the general guideline for troubleshooting push notifications for Apple devices. Along with the already effective enhancement in our push infrastructure, we are working on more developer-friendly experience for troubleshooting push notifications in the context of Backend Services.
3. We are eager to contemplate the great accomplishments of our customers, so the only limitations imposed to them in the Backend Services realm are these deriving from their subscription plan. Of course, in regard to the end users of the apps, instrumented with the Telerik Platform services, their bandwidth and calls to the server should be spared as much as possible, with elaborated client-side management of the operations for retrieving and syncing of the data.
4. The push servers know when the notification is delivered in a indirect way as they await the response of the device's state. iOS devices will receive only the last notification sent to them when they become available. In Android devices this is specified by the collapse_key
key (for the lack of more accurate word).
5. The described workflow is the appropriate one. In regard to the push token, the push service providers always warn that the push token may suddenly change.
Please, let us know if this information is helpful for you.