Question

An app I’m working on can’t meaningfully launch until it has a Location from somewhere — coarse, fine, it doesn’t matter. It just needs one that isn’t null. So, my Activity class is doing something along the lines of the following:

onCreate():

• instantiate LocationManager
• create Map so I can keep track of all the LocationListener objects for which I’ve requested updates.

onResume():

• Grab List of enabled LocationProviders from LocationManager
• Iterate through list. For each one, check whether there’s already a LocationListener in the Map. If not, create a new one, register it for updates, and stick it in the Map.
• Render the View
• implicitly return from onResume(). I’m ashamed to admit it, but I have absolutely no idea what happens to the Thread at this point.

(in the meantime)

… LocationManager.onLocationChanged(Location) gets called. The original plan was to use my LocationManager’s reference to the Activity object to call a method whose purpose was to update the view to reflect the new status. Apparently, that’s not allowed by Android.

… the user clicks a button associated with one of the LocationProvider updates, and the program proceeds to finish launching, or the user gets tired of waiting, clicks cancel, and the program quits since there’s nothing meaningful it can do without a location.

So…

1. What IS the proper way to have the main UI Thread(?) wait until another thread calls onLocationChanged() with the updated values, update the UI, then proceed to launch the next Activity’s intent or call finish() depending on whether the user clicks a button associated with a Location or clicks cancel?

2. What happens if you request updates from a LocationProvider and pass it a LocationListener that’s already registered to receive updates? Does it just replace the previous time and distance args with the new ones, or will it create TWO entries in the subscriber list, and call the LocationListener TWICE the next time the location updates?

3. What happens if a the app nullifies all of its references to a LocationListener while it’s still registered for updates? Does it live on, Zombie-like, thanks to a reference by the LocationProvider? Or does the LocationProvider use WeakReferences for everything, so old, forgotten-about LocationListeners will just fall out of scope and be garbage-collected?

4. If the LocationListener-implementing class has a reference to the LocationManager, is the Thread that calls its onLocationChanged() method allowed to use it to change the current LocationListener’s subscription terms? Or will that blow up with an angry warning, just like the attempt to update the View from a Thread of the wrong type?

Answer 1

1. You don’t “have the main UI Thread(?) wait”. Your user experience will suck if you “have the main UI Thread(?) wait”, because they will wonder why your application keeps crashing with “application not responding” errors. Instead, you display a ProgressDialog or something to let the user know to wait until you get a fix, and dismiss that dialog when the fix is in. There are other patterns here as well.

2. I’m not certain — I always use distinct LocationListener objects.

3. Yes, it lives on.

4. AFAIK, there is no problem in, say, calling removeUpdates() on a LocationListener from within onLocationChanged(). Then again, I have not tried it. If it does complain (most likely with some form of ConcurrentModificationException), have onLocationChanged() call post() on your MapView, to schedule a Runnable to be invoked on the main application thread’s event loop that will call removeUpdates().