I am currently working on a task where i need to fetch the locations from GPS.
The concern i am having here is that once i obtain the location & the task goes completed, after this if the application goes in background i do not wish to obtain any locations until & unless my application is back on screen (foreground) whatis currently not happening. (kindly note here i am not talking about switching the activity from one to another via intent as my app has only one screen & one activity).
I wish to know what place exactly the code to handle this situation must go & how can i do achieve this. I have tried with setting the instance to null & remove update but it proves ineffective. May be i am putting it at wrong place i am putiing it outside onCreate() inside the class extending activity.
Call requestForLocationUpdates() in onResume()
and removeUpdates() in onPause()
Once I obtain the location & the task goes completed
If you just want one Lat, Lon fix: don't use the tracking mode, instead use : requestSingleUpdate()
Related
Is there any way I can go from one activity to another and delay the display of the screen on the target activity?
What I want to be able to do is to allow the target activity to fetch its required data but not to display anything until does.
I want the screen of the source activity to still be visible until I am ready with the data in the second activity.
Specifically, I am using an AsyncTask to fetch the data.
I know I could fetch the data in the source activity and then send it on to the target activity but this is not viable in our case.
Edit: More Info:
The whole reason I want this is because I am trying to change the structure of certain parts of the current code.
At present the way it works is the the first activity gets the data and then sends it to the second activity as a bundle.
This created problems when the second activity could be invoked from multiple places. It resulted in loads of duplicate code.
So, I decided to move the fetching of the data into the target activity thus cutting out any need for repeating code.
it also makes more sense for the activity to fetch its own data rather than relying on something else sending it.
You should first make a service that runs your async task. Then, start the service from your first activity with startService(new Intent(this, UpdaterServiceManager.class));
When the task ends in the service, start the second activity.
Click here for an excellent service tutorial.
Try to use service for this purpose.
Original:
Is there a way to kill a child activity of a TabActivity. I have a very simple tab setup. There are two tabs. One of the tabs contains a MapActivity. When I switch to the MapActivity the GPS turns on. When I press back, the TabActivity exits, but the GPS is still on. The gps doesn't turn off until I explicitly kill the app. Is there a way to kill the MapActivity from the TabActivity? I would like to kill it when TabActivity exits/onBackPressed.
Edit:
I do attempt to stop location requests in onDestroy and onPause in my MapActivity. I am using the MyLocationOverlay class an calling disableCompass and disableMyLocation in the onDestroy method. These methods are called, but the GPS remains on. If I call enableMyLocation and immediately call disableMyLocation (during onCreate), the gps will turn off.
Edited title to reflect the answer:
Turns out the problem is unexpected behavior with MyLocationOverlay's enable*/disable*. These functions do not appear to be idempotent. Multiple calls to enable and disable do not turn it on once or off once as one might expect. Ensuring one call to enable (in onResume) and one call to disable (in onPause) will disable location requests when exiting an activity.
The location service cannot be killed by stopping an activity, you should read up more on location services and how they operate:
http://android-developers.blogspot.com/2011/06/deep-dive-into-location.html
Specifically, when you request location updates from the providers (in your case the GPS provider) you should only request it for a certain period of time, and then you need to make a call to stop the requests.
Also see:
http://developer.android.com/reference/android/location/LocationManager.html
The best thing to do would be to override onStop() or onBackPressed() to stop the GPS. When you are in one of the activities, you have the option of calling getParent() to return the tab activity, as a side note.
It turns out that calling MyLocationOverlay.enable*() multiple times (I was calling it twice) makes the GPS stay on even if you call MyLocationOverlay.disable*() as many times. At least, this is the behavior I observed. I expected enable and disable to be idempotent, but they are not.
Related problem
I have two activities, A and B. Activity A implements a LocationListener that periodically prints out the raw GPS coordinates the screen. Activity B is simply a MapActivity with a MapView. I want to be able to pass the periodically-generated coordinates from A to B, even with A paused in the background and B in the foreground. Turns out that the LocationListener indeed continues to retrieve the coordinates when activity A is paused. With B in focus, then, how do I pass those values over from A? Is startActivity(intent) appropriate for an activity that's already started and in the foreground?
If you need to constantly poll for location updates, consider making a "Sticky" service (but not like androidika). Check out the Remote Messenger Service example. This will allow the activity to "hear" updates on the location from the service.
In my app, i made a base class that "heard" updates of location and if connectivity was lost. Then, the ui activities inherited from this base class. Thus, i could make two different activities receive updates, but minimize duplicate code.
I d' recommend using a service, that runs in the background.
Or rather than having one activity decide when to update the location, write an IntentService that you launch from either of the 2 activities whenever you need them.
Take a look at PlacesUpdateService This does more than just look for the gps coordiantes, but it will give you the idea.
Firstly, I know LocationManager doesn't have to be called in an AsyncTask as it's already non UI blocking :)
I have an activity which
1. Gets the users current location
2. Calls a webservice to retrieve a list of specific POIs around that location.
The user can choose to view the results as map or list using a TabActivity. Bearing this in mind the AsyncTask to get users location and call to webservice is managed by the TabActivity view rather than either of the docked views.
So I want the TabActivity to start an AsyncTask which first gets the users location, then calls the webservice. A progress dialog prevents switching views using the tabs during this process.
It's pretty much all working apart from getting the users location from the AsyncTask. The webservice code is written, the mapping and overlay code is written, the task progress dialog copes with orientation changes.
The focus on location is speed rather than accuracy. If the user chooses to view results on the mapview then I will provide a 'My location' button which will enable a more accurate location to be obtained. I just want to initially get a rough location and return the search results quickly.
Maybe I'm going about this the wrong way. Maybe I should display the map view, let the map activity find the current location, then call just the webservice in the async - but then what if the user taps the list view tab during the location phase ? I was also going to allow the user to specify their default view - some people may prefer a list to a map. In this case I would have a listview which had to retrieve the location.
Thanks for any advice
Martin.
I sussed it.
The problem I was having was that the LocationListener was not being called in the AsyncTask.
The reason for this was that although I'd created and prepared a lopper in the thread I hadn't called Looper.Loop()
I start the requestLocationUpdates, kick off a timer. Either the locationmanager responds with a location, or the timer expires. At this point I call looper.quit() to ensure things return to normal.
Seems to be working. You also have to remember to respond to the back button etc, cancelling the timer and looper if the AsyncTask is cancelled.
I know Android's Activity model is a bit different from what I usually consider to be an "app".
I want to do something (in this case, check some notifications on a server and show them if available) when my app is "launched". What is a good way to accomplish this?
I likely don't want to do it in an activity's OnCreate, since each activity can be created any number of times - the code would get called more often than necessary.
The app also has multiple entry points - would I have to duplicate the check in each activity?
What I'm thinking of doing is setting up this code inside the Application object, along with a flag that tracks whether it's already been called - and just call it from each Activity's onCreate().
Is there a better or more "proper" way to do this?
The right, Android-approved way to do this is:
Create your own android.app.Application class
Override the onCreate method
In the AndroidManifest.xml, change the android:name attribute of the application element to the name of your class
Now, whenever your app is "started" (any one of your activites is started for the first time and no other instances are alive) onCreate will be called.
You may also find the onTerminate method useful.
Can you just check if the bundle passed to onCreate() is null?
It's not null "If the activity is being re-initialized after previously being shut down..."
There's probably no harm in putting it in onCreate; the Activity is really only destroyed when the OS needs the RAM for something else, not when the user goes to another app.
EDIT: You can also have a Service that runs when the device gets booted up, too. This might be a better option if you also want to check when the app starts, since you'll only have to call context.startService from the Activity to run the check. Just be sure to stop it when it's done if you don't need it to be persistent.