AsyncTask and screen rotation
Bret Foreman
screen rotation? My AsyncTask runs for about 10 seconds. I could call
AsyncTask.cancel in the Activity's onDestroy method and restart the
task in onCreate but that would waste cycles, bandwidth, and user
time. I'm guessing there is a better way.
Mark Murphy
Option #1: Don't have Android do the normal destroy/recreate cycle.
Add an android:configChanges attribute to your manifest for this
activity, and override onConfigurationChanged() to fix up your UI.
This keeps the same Activity instance, and so your AsyncTask should be
fairly happy. Here is a project that has this setup, though it does
not use an AsyncTask:
http://github.com/commonsguy/cw-android/tree/master/Rotation/RotationThree/
Option #2: Make the AsyncTask either a public top-level Java class
(not an inner class) or static inner class of the Activity. Manually
associate the Activity with the AsyncTask via a constructor parameter
in your AsyncTask instance. Associate the new Activity instance with
the AsyncTask after the rotation. You can see an example of this
technique here:
http://github.com/commonsguy/cw-android/tree/master/Rotation/RotationAsync/
Option #3: I think droid-fu may have some stuff related to this in
their library.
Personally, I'd use option #1.
--
Mark Murphy (a Commons Guy)
http://commonsware.com | http://github.com/commonsguy
http://commonsware.com/blog | http://twitter.com/commonsguy
Android Training in London: http://skillsmatter.com/go/os-mobile-server
Maps.Huge.Info (Maps API Guru)
your app by adding this (along with other code) in the manifest:
android:configChanges="orientation"
Search the docs for that.
-John Coryat
Bret Foreman
Android should provide more infrastructure for this sort of thing
because async web services are becoming almost universal and they
always require something like this when they interact with the UI.
Romain Guy
automatically switch layouts, drawables, etc. It might be fine now but
it might come back to bite you in the future. It should always be your
last resort. Saving and restoring an AsyncTask is not difficult.
> --
> You received this message because you are subscribed to the Google
> Groups "Android Developers" group.
> To post to this group, send email to android-d...@googlegroups.com
> To unsubscribe from this group, send email to
> android-develop...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/android-developers?hl=en
>
--
Romain Guy
Android framework engineer
roma...@android.com
Note: please don't send private questions to me, as I don't have time
to provide private support. All such questions should be posted on
public forums, where I and others can see and answer them
Dianne Hackborn
Option #1 is a lot more intrusive. You lose the ability to
automatically switch layouts, drawables, etc. It might be fine now but
it might come back to bite you in the future. It should always be your
last resort. Saving and restoring an AsyncTask is not difficult.
Dianne Hackborn
Android framework engineer
hac...@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.
Maps.Huge.Info (Maps API Guru)
> automatically switch layouts, drawables, etc. It might be fine now but
> it might come back to bite you in the future. It should always be your
> last resort. Saving and restoring an AsyncTask is not difficult.
>
regardless of how nicely done, would be a bad thing wouldn't it?
-John Coryat
Mark Murphy
> Option #1 is a lot more intrusive. You lose the ability to
> automatically switch layouts, drawables, etc.
Worst-case scenario:
Step #1: Take your UI setup that is in onCreate() and move it to a
separate method (e.g., setupViews())
Step #2: Call setupViews() from onCreate()
Step #3: Call setupViews() from onConfigurationChanged()
Done. ~4 lines of code. And it's the exact same code path that a
destroy/recreate will go down, so it's not like this adds unusual
performance overhead. There are certain circumstances where this may
not work (e.g., GLSurfaceView and a game), but you needed to do extra
work for those cases, anyway, to handle the destroy/recreate cycle.
> Saving and restoring an AsyncTask is not difficult.
No, it's not. The question is: is it reliable?
None of the AsyncTask documentation (class, article, etc.) covers this
case. It *appears* that you can write an AsyncTask such that
onPostExecute() or onProgressUpdate() will not be called in the middle
of the activity transition. However, that's not documented and hence
not guaranteed, and so while I'll describe a pattern that seems to
work, I personally don't trust it any further than I can throw your
large Froyo lawn ornament. If somebody could give us the recipe that
is guaranteed to work (i.e., works today, and is going to work in
Android 2.3/3.0/Turbo System 5000), that'd be *wonderful*.
Actually, I lied earlier. I'd choose Option #4:
Option #4: Don't do the AsyncTask in an activity. Use a Service and
have it do the AsyncTask, or use an IntentService if the sole purpose
of the service is to do stuff in a background thread. In particular,
an IntentService would be good for a download that you want to happen
regardless of what may go on with an activity (e.g., Android Market
downloading an APK), and so you don't need to worry about canceling
it.
Dianne Hackborn
What if that AsyncTask is downloading a file? Interrupting it,regardless of how nicely done, would be a bad thing wouldn't it?
Dianne Hackborn
Worst-case scenario:
Step #1: Take your UI setup that is in onCreate() and move it to a
separate method (e.g., setupViews())
Step #2: Call setupViews() from onCreate()
Step #3: Call setupViews() from onConfigurationChanged()
Done. ~4 lines of code. And it's the exact same code path that a
destroy/recreate will go down, so it's not like this adds unusual
performance overhead. There are certain circumstances where this may
not work (e.g., GLSurfaceView and a game), but you needed to do extra
work for those cases, anyway, to handle the destroy/recreate cycle.
> Saving and restoring an AsyncTask is not difficult.
No, it's not. The question is: is it reliable?
Option #4: Don't do the AsyncTask in an activity. Use a Service and
have it do the AsyncTask, or use an IntentService if the sole purpose
of the service is to do stuff in a background thread. In particular,
an IntentService would be good for a download that you want to happen
regardless of what may go on with an activity (e.g., Android Market
downloading an APK), and so you don't need to worry about canceling
it.
Mark Murphy
> Yes it is. If it isn't documented, I'll make sure it is: we guarantee that
> no messages will be processed between onRetainNonConfigurationInstance() to
> the following onCreate().
Oh, that is absolutely fantastic to hear.
I'd think it should be documented either on that method or here:
http://developer.android.com/guide/topics/resources/runtime-changes.html
Thankyouthankyouthankyou! :-)
Romain Guy
> separate method (e.g., setupViews())
>
> Step #2: Call setupViews() from onCreate()
>
> Step #3: Call setupViews() from onConfigurationChanged()
>
> Done. ~4 lines of code.
Except you would have to make sure to destroy/recreate anything your
Activity might have a reference to that would need a new
configuration. Of course you can make it work, but you can easily
break your solution in subtle ways. The only reason to handle
orientation change yourself is if the destroy/create process is very
heavy (webpage loading for instance.)
> And it's the exact same code path that a
> destroy/recreate will go down, so it's not like this adds unusual
> performance overhead.
No it is not. You are keeping the same Activity instance and any state
associated with it. It is very different.
Eric Mill
screen flips and can even maintain progress dialogs if needed, and
it's all very robust and reasonably clean - but it took a lot of
iteration and investigation.
Storing an AsyncTask is "not hard" if you understand what is
happening, but for people just getting into the Android system,
understanding that screen flips destroy Activity references and create
new ones is not trivial. It's actually really confusing and setting
it all up right is pretty delicate.
At my workplace, I'm porting an Android app over to the Windows Phone
7 platform. Many things about WP7 development are new, some are
frustrating, but there's one notably easy thing about it, which is
this exact problem. Their WebClient class automatically handles
network calls in a background thread, and you can give it a lambda or
named function as a callback to run on the UI thread once it's done.
Survives screen flips just fine, no worries about it being killed. It
Just Works(tm).
I understand that Android is a very different system than WP/
Silverlight, with different considerations that elevate the complexity
of managing all the different fedeated components of an application -
but don't write off managing AsyncTasks as "not hard". It's very hard,
and other systems make it look glaringly so.
-- Eric
On Sep 10, 2:33 pm, Dimitris <dnkou...@gmail.com> wrote:
> Wow thank you, I've been finally waiting for some clarification
> regarding how safe it is when updating the instance of the Activity in
> a task.
>
> This should be well documented and perhaps an example should be
> provided.
>
> On Sep 10, 10:13 am, Mark Murphy <mmur...@commonsware.com> wrote:
>
>
> > On Fri, Sep 10, 2010 at 1:08 PM, Dianne Hackborn <hack...@android.com> wrote:
> > > Yes it is. If it isn't documented, I'll make sure it is: we guarantee that
> > > no messages will be processed between onRetainNonConfigurationInstance() to
> > > the following onCreate().
>
> > Oh, that is absolutely fantastic to hear.
>
> > I'd think it should be documented either on that method or here:
>
> >http://developer.android.com/guide/topics/resources/runtime-changes.html
>
> > Thankyouthankyouthankyou! :-)
>
> > --
Bret Foreman
attach(String threadTag) and dettach(String threadTag) methods. You
would call dettach with a user-provided tag from your Activity's
onDestroy method and call attach with the same tag. If attach returns
false then you know there was no background thread with that tag and
you start the AsyncTask in your onCreate. If it returns true then you
know that the AsyncTask now knows about the new parent thread and also
know that you don't have to restart the task in you onCreate. Anyone
see any problems with this enhancement?
Indicator Veritatis
peculiar problems in the way the classes are designed. Service by
definition is already in the background, it HAS no UI thread, so why
do I need an AsyncTask there at all? The whole point of the latter is
to communicate between UI thread and worker thread.
As for documenting what works, I hope Google takes your hint and
documents what the right way to do this really is. After all, these
are the same people who keep warning us that "if it's not documented,
then it is subject to change w/o notice".
On Sep 10, 10:04 am, Mark Murphy <mmur...@commonsware.com> wrote:
Lance Nanek
> definition is already in the background, it HAS no UI thread, so why
thread.
> http://developer.android.com/reference/android/app/Service.html
> Note that services, like other application objects, run in the main thread of their hosting process. This means that, if your service is going to do any CPU intensive (such as MP3 playback) or blocking (such as networking) operations, it should spawn its own thread in which to do that work.
Kostya Vasilyev
> Option 4 certainly sounds like it will work, but it suggests some
> peculiar problems in the way the classes are designed. Service by
> definition is already in the background, it HAS no UI thread, so why
> do I need an AsyncTask there at all? The whole point of the latter is
> to communicate between UI thread and worker thread.
A Service runs on the UI thread by default, so some kind of mechanism to
push work to a background thread is still required. It can be a
WakefulIntentService, or, just as easily, an AsyncTask (I imagine it
takes care of acquiring a wake lock).
It seems to me (and that's just my opinion) that
onRetainNonConfigurationInstance / getLastNonConfigurationInstance is
probably the easiest way for small, one-at-a-time async tasks, where UI
feedback is supposed to be immediate.
These two methods use plain Java objects, don't require serialization or
parceling, so they are a good fit. The only issue is - switching UI
references. OnRetail... can null them out before storing the task in a
configuration object, and onStart / getLast... can store new UI
references in the task.
The task would also need to keep most recent progress state values, to
be displayed in the newly created activity.
--
Kostya Vasilyev -- WiFi Manager + pretty widget -- http://kmansoft.wordpress.com
Mark Murphy
> It seems to me (and that's just my opinion) that
> onRetainNonConfigurationInstance / getLastNonConfigurationInstance is
> probably the easiest way for small, one-at-a-time async tasks, where UI
> feedback is supposed to be immediate.
>
> These two methods use plain Java objects, don't require serialization or
> parceling, so they are a good fit. The only issue is - switching UI
> references. OnRetail... can null them out before storing the task in a
> configuration object, and onStart / getLast... can store new UI references
> in the task.
Given Ms. Hackborn's explanation of the message flow, I would agree
with your assessment. Without that guarantee, though, I couldn't trust
this model.
> The task would also need to keep most recent progress state values, to be
> displayed in the newly created activity.
Actually, that shouldn't be needed. doInBackground() should be able to
just call publishProgress(). Those messages will just get queued up
until the new activity is ready.
--
Kostya Vasilyev
>> > The task would also need to keep most recent progress state values, to be
>> > displayed in the newly created activity.
> Actually, that shouldn't be needed. doInBackground() should be able to
> just call publishProgress(). Those messages will just get queued up
> until the new activity is ready.
>
davemac
@Override
public Object onRetainNonConfigurationInstance() {
return myAsyncTask;
}
And in onCreate():
if( (myAsyncTask =
(MyAsyncTask)getLastNonConfigurationInstance()) != null)
myAsyncTask.setContext(this); // Give my AsyncTask the new
Activity reference
I added a setContext() method to MyAsyncTask which resets a local
member to be used in the on* callbacks to do UI work. I made
MyAsyncTask a completely separate class from my Activity class, and
the constructor requires a Context. This seems to work, and it seems
pretty easy to do. I realize that an AsyncTask has no chance of being
restarted the way a Service does if it comes to an untimely death. But
from the comments in this thread, I'm assuming that my Activity will
get a valid reference to the AsyncTask when it is restarted by a
Configuration Change. Yes?
- dave
On Sep 10, 1:05 pm, Dianne Hackborn <hack...@android.com> wrote:
> On Fri, Sep 10, 2010 at 9:53 AM, Maps.Huge.Info (Maps API Guru) <
>
> cor...@gmail.com> wrote:
> > What if that AsyncTask is downloading a file? Interrupting it,
> > regardless of how nicely done, would be a bad thing wouldn't it?
>
> You don't need to interrupt it. See Mark's option 2. Just don't have it
> tied to a specific activity instance.
>
> If you want to have it associated logically with the activity, you can use
> onRetainNonInstanceState() to transfer it between instances. (Though this
> is intended as an optimization, and if you rely on this then you likely
> won't get the proper semantics in other cases -- for example if the user
> leaves your app and returns to it later it could easily get killed while in
> the background and thus lose the active download. In fact you would also
> have this same problem if you use android:configChanges for many of the same
> reasons.)
>
> --
> Dianne Hackborn
> Android framework engineer
Mark Murphy
regular standalone public class (not a non-static inner class). See:
http://github.com/commonsguy/cw-android/tree/master/Rotation/RotationAsync/
> --
> You received this message because you are subscribed to the Google
> Groups "Android Developers" group.
> To post to this group, send email to android-d...@googlegroups.com
> To unsubscribe from this group, send email to
> android-develop...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/android-developers?hl=en
>
--
Mark Murphy (a Commons Guy)
http://commonsware.com | http://github.com/commonsguy
http://commonsware.com/blog | http://twitter.com/commonsguy
Android Training...At Your Office: http://commonsware.com/training
Eric Mill
solution is basically what I do, with the AsyncTask being a private
(non-static) inner class of the Activity that uses it. Store it
across screen flips, and then if it's present in onCreate, feed it the
new context.
-- Eric
On Sep 12, 1:02 pm, Mark Murphy <mmur...@commonsware.com> wrote:
> That should work, so long as MyAsyncTask is a static inner class or a
> regular standalone public class (not a non-static inner class). See:
>
Mark Murphy
> Why wouldn't that work if it's a non-static inner class? Dave's
> solution is basically what I do, with the AsyncTask being a private
> (non-static) inner class of the Activity that uses it. Store it
> across screen flips, and then if it's present in onCreate, feed it the
> new context.
Oh, technically, it'll work, but the inner class will then *also* hold
an *implicit* reference to the old activity, which you don't want, as
you'll leak memory. Since you're not using the implicit reference --
replacing it with the explicit one -- you want to use a static inner
class.
--
Mark Murphy (a Commons Guy)
http://commonsware.com | http://github.com/commonsguy
Indicator Veritatis
process and thread. Now does anyone actually use it with that same
process being an Activity? Often (though not always), it is launched
by an Alarm, not by the main process hosting the UI thread in the
first place. Then it is the Service that sends messages to the
Activity that currently has the UI.
Now since the whole purpose of AsyncTask is to provide communication
and coordination between a UI thread and a worker thread (more
conveniently than with java.lang.thread), it might make sense to use
AsyncTask in a Service only if the Service itself has a UI thread. But
although the docs you mention admit to this possibility, I am having
trouble seeing why that would ever be good design.
But knowing this group, if there are any such, someone will pop up out
of the woodwork and show us:)
Lance Nanek
anything like android:process=":remote" on the service declaration in
the manifest. Without any specific settings to prevent it like that
one, setting an alarm for a PendingIntent from
PendingIntent#getService will start the service on the same main/UI
thread that the activities in the app run on.
Dianne Hackborn
--
You received this message because you are subscribed to the Google
Groups "Android Developers" group.
To post to this group, send email to android-d...@googlegroups.com
To unsubscribe from this group, send email to
android-develop...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en
--
Android framework engineer
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.
Bluemercury
Bluemercury
Heres my onCreate of the parent activity: