-2

@commonsware let me start by saying thanks for all the help that you give this community, i swear the majority of issues that i google you were the accepted answer.

anyway, had a few questions after i started using the locationpoller

as noted in another post, once i start your polling service, i occasionally get this:

03-07 15:42:03.260: W/MessageQueue(14699): Handler (android.location.LocationManager$ListenerTransport$1) {419425f8} sending message to a Handler on a dead thread

is this a concern still? i couldn't tell if this was just something the locationmanager is screwing up of it was maybe the timeout handler

next is my main concern for creating this post:

i need to track users while their screen is off as part of a destination aware navigation-like application, and for some reason its not waking up after going underground for a while.

i get some weird test results when playing with no network too. for now i start the service like you suggest

Intent i=new Intent(this, LocationPoller.class);
i.putExtra(LocationPoller.EXTRA_INTENT, new Intent(this, LocationReceiver.class)); i.putExtra(LocationPoller.EXTRA_PROVIDER, LocationManager.NETWORK_PROVIDER);

everything seems to work as u documented, when testing with airplane mode turned on PollerThread#onPreExecute() gets called every time, and then never makes it to the end, and 2 minutes later, my receiver finally gets notified when the onTimeout Runnable gets triggered.

then when i turn airplane mode off again, everything seems to go back to normal, with my receiver eventually catching up again.

My issue is that when i test in the real world, and take the subway home but leave the app and service running, once i reconnect above ground, i cant seem to find any trace in the logs that the service continues on, and my receiver, which uses another wakelock to turn the screen back on / send a notification when close to your destination, never gets triggered until i re-open my app

long story short - is this an issue with the library? an issue with how locationmanager works? have you any ideas on a better way to test this rather than just using airplane mode?

above ground, biking around, driving, etc, everything seems to work just fine, but once i introduce the subway and i lose all connections, shit stops working, and i just dont know enough about the finer points of locationmanager to understand why the service seems to stop

disclaimer this app isn't meant for people on the subway but im just not sure (havent had any way to test) if a user is out in the middle of nowhere and loses network connectivity i hope they dont lose tracking as well (since they can choose to just use network provider or gps depending on the settings)

Community
  • 1
  • 1
trippedout
  • 1,561
  • 13
  • 20

1 Answers1

2

is this a concern still?

I have no idea. If you can create a reproducible test case that demonstrates this, please post an issue to the project's issue tracker.

My issue is that when i test in the real world, and take the subway home but leave the app and service running, once i reconnect above ground, i cant seem to find any trace in the logs that the service continues on

The service is not supposed to "continue on". The service will try for a short while to get a location fix, then will shut down after delivering the timeout message. It is up to you, via AlarmManager or similar means, to do the actual "polling".

Quoting the documentation:

You simply set up an AlarmManager alarm to contact LocationPoller on whatever frequency you wish, and it will handle all of the location work from there, sending you the results via a broadcast Intent... Next, you need to create an alarm via AlarmManager, so you can control how frequently the location is retrieved and whether it should wake up the device if it is asleep. Please do not request location updates frequently, as this will drain the user's battery, particularly if you are using GPS.

So, your first step would be to determine if your alarms are working properly. You can use adb shell dumpsys alarm to examine the registered alarms and see what is going on.

CommonsWare
  • 986,068
  • 189
  • 2,389
  • 2,491
  • the alarm seems to be working properly, after the above intent creation i continue onward with the code you supplied `alarmManager.setRepeating( AlarmManager.ELAPSED_REALTIME_WAKEUP, SystemClock.elapsedRealtime(), 1000*updateFreq, mLocationPollerPendingIntent );` and as i didn't explain enough above, since my testing updateFreq is every 30 seconds, onPreExecute will fire every 30 seconds, and then after 4 times, what must be the first instance of `onTimeout` gets fired. my concern was that when i go underground at some point this stops firing – trippedout Mar 07 '13 at 22:09
  • @trippedout: I have no idea what could be causing your difficulties. Without a reproducible test case, there is little that I can do to fix matters, assuming that something indeed needs to be fixed. There is a link on the project's home page to a fork of `LocationPoller` that you might wish to try, to see if you have better luck with that implementation. – CommonsWare Mar 07 '13 at 22:15
  • @trippedout: That being said, I strongly encourage you to set your `updateFreq` to be *much* longer than 30 seconds. `LocationPoller` is designed for checking things once per hour, not twice per minute. In particular, if your polling frequency is higher than the timeout value, I have no idea what will happen, but it is unlikely to work well. – CommonsWare Mar 07 '13 at 22:16
  • thanks for the input. what im trying to implement is a pseudo navigation app though, so depending on the initial distance between your starting point and the destination, my app could start polling with min time of 15 min and min distance of 1000 meters, but as it gets closer i am trying to update the alarmanagers settings to poll more often so that if your sleeping you wont miss ur destination. my main issue was that i couldnt even figure out a good way to debug the issues i had since by the time i got home from subway my logcat was useless – trippedout Mar 08 '13 at 15:42
  • @trippedout: A "pseudo navigation app" should not be using `LocationPoller`. A "pseudo navigation app" is in the foreground, and therefore should be using `LocationManager` directly. Again, `LocationPoller` is for infrequent background operations (e.g., "I want to automatically check into Foursquare every hour"). – CommonsWare Mar 08 '13 at 15:43
  • well when i have the app in the foreground, since google kindly updated their maps api last week and `setOnMyLocationChangeListener` now [actually works](https://developers.google.com/maps/documentation/android/releases#february_2013) i use that for updating the distance and location, but when they hit home / turn phone off, i start up your service, since that seemed to be the easiest way for me to get some kind of location polling working in the background... – trippedout Mar 08 '13 at 15:58