Keeping service alive across configuration changes

by THill » Thu, 08 Apr 2010 07:45:05 GMT

Sponsored Links
 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-
-- 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.




Keeping service alive across configuration changes

by Dianne Hackborn » Thu, 08 Apr 2010 08:17:46 GMT

 You can use the ApplicationContext to bind to the service, and propagate the
binding to the next instance via

Yeah, sorry, obtuse and awkward.  In the future I'd like to have something


Sponsored Links

Keeping service alive across configuration changes

by THill » Thu, 08 Apr 2010 10:44:10 GMT

 Thanks Dianne, I was wondering if there was a way to preserve that

If I go with that approach, I guess the ServiceConnection object will
have to be static or belong to the Application also.

What about the other scenario, where one activity launches another &
then calls finish().  Is onCreate of the second activity guaranteed to
be called before onDestroy of the first?  If not, the service could go
away in that window.


> >

Keeping service alive across configuration changes

by Bob Kerns » Thu, 08 Apr 2010 20:36:33 GMT

 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


Keeping service alive across configuration changes

by THill » Thu, 08 Apr 2010 23:32:47 GMT

 hank 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>.


On Apr 8, 5:36am, Bob Kerns <> wrote:


Keeping service alive across configuration changes

by Juhan » Thu, 13 May 2010 01:13:55 GMT

 o what solution do you use? I am facing the very same problem.

On Apr 8, 6:32pm, THill <> wrote:


Other Threads

1. OOT: Paging Yopie

Permisi mods
Numpang paging yang punya Jakarta yah

Yop gw email ke japri

Makasih mods :)

Froyoed HD2

ID Android Developer: 

2. Server errors

Is it just my customers or have there been a bunch of download
problems with Android Market in the last three days? I mean, more than

The word 'server error' in particular is something that has cropped up
in my customers complaints just this week. One person even mentioned a
number, 5005.

Of course, the maintenance and change this week weren't supposed to
cause any disruption for customers, right?



3. Best Design for Android App

4. Window already focused:ignoring focus gain android

5. (WTB) otterbox desire and hh android

6. Android system font size

7. GSOC project in android