There actually isn't a special state for orientation changes. We just
specify that the implementation will do the destruction of the old activity
and construction of the new activity during processing of a single message,
so no other messages can be dispatched while it is doing this.
That is, there is no concept of "message dispatching turned off." If there
is a message available to be dispatched, it will be. It's just that the
next message can't be dispatched until you return from the previous on.
Also the activity lifecycle is completely independent of message
dispatching. Completely. If you enqueue a message in a handler while
executing in some activity, and that activity is completely
destroyed/finished (not being restarted), the message you enqueued will
still be processed even though the activity is gone. It is your
responsibility to remove any messages from the queue in onDestroy() if you
don't want them executed after onDestroy(). (Likewise onPause() etc.)
The same applies for AsyncTask -- it knows nothing about activities, so it
will just keep running and eventually call back with the result, regardless
of what happens to whatever activity you were in when you started it.
This is also another place to look for leaks. If you have an AsyncTask that
is an inner class of an activity, it implicitly holds a reference on the
activity. Thus if you leave it running after your activity is destroyed, it
will continue holding that reference, not allowing the activity object (and
everything it holds like its view hierarchy) to be GCed until the task
completes and calls back on your inner object of a destroyed activity.
On Sun, Jan 23, 2011 at 10:23 AM, Kostya Vasilyev <kmans...@gmail.com>wrote:
> Yes, there is that special case for orientation changes, thank you, but
> it's temporary.
>
> I suppose also if the UI thread is stuck on something and is heading for an
> ANR, then it's not processing messages either.
>
> Under normal conditions, the UI thread does process messages - here is a
> simple test (I was curious about the messaging behavior here, so spent a few
> minutes writing one):
>
> >>>>> ---------------------------
> new AsyncTask<Void, Void, String>() {
> private Context context = getApplicationContext();
>
> @Override
> protected void onPostExecute(String result) {
> Toast.makeText(context, "AsyncTask says: " + result,
> Toast.LENGTH_SHORT).show();
> }
>
> @Override
> protected String doInBackground(Void... params) {
> try {
> Thread.sleep(1000 * 5);
> } catch (InterruptedException x) {
> Log.i(TAG, x.toString());
> }
> return "Hello world";
> }
> }.execute();
> <<<<<--------------------------
>
> You can put this in onStart of any activity (the main one will do), launch
> it, and immediately press <Back> so that the activity is not only paused,
> but also destroyed.
>
> Five seconds later the toast will show up over the home screen, showing
> that onPostExecute did get called.
>
> -- Kostya
>
> 2011/1/23 Mark Murphy <mmur...@commonsware.com>
>
> On Sun, Jan 23, 2011 at 12:56 PM, Kostya Vasilyev <kmans...@gmail.com>
>> wrote:
>> > so your onPostExecute will get called as soon as
>> > doInBackground completes.
>>
>> Not necessarily.
>>
>> When doInBackground() completes, the background thread from the thread
>> pool sends a Message to a Handler, to cause onPostExecute() to be run
>> on the main application thread.
>>
>> If the main application thread is not processing messages at this
>> time, then the onPostMessage() Message will be stuck in the queue
>> until such time as that state changes.
>>
>> For example, during a configuration change, messages are not processed
>> on the old activity from onRetainNonConfigurationInstance() onward.
>> And, messages will not start up again until the new activity completes
>> onCreate(). This is how we can safely pass the AsyncTask from old to
>> new, and associate that task with the right activity, without
>> onPostExecute() being invoked during this transition.
>>
>> I *think* that messages for an activity are not processed when it is
>> paused, but I'm not certain, as I haven't tried to test that specific
>> scenario, and I don't remember a particular Googly note on the
>> subject. Heck, the only reason I know what I wrote in the previous
>> paragraph is courtesy of a post on this list from Ms. Hackborn.
>>
>> --
>> Mark Murphy (a Commons Guy)
>> http://commonsware.com | http://github.com/commonsguy
>> http://commonsware.com/blog | http://twitter.com/commonsguy
>>
>> _Android Programming Tutorials_ Version 3.1 Available!
>>
>> --
>> 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
>>
>
> --
> 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
>
--
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
