I should have said to opt for the simplest thing that actually works! Or, to put it another way, "as simple as possible, but no simpler".
(Neither phrase is mine, but I can't recall the correct attributions.) For the fastest result, I'd start off with both listeners. The network will nearly always win (unless you're off the grid), but the GPS won't start until you ask it to. However, even if you can't get a network fix, you MAY be able to get a GPS fix, eventually. It will certainly take longer in this case. I haven't tested it in a location far enough away from towers to not get any network fix at all, and it would vary by phone anyway, but in theory it should be possible. Handling this case may not be important. A long-delayed GPS fix may be useless, for example. So as Maps API Guru says, you'll have to decide. On Apr 4, 3:00 am, patbenatar <patbena...@gmail.com> wrote: > Bob- You're absolutely right. The phone will continue to be a phone, > so the Network listener really isn't an energy consumer as its always > connected to towers. Great analysis, thanks! You say simplicity is > probably the best approach here--my main goal is to get a location as > fast as possible, whether it be network or GPS, then hope we can > eventually get a GPS update, but without one it will be OK.. Do you > think my approach will be just as fast as running two side-by-side > listeners? > > Ning- This isn't really a concern for me as the lifetime of my app is > not very long.. I couldn't imagine a user running my app in the > foreground for a day or so as in your application. > > Thanks for all the feedback, you guys are great help! > -Nick > > On Apr 3, 5:21 pm, Ning <zeeg...@gmail.com> wrote: > > > > > On Apr 3, 2:39 am, patbenatar <patbena...@gmail.com> wrote: > > > > Hey all who are interested in this topic- > > > > I have taken John's above advice and modified it into what I believe > > > is a more efficient way to be doing this [although the efficiency of > > > my method is only evident if you're going to to ensure updates from > > > either provider throughout the life of your app]. Please let me know > > > your thoughts on this method: > > > > Rather than running both listeners side-by-side as John suggested > > > above, I am first running a GPS listener and then within that > > > listener's onProviderDisabled and onStatusChanged [only if the status > > > is OUT_OF_SERVICE or TEMPORARILY_UNAVAILABLE] I am requesting updates > > > from a Network listener [and of course setting a networkOn=true flag > > > so I don't turn it on twice or anything]. Then the Network takes over > > > [while GPS listener remains running] until onStatusChanged() in the > > > GPS listener gets an AVAILABLE status at which point I turn off the > > > Network listener [and mark the flag accordingly] and allow the GPS to > > > do its thing. > > > Apparently, my reply didn't go to the public list because I habitually > > hit 'a' when I tried to reply all in Google Groups, which does not do > > the job. > > > I have been using this approach for a while. There are two problems > > with it. The first one is that GPS takes a while to get the first fix. > > The second one is power consumption. My program is set to get update > > every 5 minutes or 200 meters. After a day or so when I checked the > > battery usage, it had raised to the top of the list, consuming some > > 30% of all power consumed during that period. So I switched to using > > network location only, and my program disappeared from the list. > > > So my opinion on this is that unless absolutely necessary, I won't use > > GPS as location provider frequently. It will drain the battery very > > fast. > > > -- > > Ning -- You received this message because you are subscribed to the Google Groups "Android Developers" group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en To unsubscribe, reply using "remove me" as the subject.
