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

--



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
Activity.onRetainNonConfigurationInstance().

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




>


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

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.

Cheers
Tim






> >



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
stopSelf().




--



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

Cheers
Tom




On Apr 8, 5:36am, Bob Kerns <r...@acm.org> 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 <thill.dr...@gmail.com> wrote:

--



Other Threads

1. Android 1.5 - Does MediaPlayer support HTTP 1.1 Transfer-Encoding = chunked?

The tittle asks the question... :)

Thanks!
Moto!

--~--~---------~--~----~------------~-------~--~----~

2. App Engine/Google login integration

Hi,

I was wondering if there are plans (or currently available ways) of
integrating Google login from the phone with App Engine sites.

It would be desirable for the phone to submit GMail login credentials
to App Engine sites without the user having to re-enter his/her name
and password.

Any thoughts on how to do this?
--~--~---------~--~----~------------~-------~--~----~

3. Cupcake version 1.5 to firmware update on phone

4. Android 1.5 Documentation

5. How to set the width and height of an ImageView programmically?

6. MP3 download problem

7. What UI Elements in AppWidget?