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.
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 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?
I know that we can't set repeating alarms of short intervals in Android because it drains battery and has other such effects. Well, technically you can, but android will automatically push it up to a minute citing "suspiciously short duration".
So how exactly does an app like WhatsApp or Facebook constantly update our messages or newsfeed? I thought they fire an Alarm each second, but clearly that is impossible because the OS will push it up to a minute anyway. Using Handlers/Threads is off the question anyway because they don't fire when the app is closed, but WhatsApp updates your messages even when the app is closed.
So what exactly do these apps use if not AlarmManager to do the aforementioned task, and if they use AlarmManager, how do they set the short duration?
They have a service that uses push messaging. So basically they open a socket connection to a server and sleep until the server sends data to them. Its an interrupt mechanism, not a poll.
Not specific to any service like WhatsApp or Facebook, the idea behind this whole system works like this.
For Android in particular (or in general),
Your device registers with the Google Cloud Messaging (GCM) service
It allows GCM to create a HTTP persistent connection with your device
This connection is lightweight and persistent (stay alive for a long time)
With this, you will be able to consume these services, sending messages in this fashion.
Your Server ---> Google GCM Service ---> Target Device
When you send your messages, do not include the whole message itself. You should keep it lightweight by just sending simple messages to notify the targeted device that it has new information to be downloaded.
At your device application, you set up permissions and intent to listen for these push notifications. Whenever, there is new messages, you will make a request to your server to receive the corresponding messages.
Here's a guide to explain in depth: https://github.com/codepath/android_guides/wiki/Google-Cloud-Messaging
Cheers! Happy Programming!
One user manages mobile users via a website interface. By clicking on a button on that website I have to display the current position of the chosen mobile user. So what I need to do is send something to the mobile app to trigger sending the GPS position to my server. My website then starts polling the database to check every 10sec whether the GPS coordinates have arrived.
Questions:
Is it possible to use Push Notifications for this purpose? I already implemented it, so everything would be there.
Can I do that silently, so that the mobile user doesn't get notified? I have found something called Silent Push Notifications - is that what I'm searching for?
I have to do it on Android and iOS.
On Android it is definitelly possible. There is no default behavior (such as alerts/badges/sounds) to notify the user of the app that they got a notification. When the app gets a push notification, a broadcast receiver is created and its onReceive method executed. You can have whatever logic you need in that method, though if you require a logic that requires a long time to execute (such as server calls), you should start an intent service from the receiver and do you logic in the service (get the location of the device and send it to your server).
On iOS I believe it is possible since iOS7. Until iOS7, the application logic for handling the push notification would only be triggered after the user clicks on the notification/alert to open the app. iOS7 enable the app to do background processing as a result of the arriving push notification. I believe you should use the {"aps":{"content-available"=1}} payload in this case (which is used for background content downloads), since you don't want any payload that would be displayed to the user.
For android you have some ways to implement the push service:
GCM - http://developer.android.com/google/gcm/index.html:
MQTT - http://mqtt.org/
implement your own persistent connection.
All of them have their advantages. If you need a ack that the mobile client got the msg you should use MQTT. It is also faster than GCM because of less overhead and you don't have the GCM server in between. On the other hand GCM is easy to implement and you don't have to worry about the persistent TCP connection from your server.
Also the silent way is possible because you just trigger a service each time. so if you don't want a notification, the user don't get it.
I am not sure about iOS. For iOS6 it was not possible to implement your own service, which is necessary to "wake up" your app. I am not sure about about iOS7. So for iOS6 you definitely need to use Apples push server.
Is it possible to send push notifications to an android application without using Google server: C2DM?
So, I would like to have my own server which sends notifications directly to the app, but I'm not sure how are the notifications perceived by the device, because the device needs to receive notifications even if the app is not running and the notifications should appear in the notification center.
I think that the guys from www.airpush.com have managed to this, but I'm not sure how.
Can anyone help me with this please?
UPDATE:
Also I would like to know how to display the notifications in the notification center if I don't use C2DM? And if it is possible to configure the notification center to receive notifications from my server even if the user deletes the application developed by us, application which registered that device to receive notifications.
I want to send 3-4 notifications a day, but these notifications need to appear in the notification center and they should go only through our server. How can I configure the notification center within the app to make requests on my server for push notifications.
Thank You!
There is a solution from UrbanAirship called Helium push. According documentation Helium:
Works on Android 1.6 and higher
Does not require a Google Account
No default pushes per day limit
No default pushes per minute limit
Works on Amazon devices (e.g., Kindle Fire)
End to end Urban Airship support (i.e., API to to device)
Best throughput
The problem is that you need development app key for using this one.
Take a look at MQTT:
MQTT stands for MQ Telemetry Transport. It is a publish/subscribe, extremely simple and lightweight messaging protocol, designed for constrained devices and low-bandwidth, high-latency or unreliable networks.
It can be used (and was used in some applications) to implement custom server push solutions. One of the most well known applications using MQTT is Facebook Messanger.
You can easily find more information on MQTT in the Internet, e.g. in this SO question or in this blog post.
According to the FAQ on airpush.com, they're not using real push notifications but rather polling the server a few times per day. One reason I think this is a viable solution for you as well is that Android's C2DM apparently makes use of the Google Play Store, so it won't work on devices distributed outside of the Google eco-system. With over 5 Million Kindle Fires having sold already, that is worth thinking about.
From Airpush FAQ:
When executed once from the main activity of an Android™ application, the Airpush client utilizes Android™ OS's AlarmManager framework to schedule ongoing server polling events a few times per day. If an ad is polled from the server it is cached until optimal display time, which is algorithmically determined by the server.
Without using C2DM there's not option for a "real push notification". Because (afaik, correct me if I'm wrong) an android device registers at google (they can still deinstall malware from your phone via remote) and with this ip they are able to do a push notification. All other solutions could tend to be a "register at a server, keep the connection alive and wait for requests" or something and tend to be more battery-inefficient.
Parse has an excellent push notification service for Android, very easy to setup. More info here: Parse Android Notification Doc
If you want the user to only receive 3-4 messages per day and your messages are not bound to specific arrival times, you don't need pushing mechanisms.
Just create a service in your app that checks your own web service 5-10 times a day. If there is new data, make your app display it in the notification center.
If you don't want to have a service running all the time (like many messaging apps do), you can set up alarms (using the Android AlarmManager framework) that wake your app up regularily to check for new messages to display.
And if it is possible to configure the notification center to receive
notifications from my server even if the user deletes the application
developed by us, application which registered that device to receive
notifications.
That sounds like you want to write a virus or root kit ;-) You could use e-mails for your messages instead.
UPDATE 2013-12-30:
As just noted in my comment, rebuilding what GCM does is not a nice approach. It's enough when Google Services already load the device with this functionality. If your goal is just that Google does not see what messages you send to your users, you might aswell encrypt them. For Google not being able to actually read your messages, the client app should generate a key and send it to your server. All messages you send via GCM can then be encrypted using that key.
If you just want to circumvent Google's restriction on the amount of messages sent to users, you could pack multiple messages into one GCM notification and show them one after the other. But then again, we are back at some kind of polling solution as described before, with the exception that the user does not need to have internet access when you want to show the messages as they are cached on the device.