Hmm, ok thanks - "which value should be used" was intended as a rhetoric question, pointing out that in it's current form, this feature is not usable. It has the potential to cause non-deterministic behavior when the different values of minTime are set as result to (asynchronous) events. By mapping multiple objects (listeners) with different attribute values to a single one (location provider), you never know what you will get.
The real kicker (as far as I can see, I haven't tried this out): Now you can build an app that interferes with other apps running at the same time. Say, your app has a service running in the background that calls .requestLocationUpdates() with a minTime value that's different from an app running in the foreground. In the extreme, you can choke off the foreground app's location provider, no? On Oct 24, 2:00 am, Lance Nanek <[email protected]> wrote: > >multiple listeners for a location provider with different minTime intervals > >- which value should be used > > Looks like the current implementation uses the shortest value for that > situation:http://android.git.kernel.org/?p=platform/frameworks/base.git;a=blob;... > > Seems like an OK decision there from some quick tests. I called > requestLocationUpdates for two listeners. One with a power conserving > hint argument of 30 seconds. The other with 60 seconds. Both listeners > got the same update frequency. In number of seconds between > onLocationChanged calls: > 1, 1, 2, 1, 2, 1, 2, 1, 2, 1, 39, 1, 1, 1, 1, 1, 1, 1, 1, 1, 3, > 37, ... > > Corresponding to occasional ~30 second shutdowns. Once I called > removeUpdates for the listener that was registered for 30 seconds, > then the listener registered for 60 seconds started getting what it > would normally get: > 2, 1, 69, 1, 1, 3, 1, 2, 1, 2, 1, 2, 1, 70, 1, 1, 2, 1, 2, 1, 2, > 1, ... > > ~60 second shutdowns. End result, the listener that was registered > saying it is OK with ~60 second shutdowns never actually has to wait > that long if there is another listener registered that wants more > frequent updates. Meanwhile the one that wants the most frequent > updates gets what it normally would. > > On Oct 23, 10:30 am, JP <[email protected]> wrote: > > > (Refers to the logs) This occurs every 3s, although minTime is much > > higher, just as you've found. I will venture to say that this is > > harder on the battery than to just let GPS stand. > > BTW, resting a location provider this way is also mis-spec'ed. If an > > app registers multiple listeners for a location provider with > > different minTime intervals - which value should be used to control > > the location provider? > > It certainly isn't in line with 1.5 behavior, or with anything I've > > seen on any device. > > > I suppose I can't be sold on this being a feature, not a bug. > > > On Oct 22, 11:40 pm, Lance Nanek <[email protected]> wrote: > > > Is this behavior hurting an app you use/wrote in some way? It seems > > within spec. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Android Developers" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -~----------~----~----~----~------~----~------~--~---
