I have a Cordova app that receives secure messages from a service provider, through our servers, to an app installed on a phone by the user. However, the app may be rarely used (in the order of 12 months or so). In the event that the provider needs to contact the user we currently send an FCM notification. The problem is that because we don't want to place any drain on the user's battery for a service that they rarely use (although is extremely valuable) then we don't try and run anything in the background - which means that according to the firebase document Lifetime of a message the message will be discarded if the user doesn't open the app for one month.
The referenced doc states:
If the device has not connected to FCM for more than one month, FCM still accepts the message but immediately discards it. If the device connects within four weeks of the last data message you sent to it, your client receives the onDeletedMessages() callback. The app can then handle the situation properly, typically by requesting a full sync from the app server.
How are we supposed to inform the user that there is a message for them?
I understand why such a precaution can make sense, but what options exist to allow us to receive the notification causing minimal impact on the users' device?
Related
I am using Firebase with OneSignal within an hybrid application (Android + JS with cordova app). In some cases the user may become offline and online while he is still using the application.
Note that you can't retrieve a push notification if you don't have connectivity.
So my question is, is it possible to retrieve a push notification if the another user sends a push notification while the first user is offline, and later on this first user retrieves the connectivity (As a delayed push notification)?
Thanks!
Internally, OneSignal uses Firebase Messaging Service, so the constraints should be looked for there.
Firebase has 2 types of pushes: notification messages and data messages. That matters if you want to show a notification straight when a push comes, or you'd like to do some additional processing beforehand.
Then, you can configure Firebase to store and resend every message up to 28 days. Of course, losing a network connection for some time does not prevent a message to arrive.
There is another limitation though: up to 100 messages can be stored per client. So, if there are more than a hundred, it's better to re-request the diff.
And then, when the device finally comes back to the network, you should decide if you'd like the notification to come immediately even if the app is already minimized or the device is sleeping. Here is a part about push priorities.
Finally, to be able to work with Firebase on this lower level, you may need to configure OneSignal accordingly. Here is an instruction telling how to work with the background notifications, if you need them.
I'm creating an iOS and Android native app, using Firebase for sending push notifications.
It's working fine, but when I switch off my devices and send some notifications, after starting the devices, I just receive the last one sent for iOS, and the same for Android.
Is there a way to receive all the push notifications even when the devices are offline and they're started?
Referencing a couple of references:
iOS:
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.
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.
This would mean that only one notification is preserved and that sending a new one replaced the old one. So I don't think it's possible.
Local and Remote Notification Programming Guide
Android:
On Android and Web/JavaScript, you can specify the maximum lifespan of
a message. The value must be a duration from 0 to 2,419,200 seconds
(28 days), and it corresponds to the maximum period of time for which
FCM stores and attempts to deliver the message. Requests that don't
contain this field default to the maximum period of four weeks.
and
Currently, time_to_live is not supported for notification messages on iOS
and
If the device is not connected to GCM, the message will be stored
until a connection is established (again respecting the collapse key
rules). When a connection is established, GCM delivers all pending
messages to the device. If the device never gets connected again (for
instance, if it was factory reset), the message will eventually time
out and be discarded from GCM storage. The default timeout is 4 weeks,
unless the time_to_live flag is set.
and
Finally, when GCM attempts to deliver a message to the device and the
application was uninstalled, GCM will discard that message right away
and invalidate the registration token. Future attempts to send a
message to that device will result in a NotRegistered error.
When a connection is established, GCM delivers all pending messages to the device.
If the device never gets connected again (for instance, if it was factory reset), the message will eventually time out and be discarded from GCM storage.
The default timeout is 4 weeks, unless the time_to_live flag is set.
Finally, when GCM attempts to deliver a message to the device and the application was uninstalled, GCM will discard that message right away and invalidate the registration token.
Meaning it should be receiving the pending messages. Unless the device is factory reset or uninstalled.
About FCM Messages
Messaging Concepts and Options (although this is deprecated and now suggests to reference FCM messaging, linked above)
We have multiple mobile clients (ios and android) subscribed to a channel-msg.
7 messages are being published to channel-msg by the server:
Messages 1-3 were published to channel.
The device got messages 1-3 via native PubNub.
The user turned the device off.
Messages 4-5 were published to channel.
The user turned the device on, and app in foreground.
Message 6 is published.
Message 6 arrives to the device.
At this point (in the "got PubNub message" callback in the device's code), I don't want to perform Message 6, because I must perform Messages 4-5 first.
I can use the history() API to get the lost messages, but with this strategy I am forced to perform the "history check" on each message I receive on the device, before I can execute it.
I there a better pattern/design to handle this scenario?
PubNub History
You don't need to call history for each individual message, rather, you retrieve all missed messages (up to 100 per history call).
Just save the timetoken of the last received message in a way that you can retrieve it when the app is relaunched (NSUserDefaults). When your app is launched, just use the timetoken as the end param (nil for start param) in your history call.
If you get 100 messages returned (the max) then it is likely you have more and you need to call history again (paging through storage) and again until you receive > 100 messages.
Once you have received the last of the messages, use the timetoken of that last message (the one closest to now), use that timetoken to subscribe to get any message between the last history call and your subscribe and continue to subscribe for further messages.
The case here is of using GCM for payload based push notifications. Let's say about 10 odd push notifications are sent to the GCM server in a non-collapsible way so that all of them are queued. The user hasn't got those notifications yet because the user hasn't connected to internet.
If after connecting to internet the user updates the application before receiving those notifications, the registration id for the app is going to change.
Wanted to know, if in this case, would the stored notifications still get delivered to the device or would they be discarded altogether?
I was unable to locate the handling of stored notifications when registration id changes anywhere in the documentation. Could anyone please shed some light over this?
Thank you very much.
I've seen no documentation about this very unlikely scenario either.
The reason it's so unlikely is that once you connect to the internet (in order to udpate the application), it is very likely you'll get the stored messages before you download and install the update.
Now, suppose that you didn't get them before installing the update. When the application is being updated, there's a chance that due to an old bug in GCM, the app will get unregistered automatically if it receives a message while getting upgraded. That's precisely the reason why the GCM docs suggest to re-register to GCM each time the app is updated.
In the unlikely event that this bug happens, you will lose all the undelivered messages stored for your device in GCM server, since your app will become unregistered on this device.
If, on the other hand, the undelivered messages are delayed in the GCM server until after you updated the app, launchd the updated app and re-registered to GCM, it's likely that the stored messages will be delivered, even if the re-registration results in a new registration ID (note that the registration ID won't necessarily change), since old registration IDs continue to work even after a new registration ID is assigned.
All of that being said, you should never rely on all the GCM messages always being delivered. It is never guaranteed. Whenever a user starts your app, you should synchronize it with your server (load whatever data is relevant), and therefore any GCM messages that were not delivered will become irrelevant.
I need to send push notifications (PN) at some fixed time. For example, I don't want to wake my users before 8AM, so I would like to instruct google to deliver PNs at 9AM each day.
Problem is, my users might be spread all over the globe, I really cannot tell what locat time is there... does google give the ability to schedule PNs by local time of registered applications?
PS1: I read about iOS's UILocalNotification (maybe there is similar for Android too) but I don't want to set anything locally, I just want to send the PN from a remote server (with custom data) and put a restriction regarding the delivering time.
PS2: I am using Phonegap to develop the app and I am already able to send instant PNs to certain devices.
You can't instruct the push service (neither APNS nor GCM) when to deliver the notification. Both services try to deliver the notification as soon as possible (assuming the device is connected to the internet).
The only exception to my previous statement is that in GCM you can use the delay_while_idle flag to prevent the notification from being sent while the device is idle. This would prevent delivery while your users are not using the device.
If you want the notification to be delivered at a certain hour of day, and to consider the local time zone of the recipient device, you must manage it in your server. When your app sends the device token / registration ID to your server, you can send the local time zone of the device. Your server will know the time zone of each device, and send the notifications at the preferred hour.