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



On Apr 7, 5:17 pm, Dianne Hackborn <hack...@android.com> wrote:
> 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.
>
>
>
> On Wed, Apr 7, 2010 at 4:44 PM, THill <thill.dr...@gmail.com> 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 android-developers@googlegroups.com
> > To unsubscribe from this group, send email to
> > android-developers+unsubscr...@googlegroups.com<android-developers%2bunsubscr...@googlegroups.com>
> > 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.
>
> --
> Dianne Hackborn
> Android framework engineer
> hack...@android.com
>
> Note: please don't send private questions to me, as I don't have time to
> provide private support, and so won't reply to such e-mails.  All such
> questions should be posted on public forums, where I and others can see and
> answer them.

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

Reply via email to