Re: [android-developers] Re: Activity lifecycle... still a mystery to me
On Mon, Mar 14, 2011 at 3:25 PM, Indicator Veritatis wrote: > But (and you knew there was a 'but' coming), even this leaves > important questions unanswered. In particular, what does it mean to > "have input focus over any other activities"? You imply elsewhere that > it does NOT mean unconditional possession of focus, you imply it has > something to do with windows, but exactly what it does mean is not > stated here nor (anywhere I could find) in the original online docs. > Windows are in Z order. The top-most window in Z order that wants input focus gets it. The window manager implements a simple policy for Z ordering. The parts of interest here are: 1. All windows associated with activities at the bottom, ordered by the global activity stack. 2. Toasts (which can't get input focus). 3. Status bar elements. 4. System dialogs (like crash / ANR dialogs). 5. Lock screen and its UI elements. Thus if your activity is resumed, it is at the top of the stack, and if it asks for input focus it will take it from all other activities since those are below it. However windows can still be on top of it, which can take input focus away from it. (Sorry about being slow on this, I have been having trouble with my account.) -- 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
Re: [android-developers] Re: Activity lifecycle... still a mystery to me
On Mon, Mar 21, 2011 at 10:59 PM, DulcetTone wrote: > My app responds to speech commands. > > I want the behavior to be that > > 1. if back is hit on my initial activity, it exits. That is normal behavior. > 2. My app has a few sub-activities it may launch on user speech- or > GUI input > 3. if home is hit on ANY of my activities, I want all of them to > finish. Again, I ask: why? > Why I want this is uninteresting... Then don't expect much help. I'm not asking "why" because I expect the reason to be interesting, I am asking "why" because you are clearly confused, so I am trying to get to the real problem here. > few users of the app would find > the desired behavior anything other than the one they'd want. That's conceivable, but unlikely, since your users probably want your app to behave like all their other apps. What do you think the difference is between: "if home is hit on ANY of my activities, I want all of them to finish" and: "if home is hit on ANY of my activities, the home screen should appear" since the latter is the standard behavior? The home screen will appear in either case. Clearly, you think that there is some difference. We need to know what the behavior difference is that you are expecting, so we can guide you on how to achieve it. -- Mark Murphy (a Commons Guy) http://commonsware.com | http://github.com/commonsguy http://commonsware.com/blog | http://twitter.com/commonsguy _The Busy Coder's Guide to Android Development_ Version 3.5 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 For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
Re: [android-developers] Re: Activity lifecycle... still a mystery to me
13.03.2011 10:29, Indicator Veritatis пишет: > > I want to perform certain actions when the BACK or HOME keys are > > pressed, and ignore cases where a third-party activity simply pops up > > on part of the screen and then goes away. > > If you find yourself needing this, perhaps you need a Service. Why a Service? Services are meant for either 1) long-running operations in the background, operations that do not need UI or 2) exposing this component's functionality to other components, using IBinder if the latter are in other applications. Because he's trying to determine when the user "really" leaves his activity vs. when it's temporarily occluded. This is most likely to either continue or stop doing something. I'm speculating, but it seems likely. An oath he should take seriously. He asked for a response that could be "vouched for" - and since I can't sign in blood using email, that was the best I could do :) Let's hope he hasn't heard the famous Turgenev quote, "каждый Русский -- неисправаемый лгун";) Turgenev was Russian, too, so that's just like "All Cretans are liars" :) -- Kostya Vasilyev -- http://kmansoft.wordpress.com -- 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
Re: [android-developers] Re: Activity lifecycle... still a mystery to me
2011/3/12 Indicator Veritatis > Actually, comparing with the text, I don't think it means "just what > is says". There is an asymmetry in the states, an asymmetry I believe > is deliberate, if poorly explained: that between onPause and onResume: > when you enter onPause, you may still be partially visible, but you > lose input focus. But when you enter onResume you must have both full > visibility and input focus. > onResume() is called when you are becoming the top activity on the global activity stack. onPause() is called when you are going away from that state (prior to a different activity becoming the top). I'm not sure how this is asymmetrical? There are important implications about being the top activity -- for example you will have input focus over any other activities, your window will be on top of all other activities, etc. However there are some subtle aspects of this. In particular, being the top activity does *not* guarantee being input focus; input focus is based on windows, and there are a number of Android UI elements that are implemented as pure windows. This includes the lock screen, and notification shade. When one of these elements is shown, the top activity's window will lose input focus for that time. There are really three important pairs to the activity lifecycle: onCreate() / onDestroy() onStart() / onStop() onResume() / onPause() Any resources you create in the first of the pair should generally be released in the matching one. For example, if you use registerReceiver() in onCreate(), you should generally call unregisterReceiver() then in onDestroy(). These pairs represent symmetric major states of an activity: onCreate() is when it is first created, onDestroy() is when it is last being cleaned up; onStart() is when it is becoming visible, onStop() is when it is no longer going to be visible to the user. And we already talked about onResume() and onPause(). > > Finish would cause it too - your activity is about to not be visible > > (since it's going away). > Cause what, too? > It causes your activity to go through onPause() and onStop() (if needed) since it is no longer going to be visible to the user, and then onDestroy() since the activity instance is being destroyed. > But what does "front-most position" really mean? That is what confuses > many, not just the OP when reading the online documentation about the > Activity lifecycle. My best attempt at reading the mind of the online > doc's author is that "front-most position" means not only 1) being > fully visible, most likely completely covering up all other > Activities, but also 2) capturing input focus from all input devices: > touch screen, keyboard... > It really just means top of the activity stack, and since the windows created by activities are Z-ordered in the window manager based on that stack, its windows are on top, bringing along all of the repercussions of that both visually and for input focus. > > > 3. How is onPause() -> onResume() different than onStop() -> > > > onRestart()? What circumstances differentiate the flow? > > onStart / onResume depend on what happened before. > In what way do they depend? Isn't it just a matter of onPause() -> > onResume() being as the documentation says, the foreground lifetime of > the Activity has started? While onStop() -> onRestart() is quite > different? > I would ignore onRestart(). It is useful for some semi-common situations we saw during app developer, where one wants to do some work when being started but not duplicate stuff that was already done in onCreate(). For the basics of the activity lifecycle, though, the 3 pairs are the important things to understand. > I actually did work on a project where they somehow defeated the > normal behavior of the home key -- and I hated that feature. I am sure > most users feel the same way. > Generally we consider this a security hole and fix this. The current platform has closed all the holes I know of; if there are new ways people have found to prevent the home key from working correctly, I would love to get a hold of the app to fix it. :) -- 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
