It's a bit hard to say what design is right without details on what the service actually does.
First and most important question - do you really need a service at all? Many apps use services but don't actually need to run all the time. Using a service is like a tax on your user. It's currently invisible but it won't always be that way: expect your users to start asking questions at some point if/when Android makes resource consumption of apps more visible. Most of the time when people are using a permanently running service, what they really want is a service that handles inexactly repeating alarms. Now how to sync state between the activities and the services. Remember that a service is just an object representing a lifecycle construct. It exists in the same process that your activities do, so they can communicate in the same way any two Java objects would communicate - via direct method calls, for instance. It's perfectly OK to use the "local service" idiom that is shown in the API samples to bind to a service and then cast the result to the object itself. Or if started using an intent, you can just stuff a reference to "this" into a static field. As to using intents, you don't have to do this. You can just keep track of what the service is meant to do in a file, a database, or whatever else is convenient. But again, really consider whether you need an always-running service. Very few apps actually need this (things like music players being the obvious exception). --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
