Thank you for the replies. Jason -- I am binding the ServiceConnection in onCreate & unbinding in onDestroy. Don't know of a way to unbind by default.
The drawback I see with using the application context to bind the service, is that somebody still has to own the ServiceConnection. If it is owned by the application, or is a static member of the activity, the activity would have to register their instance with it to be notified of connected/disconnected events. Not terrible, but kinda defeats the purpose of allowing activities to bind to services if the best place to do it is really at the application level. Bob -- I've actually done what you described in the past, but I was never comfortable with the self-destruct timer (how long should it be, will it vary by device/OS version, etc). Also, for a service that plays audio, you'd want the audio to stop when the application exits, not during configuration changes, or activity transitions. Hence then need to prevent the last unbind, but only until the last activity has finished. This gets even more ugly on the NexusOne, where the last activity doesn't get onStop/onDestroy right away when the last activity is finished -- but that's another forum posting <grin>. Cheers Tom On Apr 8, 5:36 am, Bob Kerns <[email protected]> wrote: > Another approach, which may have benefits beyond the configuration > change issue, is to make your service only tear down the expensive > resource after a delay. Then, if you reconnect before that timeout, > you can simply reuse the resource. So if you exit and come back soon > into your app, for example, you can rebind and not have to redo the > expensive initialization. If the initialization is really expensive, > this may be well worthwhile. > > I suspect the best way to do this is for the first binding the service > to do a start of itself, and for the last unbind to post a delayed > stopSelf(). > > On Apr 7, 4:44 pm, THill <[email protected]> wrote: > > > The default way configuration changes (i.e., rotates) are handled is > > to destroy the activity & recreate it with a new one. What is the > > recommended way to handle these changes in an activity that binds/ > > unbinds to a service (that is possibly heavy/slow to start)? > > > When the activity gets destroyed, it unbinds & causes the service to > > be destroyed. When the new activity is created, it binds & recreates > > the service. > > > The only choices seem to be: > > -- override onConfigurationChanged in the activity. Feels ok, but non- > > conformant. > > -- explicitly start the service & only stop it when the last activity > > gets an onDestroy that's not due to a config change (i.e., there was > > no call to onRetainNonConfigurationInstance). Feels icky. > > -- explicitly start the service & don't stop it until some amount of > > time after the last unbind. Ickier. > > > On a related note, what happens between activity switches within a > > process, where the first activity (A) starts the next activity (B) & > > then calls finish() -- is there a guarantee that B.onCreate is called > > before A.onDestroy? If not, and the activities share a service, the > > same issue of keeping the service alive during this window exists, but > > with only the icky workarounds. > > > Suggestions? > > > Thanks > > Tim -- 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.
