I know that in never version of GCM you can dismiss notifications based on userId and not device id. This essentially syncs this action with all devices that user is using with same google account. Documentation page for this can be found here and it is quite helpful
http://developer.android.com/google/gcm/notifications.html
Only thing I don't understand from there is:
Do I need to write code in my app to contact the GCM sever or my own server to trigger dismissal on other devices or does this happen automatically when notification is dismissed or opened ?
This is the part that led me to think that you need to do it manually but I am not certain :
"You should design your app to handle cases where the app receives a dismissal message, but has not yet displayed the notification that is being dismissed."
Yes, you have to write code in your app to trigger the dismissal message, as well as handle it.
Note: A notification dismissal message is like any other upstream message, meaning that it will be delivered to the other devices that belong to the specified notification_key. You should design your app to handle cases where the app receives a dismissal message, but has not yet displayed the notification that is being dismissed. You can solve this by caching the dismissal and then reconciling it with the corresponding notification.
This makes sense, because GCM doesn't know how your app handles an arriving GCM message. Your app might display a notification (which needs to be dismissed if it was already handled on another device belonging to the same user), or it might perform some background sync with the server (in which case no dismissal message needs to be sent).
The point of this new feature is that you send a single message to a single notification key instead of sending it to multiple registration IDs, and an app installed on any of the devices belonging to the same user doesn't need to know the registration IDs of all those devices. It only needs to know the notification_key in order to communicate with the other devices.
i think its your serer that need to be contacted
this keeps the flow consistence and also , when contacting GCM server to send message you need to provide your API-key and project Id ... and this is critical to be stored on the mobile application.
thats why you should contact your server, in his turn, your server will contact GCM server
this is my opinion.
Related
I am currently trying to make a personal location application between 2 devices on Android.
The concept is simple: I install my application on my phone as well as on that of my wife and each can geolocate the other.
(This application is strictly personal)
To achieve this, I thought of using sending notifications by FCM.
Telephone A sends a request to telephone B which listens via a service for the reception of a message.
When phone B receives the request, it returns the GPS coordinates via FCM so that phone A displays them on a MAP.
(I also have the possibility to store the coordinates in a database instead of sending back an FCM message)
But FCM's documentation says:
"When your app is in the background, notification messages are displayed in the system tray, and onMessageReceived is not called. For notification messages with a data payload, the notification message is displayed in the system tray, and the data that was included with the notification message can be retrieved from the intent launched when the user taps on the notification."
Of course, this reduces the scope since it forces the user of the phone receiving the notification to click on it to activate the actions of the service.
Can FCM still meet my needs through another channel?
Are there other options to send a "request" to another phone?
(I know that this kind of application exists on the PlayStore, but I want to try to make mine :-))
The key word in that section from the documentation you quote is notification messages. Firebase Cloud Messaging supports two types of messages:
Notification messages, which are display by the system when the app is inactive - and delivered to your application code when the app is active.
Data messages, which are always delivered to your application code.
It sounds like you'll want to use data messages for this use-case
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 building a newspaper-like app and I would like to know how many people received the article's push notification vs how many actually read it.
I was thinking to implement a way in which when the notification is received the app wakes up and send a request to the server saying "Hi I'm _____, I've received the notification of the article ____" and store it in the database. Then afterwards if the user click on the notification and goes to read the article I send another request saying "Hi I'm ____ and I've read the article _____" and I also store it on the database. Afterwards with some queries I'm able to understand the percentage read/received.
I don't understand if it's even possible to wake up the app even if it was not opened by the user in a while and send a request to the server (for background is meant that the application is not launched or that is in the cache ?).
I would like to achieve what they did with Whatsapp:
I receive a new message on Whatsapp
I don't open the app
I go to WhatsApp Web
I open the conversation on WhatsApp Web
The badge and the notification on the phone goes away because I read it somewhere else
I think that that feature is achieved with silent push notifications that just update the app badge and clear the read notification.
Thats a very nice question on how to implement such silent notifications. There are few variables here that we need to consider and deal them in a different way.
Push notifications sent to the users - Some of them would have received it, Some may not have received it at all.
Pushing multiple notifications to the same user in a small amount of time - It becomes difficult here to track the exact notification user opened the app. Because user might have read all the news that received notifications in a single attempt.
The actual content displayed to the user in the app - User might have opened the app because of notifications. Some times he might have seen the notifications and then opened the app directly without interacting with the notifications.
So this is how the implementation can be.
Implement push notifications for the app
User receives the push notifications and the notification badge shows Number (1).
Now when the user views the same news story in any other medium (Your own Mac App or PC app). Server is notified of the users action and the news he/she/whoever just read.
Now the server knows it has sent a notification and it is not read. When you receive the read notification, you can send a remote notification that can be handled by the app in background and update the badge.
Check out this link for more details on how to handle notifications in various modes.
Apple documentation also can be referred here for background mode - remote-notification.
So you will be making your app run in background with certain settings to respond to silent notifications and update the badge just like WhatsApp. I hope this helps.
I've already implemented such thing in one of my app, and it's actually tricky.
You'll have a lot of use cases to handle.
First thing (but you seem to already know it): Apple does not provide
any callback to say : "this notification was sent"
Second thing : when your app is killed (not even in background), nothing at all can be done with your notification, meaning your app won't be able to wake up and read the notification, and therefor do something. The only thing you can do is changing the badge number, even if your app is killed.
Third thing : when your app is in background, you can wake up your app during 30sec. During that time you can send a request to the server, but if it takes too long, the process will be killed by the OS.
Saying that, here is a quick explanation of how you could implement the system:
You'll need on the server side to save in your data base any notifications that were sent. As soon as they are sent, save them as "pending"
On the app side: if your app is in background, as soon as the notification is received, you can wake up your app to send a request to the server. Then in your data base, your notification status will change to "receive" or "notified". If your app was killed, when the user launch your app, send a request to the server to ask for all notification in "pending" state, that way your app will be up to date, as well as your badge number.
If the user click on the notification, this will open your app directly on the article, that way you'll be able to send a request and say to your server that the article was received and read.
If the user read your article on the web side, send a notification. Set the notification badge number with the number of actual "pending" notification in your data base.
Hope this will help you in addition of the answer of #Prav :)
try this Notification Listner service https://github.com/kpbird/NotificationListenerService-Example.
Reply from Apple Developer Technical Support:
Hello Matteo,
Thank you for contacting Apple Developer Technical Support (DTS). Our engineers have reviewed your request and have concluded that there is no supported way to achieve the desired functionality given the currently shipping system configurations.
So at the end of the games IT'S NOT POSSIBLE
You want to sync your app with web app or website than once you send notification to application than set notification to particular ID.If user read that message from your web then send push notification again with different message and handle in service or broadcast receiver after that cancel notification if received message contains different message.you can also use Notification Listener.Refer thislink
Refer this link for ios.
Hi #Smile Applications after reading your question I would suggest you see OneSignal website. OneSignal will allow you to send notifications to your subscribed users. It will also show you how many users are using your app and how many of them have received your notifications. If you want to send notifications and track them from the app itself you can use their API. It is easy and I have implemented this in Android and soon will be implementing in IOS.
Now the second part of your question about knowing how to track how many users have read/opened your notification and on which activity they are on you can use Google Analytics. It will allow you to see from which part of the world your users are using your app and which activities of your app are being opened most. It is also easy and I have implemented this also in Android and soon will be implementing in IOS too.
(The following question is for mobile platforms in general (iPhone, Android, Blackberry))
We are integrating chat functionality into our existing application. I designed the system with a .Net web service and Sql Database to keep track of chat messages. Everything's working fine so far, when the chat window is open.
I need a way to notify the user of a new message when he/she is not currently viewing the chat screen (meaning either the app is not in the foreground or they are in another section of the app (not the chat screen).
Obviously, push notifications would be perfect here, but I'm not sure when I should be sending pushes.
How would the client sending the message know whether or not the other guy is viewing the chat screen? Should I just be sending pushed with every single message and have the receiving device decide whether or not it needs to pop up a window or display something in a nofication bar?
It seems like overkill to be pushing every single time a message is sent. How is this normally done?
Any ideas at all would be greatly appreciated.
Thanks.
First and foremost, keep in mind that your server will act as the broker for all messages passed between different chat clients. Here's how this could work:
User A initiates a message for user B
Message gets sent to the server.
Server determines that this message is for user B.
Server initiates a push notification and delivers the message to user B.
Now why would you need to push every single chat message? Because the only other way for your users to get notified would be to poll your server for new messages. Constant polling (at whatever rate you determine) is extremely bad in the mobile realm due to limited resources (battery, networking, etc.)
In a push notification scenario, it is up to your application to handle the logic of whether the user is notified on receiving a new message. What this means is that when user B receives a new message from user A, it's up to you to decide if you wish to notify B (i.e. bring your app to the foreground) or not. In either scenario, you want to use push notifications instead of polling.
On a similar note, user B does not necessarily have to know that user A's application (your app) is in the background which is why you will need to handle that logic (within your app) appropriately.
Push notification normally is applied to the application if it is not in the foreground. It is a way to wake-up the application to handle a new transaction from the server. Basically, a push notification is to be done if the client is running in the background and a new message is ready to be fetched from the server. As long as the new message is not fetched, if other messages arrive on the server, a push notification should be sent to the application.
Push notification is not necessary if the application is still running even if the user is viewing other screens of the application. It is however important that a thread is handling the connection to the server which is "patiently" waiting for transactions from the server.
One question, what protocol are you using for the messaging?.. Is it OMA IMPS protocol?
I'm using C2DM to send notification for my android App and it is working fine. But i am able to get only one notification at a time. so that while receiving the notification, it replaces previously received notification.
So how to receive multiple C2DM notification, like receiving normal SMS?
Give the messages different collapse_keys. Here's an excerpt from the official docs:
An arbitrary string that is used to collapse a group of like messages
when the device is offline, so that only the last message gets sent to
the client. This is intended to avoid sending too many messages to the
phone when it comes back online. Note that since there is no guarantee
of the order in which messages get sent, the "last" message may not
actually be the last message sent by the application server. Required.
On a side note; you are not supposed to use the push messages too frequently:
Are you sending C2DM messages too frequently? If you need to
communicate with your application frequently over a short period of
time, C2DM is probably not the best solution. Instead, consider
implemeting XMPP or your own protocol to exchange messages, and use
C2DM only to send the initial notification.