Everybody tells me that polling server for new data is stupid if the server is yours and you should implement push with GCM instead. Well, I agree and have done so but, I was wondering, how often can or should you perform push?
I have a simple app where people post stuff to the server and have a feed of everyone else's posts. The method on the server that does the saving to the database also triggers the GCM Push at the end, so Google sends out the push notifications to everybody and everybody then requeries the server for new posts, containing the post weve just made.
But, what if I have, lets say milion users and a new post is created lets say every minute. This will mean that app will connect to server every minutes and will kill the battery. So my question is, how often you perform Push? Wouldnt in this case polling every 10 minutes be actually better for battery, right?
I know this example is kind of crazy, having milion people in your feed, but its just to make a point, because I cant imagine how this would scale. I figure Google will handle sending million gcm messages at once no problem.
So the question is, is there a limit after which Push is contraproductive? I guess its kind of a first world problem :D but cant imagine Facebook handles stuff like this.
Thanks!
Push notifications are welcome when the server has important new data to show to the user (and by important I mean important to the user).
I believe that if any app sent me a notification every minute I would either disable notifications from that app or uninstall that app. You should be very carefull when deciding what updates to send to your users as push notifications, in order not to antagonize them. If your server can send push notifications very often to the same device, you must have settings options in your app that can reduce the frequency of those notifications.
Push notifications are usually relevant when the app is not running (or is running in the background). When it is running in the foreground, polling the server is probably a better solution (given the disclaimer that you can't rely on the push notifications being delivered every time).
In your example, I'm not sure I'd want to be notified automatically about each new post in the DB. Even while I'm using the app (i.e. it's in the foreground) I wouldn't want it to update with new posts automatically. Even facebook don't update the view automatically (they show you on top of the screen that you have new posts, and you have to pull the list view down in order to load them. And when the app is not running, I'd want to be alerted only about important posts (for example, posts from specific users). When an app sends me too many push notifications, I go to its settings to reduce them.
I can't give you a numeric figure of a reasonable frequency of push notifications, but I hope my answer helps. In short, you don't have to worry about GCM's technical limits. You should worry about the user experience.
Related
Also is there an effective way to track, by the backend server, if the app being used by a user is in the foreground?
What are the best practices and recommended ways in mobile app development to get the latest data as soon as possible from the backend server to mobile apps being operated in the foreground?
Generally, for staying up to date, there are lots of solutions based on your case.
I'm going to divide them into two approaches:
1- You pull the new data when some specific conditions meet (eg; Intervally or based on user actions).
2- Data should be pushed to your app.
The first approach is quite obvious if you need to be up to date at some intervals, you can call networks APIs at intervals and fetch the latest changes.
In the second approach,
In iOS operating system, while app is in foreground state, There are Silent Push Notifications and WebSockets.
Silent push notifications is kind of push notification which can carry payloads and deliver to your app silently either your app is in background state or foreground.
There is some limitations to this kind of notification, based on some conditions OS will decide to deliver push notifications to your app or not. and also there is payload size limitation (up to 4Kb)
You can read more about this and its limitations in Apple Documentations
The second approach is pretty straightforward, It needs to use third-party libraries (like StarScream) to open a socket connection and get the latest updates real-time. There is no limitations in this approach for times that server pushes data to your app or the size of payload you are receiving. so you can be notified from last changes by your backend server every moment while app is in foreground and connection is alive.
Choosing between these two approaches is completely depends on your case.
If you should receive the update a lot of time in an hour and transferring lots of data so I recommend you the WebSocket approach, otherwise push notification will be sufficient and easier to implement.
I am writing the app that can chat with other. I saw some project : Parse, GCM,... It is exactly good. But I need to know how it work. Because want to use my own.
In my case, I saw when other send his chat, then it's almost display on my screen after 1-2 seconds. Then I think what happened:
My friend post his chat to server, and server send request to app with ID ( unique).
In my app, there have a service, which send request to this server each 1 second to get new chat, or notification. If found, display in my device.
Is my above ideal true? I am going to write about chat with client-server.
Give me reason why down vote.
Thanks :)
In my app, there have a service, which send request to this server each 1 second to get new chat, or notification. If found, display in my device.
Implement as you say lead to energy(own app services use)/IO(every net request each 1 second)/server(large amount request from clients, and most of request is useless because nobody chat in 24h) waste, and message may lost or can't get notification in time if the service is killed by system(or don't start).
However, your method will work if you find a way to keep your service always alive, and make well design for servers to support large amount requests from large multi clients.
For the better, you can use dynamic look-up algorithm that keep a long interval if there is no notification recently.
I'm currently making an app in Android that is checking an API which returns two things. Some text and a colour.
However I want this to be checked for updates every 15 minutes in the background and check every 5 seconds when the app is open. When running in the background it should give a notification if the status is changed.
Now I have checked numerous stackoverflow q&a's and forums, docs etc.. But I can't seem to find a good baseline for what I need. So many documentation that contradicts eachother.. I think that I need an Alarm Manager or a Service... but what do you guys suggest for my problem? The app may not harm the battery too much.
What I really would like to have is that the application doesn't have to "poll" the server every 15 minutes but that the application gets interrupted like.. "hey, there is a new status update". I can't imagine that messaging apps are constantly polling a server for updates? I haven't found much information about that topic... Any help is appreciated. Not asking for code but directions to get where I want to go.
Many thanks
If you're looking to poll the server every X seconds/minutes, AlarmManager(android guide, tutorial) is exactly what you need. However, as you point out this is probably not the best way to go about things. While the app is open you may want to look in to passing messages between the device and server via an open Web Socket. Once your app is closed you could, instead of the app polling the server, have the server push a notification, via GCM or some such, to the app when an update is available.
If you are doing both the server side project and the mobile application, You can use Any messaging service rather than polling for the server, Because there has to be a pusher implementation from the server side to push the status to the MS.
For now GMS is free, I hope it will remain the same :). Otherwise, You can use AlarmManager and IntentService to achieve your goal.
I'm creating mobile application for iOS and Android. The problem is when any data has changed on server, I cannot notify mobile devices.
I have found 3 solutions, each have minus and pluses.
Use push notifications. Since iOS always shows a notification to user this is not a solution at all. Also I cannot know if the notification will go to device or when it will.
For every X seconds ask server if any change exists. I don't want to do that, because creating too many HTTP connections and closing them is not a good idea I think. Also if the data is changed right after the device asks, the info change on device will occur late.
Use web socket. My application's one time usage expectation is ~2 minutes. So web socket looks like a good choice, because app will be terminated or go to background state quickly and battery consume won't be much. Also all the server side data changes will come to the device just in time. But I don't know much about web socket. Is my opinion acceptable? Also how many concurrent connections can be done by my server. Is it a question too.
Here are my all solutions.
The document would suggest assumption 1. above is incorrect.
If you read the The Notification Payload section, you'll come across this;
The aps dictionary can also contain the content-available property. The content-available property with a value of 1 lets the remote notification act as a “silent” notification. When a silent notification arrives, iOS wakes up your app in the background so that you can get new data from your server or do background information processing. Users aren’t told about the new or changed information that results from a silent notification, but they can find out about it the next time they open your app.
https://developer.apple.com/library/ios/documentation/NetworkingInternet/Conceptual/RemoteNotificationsPG/Chapters/ApplePushService.html
I think for the most part this depends on what your app is doing.
I would say you should use a combination of #1 and #2.
2 - At the very base level if you need information from the server you are going to have to make a request. If this information needs to be up to date then you can proceed to make a request for the information when the ViewController is loaded. If you need this information to update as the ViewController is loaded then you will need to make subsequent requests every X seconds... In addition to this if your user is interacting with this data and sending an update to the server you can check at this point if the data is up to date and alert the user as well as return the current data.
1 - Push Notifications operate off of the 'send and forget' protocol. The notification is sent and is not verified if it is received or not. This is used as a supplement to #2 and is 'nice' but should not be depended upon.
Push notification is the intended way (from both Google through Google Cloud Messaging, and Apple through Apple Push Notification Service).
Both option 2 and 3 are frowned upon as they affect battery life, and they are unnecessary as most cases scenarios can be covered by push notifications.
I am building an app that shows user's friends' real-time locations on a map.
Each user updates his currnet location on the server (Parse.com) every defined interval (time and distance).
When a user opens the FindFriends activity, he'll get a map with markers on friends locations.
The friends locations data can be retrieved in two methods:
When activity is running, I am calling an AsyncTask that will download locations data from the server in a while loop (inside doInBackground), and after each time I call publishProgress() to handle the changes on the map.
I wrote a cloud code that is called every time a user updates his location on the server, which sends push notification to the relevant users (the user cant see the notification). When the FindFriends activity is running, a broadcast reciever is getting those pushes and update locations data on the map.
My question is: Which method is better for my needs or maybe I should do it differently? Of course I would like to keep battery consumption to minimum but not at expense of getting almost real time data.
I don't really think that this is an appropriate question, since you really should just make a prototype using each implementation, and see which is more performant in your particular use case. However, I can say that I definitely prefer the cloud solution. I've used GCM to implement a messaging client, and from my testing the updates are definitely really quick (very little noticeable lag time, when testing two clients side by side). So, I don't think that implementing it with GCM would negatively impact your user experience, and it does have the plus side of eliminating pointless server polling when, potentially, no updates could be present - which saves on battery.
If you want real time data then push notification GCM is not a good idea because, there is no guarantee that all users will get push notification in time. Sometime you will encounter delays in push notification.
Under given circumstances AsyncTask or Service can be a good way to perform required task, if they are handled properly. You should have control on AsyncTask/Service so that you can stop it any time you want.