I don't think you're saving anything significant. It takes only a tiny bit of energy -- VERY tiny -- to register a listener.
The things that will make a difference are keeping the various components awake and powered up. For example, keeping the processor awake and running, or keeping the GPS radio tracking satellites. Since the phone will continue to be a phone, you won't be making a difference asking for network location, even if you're also asking for GPS. And if it takes your application 100 ms to respond to one of these notifications, and you don't actually wake the phone up to respond to them, you're only going to cost AT MOST 100 ms of battery life -- and likely less. And a trivial check for whether you have a recent update from the other provider would be enough to reduce that by at least a couple orders of magnitude... I'm not specifically arguing against your approach -- but I'd value simplicity and 100% certainty of getting it right, over any energy or performance improvement you may be getting. If it's about as easy to do it your way as it is to coordinate two different listeners feeding events, then fine, go for it. Just don't expect to see any power savings. On Apr 2, 11:39 pm, patbenatar <[email protected]> wrote: > Hey all who are interested in this topic- > > The reason I think this is more efficient would be for power usage > purposes: it seems that running the GPS and Network listeners side-by- > side all-the-time would be a waste of the user's battery... Running > 'em side by side would also probably slow down your app just a tiny > bit as you're starting up an extra listener when you may not need to. -- 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 To unsubscribe, reply using "remove me" as the subject.
