So what solution do you use? I am facing the very same problem.
On Apr 8, 6:32 pm, THill <[email protected]> wrote: > Thank you for the replies. > > Jason -- I am binding the ServiceConnection in onCreate & unbinding > inonDestroy. Don't know of a way to unbind by default. > > The drawback I see with using the application context to bind theservice, 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 aservicethat > 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/onDestroyright 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 yourserviceonly 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 theservice > > 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 aservice(that is possibly heavy/slow to start)? > > > > When the activity gets destroyed, it unbinds & causes theserviceto > > > be destroyed. When the new activity is created, it binds & recreates > > > theservice. > > > > The only choices seem to be: > > > -- override onConfigurationChanged in the activity. Feels ok, but non- > > > conformant. > > > -- explicitly start theservice& only stop it when the last activity > > > gets anonDestroythat's not due to a config change (i.e., there was > > > no call to onRetainNonConfigurationInstance). Feels icky. > > > -- explicitly start theservice& 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 aservice, the > > > same issue of keeping theservicealive 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
