We have a back-end server that sends FCM push notifications with a data payload to Android and iOS devices. I am working on the Android app. When the app is in the foreground, onMessageReceived is called and the data is retrievable from RemoteMessage. When the app is in the background, a system notification is posted. A user clicks this and the data is retrievable from the Intent extras. All is well.
I am trying to figure out how to handle the case of multiple notifications coming in while the app is backgrounded or dead. The desired behavior is to "suck in" any active notifications and be able to retrieve their data payloads. I can get and clear (cancel) the active notifications using the NotificationManager (API >= 23), or implementing a NotificationListenerService. I have not been able to figure out a way to get the data payloads associated with them. The StatusBarNotification.getNotification().extras seemed promising but did not contain the data. I have even used the Android Studio debugger to inspect the notifications returned from getActiveNotifications() and have not found anything.
I think the "correct" answer, from my research, is to send the "notification" portion for iOS pushes, but omit it for Android pushes (ie. data only), and then post my own notifications locally on the device when my app is not in the foreground. Then onMessageReceived should always get called and I can save away the data payloads and have complete control. However, I am not sure we can change the back-end server to support a split Android/iOS path at this point. And from I've read, I have concerns about the service not being called on certain devices if the app is killed.
So, does anyone know of a way to retrieve the data payload of other active notifications? Or have alternative methods of going about this without requiring back-end server changes?
Thanks!
I think the "correct" answer, from my research, is to send the
"notification" portion for iOS pushes, but omit it for Android pushes
(ie. data only), and then post my own notifications locally on the
device when my app is not in the foreground. Then onMessageReceived
should always get called and I can save away the data payloads and
have complete control.
this is the correct approach. (currently the only available)
However, I am not sure we can change the back-end server to support a
split Android/iOS path at this point.
We are working on improving the API to better support your use case.
Unfortunately I cannot share an ETA for that work.
And from I've read, I have concerns about the service not being called
on certain devices if the app is killed.
Those devices would not receive notification-messages neither :( .
Those devices don't even receive AlarmManager events, and neither system broadcast.
If you encounter such device please contact the manufacturer and let them know that their behavior is not standard and it's breaking your app.
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 an app with different notification types it can receive (for example News and Podcast). Currently it has two simple switches where the user can enable and disable those different notification types. It works by just subscribing and unsubscribing from the corresponding Firebase Topic for the type. The clear advantage is that the device only receives the notification the user wants and does not have to filter them locally => battery and data efficient.
Problem is, I want to combine it with the new android O notification channels. Am I right to assume that the only way is to just subscribe to all topics in Firebase and have the user manually disable unwanted ones in the android settings?
Is there a better way that saves more battery life (by not receiving all notifications)?
The Notification Channel (a feature only needed for Android O -- presumably onwards) is (like) a parameter that you would (typically) use to sort/manage the notifications you build locally. --
Android O introduces notification channels to provide a unified system to help users manage notifications.
It doesn't necessarily disable receiving the notifications that you don't want to receive, but (AFAIK) notifications built without the Notification Channel won't show up/display in Android O (not received != not displayed). i.e. Your device may actually still be receiving the notifications, but just isn't displayed.
For Notifications sent through topics, so long as the corresponding registration token is subscribed, it is the expected behavior that the client would handle it accordingly.
With all that said, what you already have implemented (if I understand your post correctly -- subscribe and unsubscribe to topics based on a switch of some sort) is already the simplest as it could get.
If you want to totally disable notifications completely, you could call deleteInstanceId(). See my answers here and here for some additional info.
I am pretty new to the mobile development scene and there is a very basic question to which I cannot seem to find the answer. Here is the scenario.
I have a mobile application. That application is connected to a server that I own. To use the mobile application, users have to login using unique credentials. Now lets say there are certain events on my server, about which I want to notify a particular mobile application user. Can my server proactively send a signal / data to the particular mobile app instance [using sessions data perhaps] so that a notification can be displayed on their screen?
Polling by mobile application towards the server to look for such events is not allowed / feasible.
I can speak to an iOS solution. Android surely has very similar functionality.
There are 2 ways to accomplish this:
Silent push notifications
Background fetch
A silent push notification can be, well uh, pushed to devices without alerting the users. This means that upon reception of the notification, the app can start downloading what it needs from your server. You will need to set up proper backgrounding for this to work properly. Otherwise, the notifications will be queued up and will only take effect when the user opens your app the next time. Start here for push notifications. The payload you send is what controls the notification.
Background fetching is process where your iOS app gets woken up by the operating system (iOS) periodically to allow you to perform a task. This task can be fetch data from a server or anything else you want pretty much. This is probably the best of the 2 solutions given that push notifications are not guaranteed to be received and this puts the onus back onto each device to fetch their own data as opposed to you creating a whole back-end system to perform the push notifications. Start here for background fetches.
You mean something like push notifications? You can read this tutorial (or any other tutorial on google) about how to implement push notifications in your app:
http://www.vogella.com/tutorials/AndroidCloudToDeviceMessaging/article.html
Lookup about push notifications on each of the platforms you're talking about.
Plus look into some live web apps, two that come to mind are meteor.com and nodejs
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.
I am creating a app in android 4.0.3 i.e ICS version, which connects to the server when client gets login into the app.I am trying to get status of an client when he gets online or offline through server & seen onto the app screen.I am unable to proceed. Can anyone say me:
Is it possible to get the status of an user through server?
1-- How to proceed for first step...?
2-- How should I get a response from the server that the client is connected & viewed to other client example - when we login into skype our status shows available with green radio button, In same way how can I get it.?
It ll be very help full, If anybody guide me.
Many Thanks..
I'm assuming you're trying to develop a chat app ?
If this is the case, try using an XMPP library. XMPP is widely used for chat apps, including Facebook chat (and Google talk I think) and there are plenty of open source libraries available.
Otherwise, if you only want real-time notifications as a part of a bigger picture, try using push notifications. Google supports Cloud to Device Messaging (C2DM) for android. It allows to have push notifications to a specific device without you having to deal with persistent connections, battery and CPU use .etc.
C2DM approach comes down to this. When a client connects to your server, get a list of his friends and their 'C2DM IDs' and fire a C2DM push to their devices. This push is delivered to your app, and you can respond to it by firing a notification, or update UI .etc. (Your app doesn't necessarily have to be running. Push notification is delivered via a specific broadcast, and your app can register a receiver for it to wake up.)
Keep in mind that there is a quota for C2DM messages per device, per app and also a limit for the payload per message. So you're not supposed to send massive files via this. Just a notification to your app, so it can call your server and get an updated list, instead of polling.
You can get more info on C2DM and code samples here. https://developers.google.com/android/c2dm/
Hope this helps.
You may have moved on, but I'm posting for anyone who would run into this one in the future.
Firebase is a good solution to use in this scenario, if the app is always running when you want communication to happen. (It will not wake up your app as C2DM/CDM does, unless you have a service running all the time and still wouldn't wake up if the device is asleep... AFAIK)
It may be useful for some scenarios, but may be not for a chat app as you want the device to wake up when a message arrives.
Note that they have limitations on the free subscription though.