For one of the screens in my android application, I need to listen to server indeterminately - ie; I have few fields in the screen whose values change continuously so long the screen is kept open. The values to be updated will be provided by the server continuously. I understand that normal http connection would not be a solution here. Also, I do not wish to make continuous http requests owing to performance reasons. What is the best way out in order to accomplish this.Is GCM Cloud Connection Server a good solution for my requirement. Or are there better solutions? Please advise.
Any help is much appreciated.
I think there are a two options. If you don't own the server yourself I would start a service to run in the background and bind to it. The service would poll the server at some time interval depending upon how often you want the values to update. The activity would then receive periodic updates and update the views. Given that the information that you're updating is really not all that large, updates every 30s to a minute wouldn't take a toll on performance at all since all of the work would be done in an asynchronous task.
Using an AlarmManager to accomplish this.
If you own the server then you could implement the GCM model, and only send updates when data changes. This is assuming that every user of the app would get the same set of updates of course.
Introduction to GCM
Keeping screen on could be battery consuming. If you own the server the changes can be pushed to the app using the GCM service.
As far as I understand, GCM bundles push messages from several server trying to push the messages together and hence is an optimised way to communicate.
Alternatively, you can bring up a server which can keep polling the original server and push the changes to the app through GCM.
Related
I have an mobile application (iOS and Android) and I need send some notification from my server to these, then the mobile app need to make some tasks and when they finish, send a message from mobile to server to confirm. I have thought using Push Notification, but the problem is if the user disable this feature, the app will never receive this notification. Anyone know some direct communication server-app but keeping security?
You may try the long polling technique. But it will drain your battery very fast, so be careful. The main idea is that you set connectionTimeout to a very very long time (30 mins for example) and when not closing that connection until the server says there is something. After receiving an answer or timeout, just reopen it.
Another approach is to make some method like getJobStatus on the server, assign a unique id for your job and ask the server if it's complete every N minutes for example.
When trying to synchronise the client with the server, we usually need to combine both push and pull.
Something you can think of:
The server provides an API that allows the client to get the latest updates.
On the client side, when the app is active, use a timer to try fetching updates every N minutes.
When the app is in the background, use a background fetch to try fetching updates. In this case, the user doesn't care about if the task is done instantly, because his is not using it.
Call the getUpdates when the app becomes active from the background, to make sure handle the updates when the user starts to use it.
I have an application with list of data that I get from server with http request. Now I want to make a notification when new data is available and I assume that it can be achieved with service.
Is that a good practice? Is there any limitations for number of requests made from service?
What I want to achieve is something like gmail application. When I get a new email, notification is shown.
I want my app to be as up to date with data as possible, but I understand that making requests every 5 seconds might be too much.
I am open to all alternatives and various ideas how to do that.
Not sure if you really need to pull data every 5 seconds. Of course, it is too much. You have two options:
Use GCM as #duynt suggested in comment. Follow Try cloud messaging for Android if you've never used it. This way you don't need to worry managing your service locally but whenever there is a latest data available, you will get notification so you can place request to get that and update in notification.
GCM needs An application server that you must implement in your environment. This application server sends data to a client app via the chosen GCM connection server, using the appropriate XMPP or HTTP protocol. Take a quick look About GCM connection server.
For any reason if you would like to pull data from your local Android Service component, you can still do that. But 5 seconds frequency is really high. As majority of the times the device is in sleep mode, you have to wake up the device then send request to pull data. Waking up device every 5 seconds means a battery drain along with consuming data.
If you still want to proceed with local service option by increasing the frequency, make sure you follow How to use http in sleep mode and implement it that way otherwise it wont work in deep sleep mode.
You have to make a decision now.
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 designing an Android application that needs to receive constantly changing information (so the update interval must be very small).
Right now I am reading this information by consuming a REST WebService, but I am wondering if this is the best approach, regarding the battery drainage. This application would have to refresh the data being shown very often (specifically GPS data read from another system).
I have been reading about Google Cloud Messaging but I didn't find any comparisons between the two approaches.. Theoretically both approaches fit my needs since the data changes so frequently that it doesn't really matter whether it is updated by request or on a timer..
So my question is: Should I stick with WebServices or shift to GCM? Is there another battery-efficient solution?
Thanks in advance!
GCM utilises a connection that is already there - using this over your current polling methods is definitely recommended and will be much friendlier with the battery.
Think about it, in your case GCM will send you a notification to let you know you need to refresh data so instead of just calling refresh you have: receive the notification, process it and then call refresh. So if you need to refresh so often, like just say each minute and it's constant just skip the notification.
I would set a recurring alarm, get the intent in a BroadcastReceiver and trigger an IntentService for the refresh