Which one is best for continuous/time-wise server updates.
Some developers use AlarmManager followed by PendingIntent and some also use Looper with Handler.
So can anyone please explain me that which is best for continuous network updates and why.
Which one is best for continuous/time-wise server updates?
depends if your app suppose to run in background / foreground at that time:
let's say you are scheduling Runnable via handler to 15 minutes from now.
if the user will "close" all running activities, the system will probably kill your process if it not running any foreground services/activities after a while to reclaim memory.
in that case - your Runnable will never be executed.
if you want to continuously poll for server updates even when the user navigates away from your app - this option is obviously not good for you.
if you choose to update server like that - at least do it from a started Service context- that way your Handler reference will stay allocated even when user navigates from one screen to another...
on the other hand - providing pending intent to AlarmManager insures that no mater if your process is alive or not - the intent provided to the AlarmManager will wake up your app (and the Service / Activity / broadcast) you provided with the pending intent.
about your question - I think that none of the two are good solution to get server updates:
the user probably have 10-20 applications (such Facebook/Twitter/Whattsap/Viber/Google+...) installed on his device which getting updates from server.
imagine that each one of them wake up in some different time interval, opens internet connections, consuming lot's of precious battery life and band-width. that's crazy! your device will never "sleep", all process will be opened all the time, internet cellular radio transmission also. the battery will rich to 0% very fast!
the right think to do is to use the GCM API. it requires also server side implementation, but the general idea is that the responsibility to wake up your application when there is a new data passes to the server's side, and by that -the android application don't need to poll for updates. it just get notified (and wake up if the process not alive) when the server notified you.
in case you'll wonder - this is how it works - How does push notification technology work on Android?
I advice you to read about it - http://developer.android.com/google/gcm/index.html
Related
Android : java class ā
Worker vs Service ?
What is the difference between Worker and Service? Which is better to do something in background for a long time. Application never stops.
Dear friends.
Android : java class ā
Worker vs Service
I made an android application and inherited the Service class and it checks a website every minute and if there is new information on this website, it sends me a notification.
Does anyone know about Worker and what is the difference between Worker and Service? Which is better to do something in background for long time. I want to make an application, that it never stops.
Don't do this. This is the wrong architecture for a mobile device. You'd kill the battery by forcing the cellular radio to constantly be transmitting. Instead, use push notifications from your server to the device when there's new information.
As for workers vs services- everything in Android is written to prevent long term background processes. Background services can last a max of 2 minutes after your app is no longer in the foreground. A Foreground service lasts longer, but can still be killed for resources. A worker is a better idea for long term work, but can't be done once a minute. And if the phone is in Doze mode (entered a minute or two after the user puts the phone screen off) you're limited to one short period of processing every 15 minutes anyway.
The right way to do this is push messaging. If you want the notificaion to be instant, use high priority messages. This will be better on your server side as well, as N clients pinging every minute would cause a ton of traffic and cost you a ton in hosting fees.
I'm making an app that tracks user activity in the background using ActivityRecognition API, and if the user remains in the same place for specified period of time(e.g. 1 hour), then system pushes notification telling user to take a walk. I have implemented activity recognition, but only for the cases when the app is opened. Obviously, the Google API Client needs to keep connected in order to send activity updates. My questions is - for activity tracking in background, what would be a better solution:
1) To implement AlarmManager in the main activity (or separate activity) that once in 30 seconds wakes the activity, connects Google API Client to Play Services, then sends PendingIntent to IntentService for activity analysis
2) Create a separate Service (not IntentService) to continuously run on background (separate thread), that will keep API Client connected, and send activity updates to IntentService. Hence, the system would have 2 services: 1) Service to keep API client connected to Play Services and send regular activity updates to IntentService for analysis; 2) IntentService for receiving activity updates form Service, and analyse the data.
3) Some other solution (offered by you guys)
Comments: My tutor suggested me to use AlarmManager, but you usually use it for things like network updates, hence the interval is generally more than 10 minutes whereas I need 30 sec - 1 min. So I am hesitant to use it.
I also have seen many similar questions on here before, but I haven't found any clear answer.
Actually, a connected GoogleApiClient is only required for requesting and removing activity updates - you do not need a connected GoogleApiClient to receive activity updates.
The requestActivityUpdates() documentation actually specifically mentions working in the background:
A common use case is that an application wants to monitor activities in the background and perform an action when a specific activity is detected. To do this without needing a service that is always on in the background consuming resources, detected activities are delivered via an intent. The application specifies a PendingIntent callback (typically an IntentService) which will be called with an intent when activities are detected. The intent recipient can extract the ActivityRecognitionResult using extractResult(android.content.Intent). See the documentation of PendingIntent for more details.
I would recommend a different approach. The problem with the Google Activity recognition API is that you cannot be confident about it reporting a certain event until its confidence level is >75. To have a confidence level of >75, you need to increase the detection level, which in turn can consume a lot of battery. Iād recommend trying some free SDKs like Atooma, tranql or Neura (you can find them online). These give you much better insights about your users and, in some cases, consume only around 1% of your battery life
I'm writing an Android app whose main Activity starts a Service that makes itself sticky. The Service makes repeated HTTP POSTs to a server, exchanging some information. This process works perfectly as long as the phone's screen is on, but once I turn the screen off, the service stops after a while. Is there any way to guarantee that my Service keeps running indefinitely?
Is there any way to guarantee that my Service keeps running indefinitely?
No.
Furthermore, you should not want your service to be "running indefinitely". Certainly your users do not want your service "running indefinitely", as that is why they will attack you with task killers, the force-stop operation in Manage Services in Settings, and so on. Not to mention all the lovely one-star ratings on the Market, choice comments in discussion boards, and the like that such applications will trigger.
Moreover, your problem here is not that your service is not running, per se, but that the device is falling asleep. This is perfectly normal. Users want their device to fall asleep -- otherwise, their battery life will be horrific.
The Service makes repeated HTTP POSTs to a server, exchanging some information.
The proper way to do this is to use AlarmManager, to trigger your code to execute periodically. Your user should be able to control the period (perhaps via a SharedPreference), including an option of "I'll manually request the data transfer, thanks". And, via an IntentService or similar means, you arrange for your code to be started by AlarmManager, do its work, and then shut down to get out of RAM.
Getting AlarmManager to wake up the device out of sleep mode is not that difficult (use a _WAKEUP flavor of alarm), but keeping the device awake long enough for you to do your HTTP request can be. The HTTP request cannot be performed on the main application thread, as it may take too long. One recipe is to use my WakefulIntentService component, which is an IntentService that keeps the device awake long enough for your work to be complete, then shuts down and allows the device to fall back asleep.
First Way: What you can also do to make HTTP POSTS to a server continuously is, you can make a timer and inside the task of the timer ie. in run() of class TimerTask you can make startService() and as soon as you are done with the HTTP POST work you destroy the service. Thus on a periodic basis, the timer will start the service and there won't be any background service.
Second: You can also use the PowerManager.WakeLock
Third: You can use AlarmManager as discussed in the previous answer.
I am coding an android application that gets the user position every 5 minutes, stores it in the database and sends it to a server.
I have read many ways of doing it, I was going to do the following:
User starts the application
The main UI activity starts a service.
The service runs in background and keeps turning on and off the gps, and creating new
threads that will save to database,and send the data to the server.
But I have seen that it can be done with a "Remote service" (http://developer.android.com/resources/samples/ApiDemos/src/com/example/android/apis/app/RemoteService.html) or with an AlarmManager that schedules starting this service every 5 minutes.
The service will need to be running always: it is important that after every interval (5 minutes), it is executed.
I think I need some clarity here.
Thank you for your help,
I am coding an android application that gets the user position every 5 minutes, stores it in the database and sends it to a server.
Please allow the user to choose the location provider. Not everybody has GPS on their device. Not everybody has GPS enabled. And, not everybody will want the power hit of GPS being turned on every five minutes.
Please allow the user to choose the polling period, including "never poll -- I'll refresh the information manually from the activity". Also, please honor the background data setting (deprecated as of ICS).
I think I need some clarity here.
If the polling is supposed to go on even if the activity is not in the foreground, use AlarmManager. However, most recipes for using AlarmManager will have the real work (in your case, GPS fix and network I/O) be handled by an IntentService. This will not work in your case, because GPS is asynchronous -- you cannot just get a fix whenever you feel like it. It will take a long time, possibly forever, to get a fix, so you have to deal with the delay and eventually timing out the operation. Writing a Service to do this is possible, but tricky, particularly if you are aiming to collect this information even if the device falls asleep.
If, however, the polling is only supposed to go on while the activity is in the foreground and the device is on, I wouldn't bother with a Service at all. Just have the activity use postDelayed() to set up an every-five-minutes scheduled bit of code to run, then have it do the work.
I am new to Android, and I need some advices for start up.
I want to build an application, which will show up, when the user gets into some hot situation.
By hot situation I mean:
the GPS/cell coordinates are in known zone;
known Bluetooth device detected;
known Wi-Fi network detected;
weather info has change;
I see something running in background and when one of the clauses hit, it will trigger and open the app.
How to get started?
How do I make sure my app won't be shut down?
As I read somewhere that Android OS will terminate apps if memory out occurs or consumes too much, and my app would consume a lot, making repeated measures/checks to see if situation changed.
Regards,
Pentium10
You need to use a Service for the part of your application that runs in the background.
You might find the Application Fundamentals document in the Android Developer Documentation helpful. It says this about Services:
A service doesn't have a visual user interface, but rather runs in the background for an indefinite period of time. For example, a service might play background music as the user attends to other matters, or it might fetch data over the network or calculate something and provide the result to activities that need it.
In you case you might find the LocationManager Service helpful. It is a system Service which will you can use to notify your application based on GPS position.
However, I think you'll have to write your own Services to monitor Wi-fi, Bluetooth and weather.
You can use the AlarmManager Service to get your Service to perform particular tasks at certain intervals.
It depends on how & where you want to deploy your application. In my experience it boils down to
you create an application for a specific use case where battery drain matters less than accurate results (showcase situations, prototyping, ...)
you want to distribute the application to users.
In case 1) just create one service that aggressively polls the sensors / web services. Use the AlarmManager to send a REFRESH intent (AlarmService.setRepeating(...) ).
That REFRESH intent will restart the synchronization service everytime, even if it was killed by the system. onStart() will be called everytime the REFRESH intent is emitted. You can do heavyweight setup logic in onCreate() as this will be called everytime the service is created after it was destroyed. WARNING: This will possibly drain the battery very quickly.
In case 2) I would create several services and let the user configure different polling intervals for each service to limit battery drain. I can see for example that bluetooth should be polled more regulary than GPS as it is more likely that a bluetooth device suddenly appears than a user moving extremely fast.
Weather sounds extremely expensive (network lookup, possibly triggering a network connection!)
Please do not try to be too persistent with your app in case 2). It usually makes a lot of sense for a phone to kill memory / power draining services.