I want to show notification only app is close or background or in different chatroom. but I don't know which is better Solution.
stop send push notification when another device foreground
just send push notification anyway and don't show the notification in another device when app foreground.
In first solution I need to get another device information from server like in which chatroom or in which activity or in foreground it make my app and database more complex but maybe it reduce the network usage.
In second solution just send notification anyway and receiver device just ignore it but maybe big network usage.
Most apps that I know off use the second approach: they always send the FCM message, and only show it when needed. That also means that they usually only send a so-called tickle message, which contains very little data and whose main purpose it is to wake the app up.
Related
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.
I am wondering if I can use parse as a notification service for the backend instead of to notifying the user. I am wondering if sending a push notification can start a background activity to run some code in the background. Would this be possible or should I try a different service. If so, could you recommend any other services and/or solutions to the problem. All of the other services seem to be the same and the only other solution I can think of is scanning the server every little while in the background. I am afraid that will use too much battery life.
Sure, you can do this with a combination of push notifications and their proper handlers.
Send the push as a silent push. As noted in this SO post, silent push reception is the default- you have to add extra code to interact with the user.
When you receive it, process it appropriately to run background code instead of interacting with the user. You can read more about how to receive and process a push in the Parse.com Push Guide for Android.
I'm looking to make my app more responsive by having it automatically download some data (around 10KB) when it receives a notification. My two options (I think) are:
Try and pack all the info I need into the 4k payload limit - this may be possible, but certainly wouldn't help with iOS/WP implementations, as they have much lower limits. It also would be pretty inextensible, and I'd need to hand-craft the messages.
Send a notification which the app would react to and download data in the background.
If it's going to be 2, can I do that? Can it be done when the app isn't already running in the background or foreground?
For some updates I'd like to show a notification to the user. Can this be done in the same notification, or do I need to push another one?
Any similar info about iOS much appreciated, but not essential for answering the question!
When using Google Cloud Messaging you create a broadcast receiver which receives the GCM push notification. The broadcast receiver can either handle the notification on its own or start an intent service (which is better suited for your logic that downloads data from the server, since it runs on a separate thread, and doesn't block the main GUI thread). You can display a notification and download data from your server as a result of the same notification.
Look into BroadcastReceiver, once registered you can create a listener inside of your activity that will be called once the notification has been received.
In Android, I want to run a service which periodically connects to the server gets the message
and displays the message in full screen to the user irrespective of what the user is doing.
Should I be using the above approach or use GCM to deliver messages to the client device.
What component do I need to use to show a full screen message to the user ?
Notification requires the user to pull down the notification bar and select the notification. I want the message to appear right away in full screen on the user device.
Please let me know what component of android I should use to achieve the above step.
Thanks
A GCM message should do. The additional information needed to show the message can be represented via JSON and parsed by your GCMIntentService. As long as the payload is within 4k the messages will be delivered. The maximum retention time (at the moment) for a GCM message is 4 weeks. You might want to take that into consideration also.
As for displaying the message on the screen, it is possible to register broadcast receivers for an Activity. Alert the broadcast receiver and display the message if the activity is on the foreground.
GCM is used for push notifications. For what you want to do, GCM is not needed at all if you simply want a service running executing some code at your set interval and polling your server. If you want to show a full screen message, simply create an activity and display that each time you execute the code in your interval. Now if you want that message to automatically disappear after a few seconds, then create a custom Toast message.
GCM will simply add another complexity layer that you don't need I think.
What's the best way to have a status bar notification persist when the phone is turned off and on again? The only solution I can think of is to create the notification in a Service which starts in response to the BOOT_COMPLETED_ACTION Intent.
The only solution I can think of is to create the notification in a Service which starts in response to the BOOT_COMPLETED_ACTION Intent.
For raising a Notification, you can probably get by with just doing it in the BOOT_COMPLETED_ACTION BroadcastReceiver, rather than delegating it to a service. However, I agree, this is the only way to do it AFAIK.
Just be sure you do not irritate your users by doing this. Most people expect a relatively clean slate when they reboot their phone. Android assumes that notifications are no longer relevant with a reboot, which is why they do not persist.
So, for example, suppose you were writing an email client, and you use notifications to let the user know about unread messages. The answer should not be "redisplay the unread-message notification after a reboot". The answer should be "check for unread messages after a reboot, and raise the notification if there are unread messages". This way, if there are no unread messages (e.g., user had the phone off for a while and took care of their email on their PC or tablet), they do not get a spurious notification.