I have an app that consists of a few Activities. I want the when my app starts up, the I start listening for updates from the LocationManager, and after a few minutes, I want to time out and stop listening for updates. I've done this in other apps, but where I only have one Activity.
What I have now is a BackgroundService that starts listening for LocationUpdates; if it gets a good enough location quickly, it stops listening for updates. But sometimes it doesn't get a good location quickly, and I want it to time out, so I have a Timer that stops listening for updates after a bit. This works fine when I start the App and stay in the first Activity.
The problem is when I start the app, then start using the app and other Activities start, the Timer never goes off, so LocationManager is always on, until the app quits.
Thoughts? Is there a better way to listen to location updates so any Activity in the app can get the location, and ensure that it times out to stop listening for updates?
Update:
It turns out the BackgroundService gets destroyed when I switch Activities, and I cancel the timer in onDestroy(). Thanks for the response-- that was enough to confirm that the general approach was reasonable and I probably had a silly mistake somewhere (true).
Why don't you put the Timer in the background service ? That will solve the issue.
Related
I'm making an app where a background service does some stuff on some specific motion. At the moment I use a simple Service with a SensorEventListener attached to register the movement of the phone and to do the action I wanted it to do. Im also using an (optional) wakelock without any time limitations (but it gets unatached when the service is terminated) to ensure that the service is always accessable. I used the START_REDELIVER_INTENT to ensure a restart when the activity stops it when the user stops its (regularly via the ome button).
Now to my problem: When I stop the activity, the service gets terminated but only sometimes restarted (I dont know whether its not restarted or just doesnt get its sensorchanged called. I suspect last but I dont know for sure due to I only place a simple Sysout in the Sensorchanged method for testing).
Is there better and more efficient way to achive my goal (eg startForeground) and how can I ensure a continous aquiring of sensordata after an activity stop?
Services which need to run continuously have to be started with startForeground().
A positive sideeffect of this is that the user will be aware of your app using a sensor and can stop it if he runs low on battery.
this scenario is very common according to the Android documentation but still I don't find a straight solution neither there nor anywhere on the net.
So I have a service that should do something like this:
Register a LocationListener to receive the user location
Once the LocationListener is called - stop listening for a 5 minutes
After 5 minutes start listening again and loop from 1
This is the recommended way to save battery power while listening for the user location.
As a service I have a major problem with step 3.
The only way I found to "wait" for 5 minutes is to schedule a java.util.Timer to execute a TimerTask in 5 minutes and this TimerTask should register the LocationListneres again.
However this does not work because of:
java.lang.RuntimeException: Can't create handler inside thread that has not called Looper.prepare()
Which is also expected because requestLocationUpdates should be called from a "main" thread.
Ok .. nice... but I don't have a Main thread. I don't have an activity. From the TimerTask I can't send an intent to the service to register my listeners back.
How can I ask my own service to register my listeners again?
This is the recommended way to save battery power while listening for the user location.
Really? The only way that's a good pattern is if you are using AlarmManager for the five-minute delay, so the device falls asleep in between location checks.
The only way I found to "wait" for 5 minutes is to schedule a java.util.Timer to execute a TimerTask in 5 minutes and this TimerTask should register the LocationListneres again.
And that would be a horrible use of battery, because it would mean you would need to keep the device powered on constantly, not allowing it to go to sleep.
I don't have a Main thread
Yes, you do. All processes have a main application thread. onCreate(), onStartCommand(), etc. of a service are called on the main application thread.
I don't have an activity.
Then you better write one, as your app will not work on Android 3.1+ without it. Your app will not run until a user launches one of your activities on Android 3.1+.
How can I ask my own service to register my listeners again?
What you are trying to accomplish is a rather complex problem. Not only do you need to arrange for the device to fall asleep and wake back up again, but you also need to deal with lots of edge cases (e.g., what if no location is available, because the device is in airplane mode or is underground or something?).
I wrote LocationPoller to handle your use case, and another developer forked it to create a more feature-rich implementation.
Whether you use one of these directly or simply examine their implementation, they should be useful to help you understand how to solve this problem. All of the details, though, are well beyond the scope of a StackOverflow answer -- it would take several pages in a book to explain it all.
You can specify the parameter in requeestLocationUpdates() to make it run after a certain time.
I have build a service to broadcast a timer data to various activities. Usually it runs ok without problems, but there are ocassions when android restarting it does not work as expected.
It has also three Broadcast receivers:
1 - Screen off event: in order to stop broadcasting timer data and setting an alarm in alarmanager for when the service ends, so I will be able to play end notifications for the users to attend.
2 - Screen on event: in order to continue broadcasting the timer data. I also cancel any preiously alarm pending.
3 - A receiver for alarms. This usually fires when screen is off, as explained in 1.
My service is started with startForeground and return START_REDELIVER_INTENT. AS the start intent has inicial timer date, I can recreate service status without problem. Broadcast alarm receiver and onStartCommand share the same handle intent routine to start or continue the service.
All this works perfect. For short timer ( < 30 min ) I dont find any problem. The screen can be on, off, change same times from on to off and from off to on. Also the activity can be in front or in back. I have toying with those all possible states. In all cases, my service and activity runs ok.
My problems comes when some timer are longer ( > 30 min , usually I set up for 35 min). There are sometimes that maybe due to memory reason Android kill me service. That is ok, as I understand Android does this in order to improve user experience. The problem is that when I goes to 'settings/application/services' I can see my service in 'restarting' state. I suspect this mean Android has not launched it yet and it is been sheduled. It show that state for long time (I have not had patient to say if it changes for more that other half hour....)
The problem is that when in that state, that can long for ever (I have been looking into it and the service is never started), the timer (in my watch) reach the timeout, the alarmmanager launch my intent, but as my service is not started yet and the broadcast not registered, I cann't do staff for time outs (playing notifications). So the user does not known the service timer has ended and it is a heavy problem.
It is very courious. As the service is killed in almost any run passed 30 min, while other services are not killed.
My question is: what exactly is it happening? How can I correctly handle this situation in order to detect alarms been fired correctly, or more to the point: how can I force my service to be restarted correctly?
For adding some help data:
My service does have very little memory compare to others, and also does not run long operations, it only uses handler.postdelayed("sendUpdatesToUI",250) when screen is on, and nothing when screen is off, only waiting for alarmmanager to send time out intent.
When time is reached, and user opens the activity, it received the timer data broadcast intent from service and as it see time is reached, then it stops the service.
I understand and accept user can kill the service when he wants, and I accept that. The problem here is not the user, but Android restarting the service.
When service killed, onDestroy is not invoked.
Using 2.3.4 version.
After lot of investigation I found the solution to my problem. It is all about startForeGround function. I was using:
startForeground(0,not);
while this looks good and it found in lot of examples around the web, the correct way to do it is not using 0, but any other random value:
startForeground(2765, not),
This solve the problem.
friends,
i have created an application in which i am getting GPS location onCreate Method and
onPause method i remove Location updates.
after taking gps update i left my mobile idle and whole night it was in idle mode and my application was running in it, in the morning bettery was down due to GPS i guess.
any one guide me how to handle this situation in which method should i stop using GPS if application is idle other than onPause()?
any help would be appreciated.
Stop the location update notification in onPause() is fine, but please note two things.
If GPS is still on, it will still eat your battery.
According to the activity life cycle if you start listening to location updates in onCreate() and stop it in onPause(), then when you return your application to foreground it will not register to updates again, consider moving the registration to onResume().
I asked a similar question about timing out the GPS if the user moves indoors where a signal cannot be found. I started a timer within the LocationListener class and remove updates if a signal isn't found within 5-8 seconds. There's some code here that might help How to time out GPS signal acquisition
If you stop receiving broadcasts (thus unregistering your BroadcastReceiver in the onPause() method of your activity), there is no reason why your application would keep receiving updates from the LocationManager.
I am building an android app for fetching internet data and rendering it as a list. The data is changing every minute, so I made a service and used a Timer to load the data with an interval.
My question is that:
I want to know when the app (not a particular activity) goes to the background, for example, user pressed the home button, in that case, I want to pause the service in order to save battery.
I want to know when the phone is sleeping (screen dimmed), in that case, I would like to pause the service too.
Any ideas?
Pause your service in onPause (and resume in onResume).
Unless you have a wake lock, your app will not run when the phone is sleeping.
If you're bound to a foreground app, why use a service in the first place?
To elaborate on 1: I understand you're saying "app", not "a particular activity", but your best bet is to use Activity.onPause and Activity.onResume. If anything, you can add a short delay so that nothing happens if onPause is followed immediately by onResume.