Paused/stopped Activity: what (UI) operations allowed

[Tamás Kovács]

Hello,

I know the Activity lifecycle and related concepts & definitions, but
I haven't found a clear answer to the following:

What type of operations are allowed in/after onPause,onStop? Since
onPause means we aren't foreground, and onStop means we aren't visible
at all, some UI manipulating operations might not be allowed.

Are there any operations (methods) that assume a visible Activity?

Motivation of my question: obviously, some messages sent to my UI
Handler will change on the UI, but these messages might arrive e.g.
after onPause() if the user is quickly turning on and off the device
screen, for example.

[Dianne Hackborn]

Is there something specific you are wondering about?  There aren't a general sweeping set of things you can't arbitrarily do in different states.

--
You received this message because you are subscribed to the Google Groups "android-platform" group.
To post to this group, send email to android-...@googlegroups.com.
To unsubscribe from this group, send email to android-platfo...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/android-platform?hl=en.

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

[Tamás Kovács]

Thank you, Dianne. I was thinking to things like adding/removing Views
to ViewGroups, etc. Two questions, then:

1.
In certain circumstances, I send a message via the UI Handler which
changes visibility of some of my Views. Some Views are set visible
("foreground", practically), others are set to View.GONE.

E.g. if the user turns off the screen (resulting in an onPause()) when
the message has already been sent, then the UI thread will handle the
message in the state of a turned-off screen (a paused activity).
Similarly, if the Home button is pressed, the activity gets an
onStop() too, and the message that manipulates the View visibility
might be handled when we are already in the home screen. I suppose
these are OK, as these are internal state changes in the View system,
and when the screen is on, they will be applied nicely. So I suppose
it would be unnecessary (and bad practice) to check whether we're
visible when a message is handled.

2. Someone on stackoverflow mentioned that using AlertDialog when your
Activity is not in foreground/visible will cause a BadTokenException,
because "AlertDialog creates a new window". But it didn't look to be a
too reliable comment, so this point might be irrelevant (if it's not,
please clarify it if possible).

On máj. 12, 22:20, Dianne Hackborn <hack...@android.com> wrote:
> Is there something specific you are wondering about?  There aren't a
> general sweeping set of things you can't arbitrarily do in different states.
>
> On Sat, May 12, 2012 at 11:17 AM, Tamás Kovács

> <falcon.firebre...@gmail.com>wrote:

>
>
>
>
>
>
>
>
>
> > Hello,
>
> > I know the Activity lifecycle and related concepts & definitions, but
> > I haven't found a clear answer to the following:
>
> > What type of operations are allowed in/after onPause,onStop? Since
> > onPause means we aren't foreground, and onStop means we aren't visible
> > at all, some UI manipulating operations might not be allowed.
>
> > Are there any operations (methods) that assume a visible Activity?
>
> > Motivation of my question: obviously, some messages sent to my UI
> > Handler will change on the UI, but these messages might arrive e.g.
> > after onPause() if the user is quickly turning on and off the device
> > screen, for example.
>
> > --
> > You received this message because you are subscribed to the Google Groups
> > "android-platform" group.
> > To post to this group, send email to android-...@googlegroups.com.
> > To unsubscribe from this group, send email to
> > android-platfo...@googlegroups.com.
> > For more options, visit this group at
> >http://groups.google.com/group/android-platform?hl=en.
>
> --
> Dianne Hackborn
> Android framework engineer

> hack...@android.com

[Tamás Kovács]

Or a short example: while I start a new activity with
startActivityForResult(), a non-UI thread sends a message to my UI
thread: a message that alters the UI state of the original Activity
(the one that spawns the new activity). So when the message is handled
in the Handler, the original Activity might already be paused or
stopped, because the new activity disguises it already.
(Note: I do know that I can handle this specifically, e.g. with
booleans; the question is actually if e.g. the Views of a disguised
activity can be manipulated in this case or not).

[Xiao-Feng Li]

I don't see any special restriction for you to program whatever you
want for UI manipulation, but according to the fundamental nature of
UI, it is supposed to handle "user interactions", so it automatically
won't be able to handle your touch events when it is disguised because
it has no focus to get the events. At the same time your
non-user-interaction UI operations such as clock arms still can move
if the inputs are from the system instead of the user unless you stop
the updates explicitly. Of course the system can also do some
optimizations such as not to draw the hidden views, but that is just
an optimization rather than an design.

Thanks,
xiaofeng

--
http://people.apache.org/~xli