[android-developers] Re: Ideas behind Android's task concept
Hey Mike, no, this also happens on my G1 ;-( Cheers, Mariano On Sun, May 10, 2009 at 1:36 PM, Mike Hearn mh.in.engl...@gmail.com wrote: If you press back and arrive at the same activity you started on, I think that's a bug that I've only seen when using Eclipse to develop. I think if you press back as far as you can possibly go, until you reach the home screen, then run the app from the phone (not from eclipse) it will behave normally. Running the app from the IDE seems to screw around with the task stack for some reason. On May 9, 3:49 pm, Mariano Kamp mariano.k...@gmail.com wrote: I still don't get it ;-( I have the top level activity, let's call it A, that is used by the launcher and have the android:clearTaskOnLaunch attribute set to true. A drills down to B and B to C. Now when I am on activity C and switch to Gmail and back to my app/task then C is up. If I launch the task activity A is displayed not C, which is what I want. But when pressing Back on A I get to A again. That doesn't seem right to me. Shouldn't A have been cleared too, so that Back would return me to the launch screen? On Fri, May 8, 2009 at 5:08 PM, Mariano Kamp mariano.k...@gmail.com wrote: Isn't that the same model that is used on the Desktop?Launching an app usually puts you in a clean state, but switching back to a running instance (Alt/Cmd+Tab) brings you to the screen of the app you were most recently on.That makes perfect sense to me. Actually now that I learned about android:clearTaskOnLaunch [use in contacts http://android.git.kernel.org/?p=platform/packages/apps/Contacts.git;...] here, I can finally try to get my app to behave like I would expect it to. This discussion is very enlightening. Dianne that would be a great topic for a blog post of yours, wouldn't it? ;-) On Fri, May 8, 2009 at 3:07 PM, Mike Hearn mh.in.engl...@gmail.com wrote: As far as contacts goes, though, this is actually intentional -- some apps (like contacts and settings) want to put the user back to their front door when relaunched from home, so they set the option to do that. This is actually a desired inconsistency. Right, I realise it's intentional. What I'm unclear on is, why these apps are special? I presume usability testing revealed this is the behavior users expected. In which case why not reset task stacks for every app? --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[android-developers] Re: Ideas behind Android's task concept
If you press back and arrive at the same activity you started on, I think that's a bug that I've only seen when using Eclipse to develop. I think if you press back as far as you can possibly go, until you reach the home screen, then run the app from the phone (not from eclipse) it will behave normally. Running the app from the IDE seems to screw around with the task stack for some reason. On May 9, 3:49 pm, Mariano Kamp mariano.k...@gmail.com wrote: I still don't get it ;-( I have the top level activity, let's call it A, that is used by the launcher and have the android:clearTaskOnLaunch attribute set to true. A drills down to B and B to C. Now when I am on activity C and switch to Gmail and back to my app/task then C is up. If I launch the task activity A is displayed not C, which is what I want. But when pressing Back on A I get to A again. That doesn't seem right to me. Shouldn't A have been cleared too, so that Back would return me to the launch screen? On Fri, May 8, 2009 at 5:08 PM, Mariano Kamp mariano.k...@gmail.com wrote: Isn't that the same model that is used on the Desktop?Launching an app usually puts you in a clean state, but switching back to a running instance (Alt/Cmd+Tab) brings you to the screen of the app you were most recently on.That makes perfect sense to me. Actually now that I learned about android:clearTaskOnLaunch [use in contactshttp://android.git.kernel.org/?p=platform/packages/apps/Contacts.git;...] here, I can finally try to get my app to behave like I would expect it to. This discussion is very enlightening. Dianne that would be a great topic for a blog post of yours, wouldn't it? ;-) On Fri, May 8, 2009 at 3:07 PM, Mike Hearn mh.in.engl...@gmail.comwrote: As far as contacts goes, though, this is actually intentional -- some apps (like contacts and settings) want to put the user back to their front door when relaunched from home, so they set the option to do that. This is actually a desired inconsistency. Right, I realise it's intentional. What I'm unclear on is, why these apps are special? I presume usability testing revealed this is the behavior users expected. In which case why not reset task stacks for every app? --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[android-developers] Re: Ideas behind Android's task concept
Hopefully we can have full UI design docs for this. :) Yay, yes please :) A HIG for Android would be great. Partly because I Anyway, I'll see. The material I wrote in the application model docs was supposed to explain a lot of this. I find it helpful, but it explains the how and not the why or when. From what I can tell we're meant to intuit whether our app should clearTaskOnLaunch or not, which is going to lead to a lot of inconsistency. I left my app at the default, but I'm honestly not sure if it was the right decision. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[android-developers] Re: Ideas behind Android's task concept
I still don't get it ;-( I have the top level activity, let's call it A, that is used by the launcher and have the android:clearTaskOnLaunch attribute set to true. A drills down to B and B to C. Now when I am on activity C and switch to Gmail and back to my app/task then C is up. If I launch the task activity A is displayed not C, which is what I want. But when pressing Back on A I get to A again. That doesn't seem right to me. Shouldn't A have been cleared too, so that Back would return me to the launch screen? On Fri, May 8, 2009 at 5:08 PM, Mariano Kamp mariano.k...@gmail.com wrote: Isn't that the same model that is used on the Desktop?Launching an app usually puts you in a clean state, but switching back to a running instance (Alt/Cmd+Tab) brings you to the screen of the app you were most recently on.That makes perfect sense to me. Actually now that I learned about android:clearTaskOnLaunch [use in contactshttp://android.git.kernel.org/?p=platform/packages/apps/Contacts.git;a=blob;f=AndroidManifest.xml;h=71a90eb3b6f4d1a7285a462d0965aeb6660506ca;hb=HEAD#l149] here, I can finally try to get my app to behave like I would expect it to. This discussion is very enlightening. Dianne that would be a great topic for a blog post of yours, wouldn't it? ;-) On Fri, May 8, 2009 at 3:07 PM, Mike Hearn mh.in.engl...@gmail.comwrote: As far as contacts goes, though, this is actually intentional -- some apps (like contacts and settings) want to put the user back to their front door when relaunched from home, so they set the option to do that. This is actually a desired inconsistency. Right, I realise it's intentional. What I'm unclear on is, why these apps are special? I presume usability testing revealed this is the behavior users expected. In which case why not reset task stacks for every app? --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[android-developers] Re: Ideas behind Android's task concept
Yeah I will certainly agree that this is a bit of a mess -- it was unfortunately the result of a lot of continual iteration on the UI (often of different apps independently), leading to new feature requests each time, causing an every growing number of options. :/ We are working on cleaning up and better formalizing the overall navigation model, but that will be an ongoing process. For example in Cupcake we have finally laid down some basic rules for notifications where pressing back should always return you to whatever your were immediately previously doing, and I believe all of the standard apps now follow this. As far as contacts goes, though, this is actually intentional -- some apps (like contacts and settings) want to put the user back to their front door when relaunched from home, so they set the option to do that. This is actually a desired inconsistency. (And something you may not know -- if you select one of these apps from the long-press-on-home task switcher, this will bring it to the foreground without clearing it... I would like to make this level of task switching more discoverable and integrated with the core UI.) On Thu, May 7, 2009 at 1:41 PM, Mike Hearn mh.in.engl...@gmail.com wrote: Can someone educate me about the rationale behind Android tasks? I'm also curious to know the thought process behind their design when they were originally conceived? I think the problem they solve is that it's hard to have a multi- tasking OS when only one thing can be on the screen at once. So the idea of tasks is that you can switch quickly between them, and they preserve your state in the context of that application: Maps - View Business Details Contacts - View Contact - Edit Contact Now if am editing a contact and want to do something else like view business details, I can go back home, press the Maps icon, do whatever, and then use home to press contacts and arrive back at the edit contact screen. I guess there are a few problems with the current implementation though: it's quite complicated, and there's no real way for users to learn how it works. The obvious mental model is of a linear stack of activities, but that's not what actually happens so you get things like pressing back on the home screen does not actually take you back. And then there is a lack of guidelines around when to use the activity modes - as you have found. And finally the built-in apps do use the activity modes inconsistently. For instance my example is wrong because the contacts app does reset the task stack. I think this stuff will shake out with time. Better animations can help users figure out the application model. UI guidelines will help developers. Hopefully the built-in apps will either become consistent or at least call out in their manifests why they use certain attributes so people can learn from them. -- 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 -~--~~~~--~~--~--~---
[android-developers] Re: Ideas behind Android's task concept
As far as contacts goes, though, this is actually intentional -- some apps (like contacts and settings) want to put the user back to their front door when relaunched from home, so they set the option to do that. This is actually a desired inconsistency. Right, I realise it's intentional. What I'm unclear on is, why these apps are special? I presume usability testing revealed this is the behavior users expected. In which case why not reset task stacks for every app? --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[android-developers] Re: Ideas behind Android's task concept
Isn't that the same model that is used on the Desktop?Launching an app usually puts you in a clean state, but switching back to a running instance (Alt/Cmd+Tab) brings you to the screen of the app you were most recently on.That makes perfect sense to me. Actually now that I learned about android:clearTaskOnLaunch [use in contactshttp://android.git.kernel.org/?p=platform/packages/apps/Contacts.git;a=blob;f=AndroidManifest.xml;h=71a90eb3b6f4d1a7285a462d0965aeb6660506ca;hb=HEAD#l149] here, I can finally try to get my app to behave like I would expect it to. This discussion is very enlightening. Dianne that would be a great topic for a blog post of yours, wouldn't it? ;-) On Fri, May 8, 2009 at 3:07 PM, Mike Hearn mh.in.engl...@gmail.com wrote: As far as contacts goes, though, this is actually intentional -- some apps (like contacts and settings) want to put the user back to their front door when relaunched from home, so they set the option to do that. This is actually a desired inconsistency. Right, I realise it's intentional. What I'm unclear on is, why these apps are special? I presume usability testing revealed this is the behavior users expected. In which case why not reset task stacks for every app? --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[android-developers] Re: Ideas behind Android's task concept
On Fri, May 8, 2009 at 6:07 AM, Mike Hearn mh.in.engl...@gmail.com wrote: Right, I realise it's intentional. What I'm unclear on is, why these apps are special? I presume usability testing revealed this is the behavior users expected. In which case why not reset task stacks for every app? Because you don't want this for every app. If we had a task switcher at the core of the UI like the app launcher, you could make an argument for launching always restarting the app. In fact, early versions of the UI were like that. We found it to be too confusing. So we settled on a single primary way to launch/switch apps, which would reset certain apps when that is nearly always what you want. -- 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 -~--~~~~--~~--~--~---
[android-developers] Re: Ideas behind Android's task concept
On Fri, May 8, 2009 at 8:08 AM, Mariano Kamp mariano.k...@gmail.com wrote: This discussion is very enlightening. Dianne that would be a great topic for a blog post of yours, wouldn't it? ;-) Hopefully we can have full UI design docs for this. :) I kind-of avoid writing blog posts, because that would take the last little bit of time I have for coding these days. :/ (Or I guess I could take the time I spent reading and posting to these groups. :p) Anyway, I'll see. The material I wrote in the application model docs was supposed to explain a lot of this. -- 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 -~--~~~~--~~--~--~---
[android-developers] Re: Ideas behind Android's task concept
Hi, Mike, thanks for your views.I agree that this model is more complex because there are no formal rules that associate launch modes with the properties of activities. I'm sure I'll have more questions in the coming days :) 2009/5/8 Mike Hearn mh.in.engl...@gmail.com: Can someone educate me about the rationale behind Android tasks? I'm also curious to know the thought process behind their design when they were originally conceived? I think the problem they solve is that it's hard to have a multi- tasking OS when only one thing can be on the screen at once. So the idea of tasks is that you can switch quickly between them, and they preserve your state in the context of that application: Maps - View Business Details Contacts - View Contact - Edit Contact Now if am editing a contact and want to do something else like view business details, I can go back home, press the Maps icon, do whatever, and then use home to press contacts and arrive back at the edit contact screen. I guess there are a few problems with the current implementation though: it's quite complicated, and there's no real way for users to learn how it works. The obvious mental model is of a linear stack of activities, but that's not what actually happens so you get things like pressing back on the home screen does not actually take you back. And then there is a lack of guidelines around when to use the activity modes - as you have found. And finally the built-in apps do use the activity modes inconsistently. For instance my example is wrong because the contacts app does reset the task stack. I think this stuff will shake out with time. Better animations can help users figure out the application model. UI guidelines will help developers. Hopefully the built-in apps will either become consistent or at least call out in their manifests why they use certain attributes so people can learn from 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 -~--~~~~--~~--~--~---
[android-developers] Re: Ideas behind Android's task concept
I was thinking of preparing a bunch of matrices that capture various details. For instance, we can have a matrix that expresses the result of composing activities with different launch modes. Another matrix may capture the effect of taskAffinity and such factors. My major interest is in defining a set of activity-composition rules. I hope I'm clear :) If others can spare time to review, I can post a couple such matrices soon. thanks On Fri, May 8, 2009 at 10:21 PM, Dianne Hackborn hack...@android.com wrote: On Fri, May 8, 2009 at 8:08 AM, Mariano Kamp mariano.k...@gmail.com wrote: This discussion is very enlightening. Dianne that would be a great topic for a blog post of yours, wouldn't it? ;-) Hopefully we can have full UI design docs for this. :) I kind-of avoid writing blog posts, because that would take the last little bit of time I have for coding these days. :/ (Or I guess I could take the time I spent reading and posting to these groups. :p) Anyway, I'll see. The material I wrote in the application model docs was supposed to explain a lot of this. -- 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 -~--~~~~--~~--~--~---
[android-developers] Re: Ideas behind Android's task concept
Tasks are purely there for UI navigation -- they basically take on the roll of an application for the user, in lieu of a more rigid 1 apk == 1 process == 1 icon == 1 app model. A task really has little identity of its own -- without some activity, a task doesn't exist. It is just a way to group related activities together for purposes of managing flow through the UI. For launch mode, I would strongly discourage from using singleTask unless you understand what that is, why the default interaction model doesn't work for your app, and how singleTask changes it to do what you want. The vast majority of apps don't need it. The Browser does use it, but I would argue that this is as much to its detriment as to its advantage. As far as the thought process... well, first there were activities, and that was all. A single linear activity stack was not enough for the UI navigation we ended up doing, though, so the concept of tasks was created as a way to group related activities together so they could be moved around in the history. If you look at the activity manager implementation, you can still see many remnants of the fact that tasks were a later addition -- the activity manager is still all oriented around a single global stack of activities, and the implementation of tasks is actually just re-ordering operations on that single list. So while the model we present is that each task has its own activity stack, the implementation hasn't actually caught up to that. (Actually this global list ends up being useful to have, anyway, to give the window manager a single holistic Z-ordering of all windows... but if we had started with tasks as a formal concept from the start, it is unlikely we would have ended up with the current implementation.) On Thu, May 7, 2009 at 11:59 AM, devi prasad dpras...@gmail.com wrote: I've been trying to understand the key concepts that make up the Android programming model. I'm impressed as well as intrigued by 'tasks' that stack up activities. I do not really appreciate why and how one assigns a particular launch mode to an activity. For instance, I'd like to define a few necessary conditions for marking an activity the root of a new task. I'm focusing particularly on the 'singleTask' launch mode. I'd like to know, for example, whether security, user experience, and such factors decide the launch modes... Can someone educate me about the rationale behind Android tasks? I'm also curious to know the thought process behind their design when they were originally conceived? thanks -- 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 -~--~~~~--~~--~--~---
[android-developers] Re: Ideas behind Android's task concept
Can someone educate me about the rationale behind Android tasks? I'm also curious to know the thought process behind their design when they were originally conceived? I think the problem they solve is that it's hard to have a multi- tasking OS when only one thing can be on the screen at once. So the idea of tasks is that you can switch quickly between them, and they preserve your state in the context of that application: Maps - View Business Details Contacts - View Contact - Edit Contact Now if am editing a contact and want to do something else like view business details, I can go back home, press the Maps icon, do whatever, and then use home to press contacts and arrive back at the edit contact screen. I guess there are a few problems with the current implementation though: it's quite complicated, and there's no real way for users to learn how it works. The obvious mental model is of a linear stack of activities, but that's not what actually happens so you get things like pressing back on the home screen does not actually take you back. And then there is a lack of guidelines around when to use the activity modes - as you have found. And finally the built-in apps do use the activity modes inconsistently. For instance my example is wrong because the contacts app does reset the task stack. I think this stuff will shake out with time. Better animations can help users figure out the application model. UI guidelines will help developers. Hopefully the built-in apps will either become consistent or at least call out in their manifests why they use certain attributes so people can learn from 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 -~--~~~~--~~--~--~---
[android-developers] Re: Ideas behind Android's task concept
Dianne, thanks much for the details. I had, in fact, taken a look at the implementation of ActivityManager, and now I need to go back to it again. Thanks for clarifying the evolutionary growth of these ideas. I agree with you about the singleTask launch mode. It's strangeness is what led me to this question -- honestly! On Fri, May 8, 2009 at 1:06 AM, Dianne Hackborn hack...@android.com wrote: Tasks are purely there for UI navigation -- they basically take on the roll of an application for the user, in lieu of a more rigid 1 apk == 1 process == 1 icon == 1 app model. A task really has little identity of its own -- without some activity, a task doesn't exist. It is just a way to group related activities together for purposes of managing flow through the UI. For launch mode, I would strongly discourage from using singleTask unless you understand what that is, why the default interaction model doesn't work for your app, and how singleTask changes it to do what you want. The vast majority of apps don't need it. The Browser does use it, but I would argue that this is as much to its detriment as to its advantage. As far as the thought process... well, first there were activities, and that was all. A single linear activity stack was not enough for the UI navigation we ended up doing, though, so the concept of tasks was created as a way to group related activities together so they could be moved around in the history. If you look at the activity manager implementation, you can still see many remnants of the fact that tasks were a later addition -- the activity manager is still all oriented around a single global stack of activities, and the implementation of tasks is actually just re-ordering operations on that single list. So while the model we present is that each task has its own activity stack, the implementation hasn't actually caught up to that. (Actually this global list ends up being useful to have, anyway, to give the window manager a single holistic Z-ordering of all windows... but if we had started with tasks as a formal concept from the start, it is unlikely we would have ended up with the current implementation.) On Thu, May 7, 2009 at 11:59 AM, devi prasad dpras...@gmail.com wrote: I've been trying to understand the key concepts that make up the Android programming model. I'm impressed as well as intrigued by 'tasks' that stack up activities. I do not really appreciate why and how one assigns a particular launch mode to an activity. For instance, I'd like to define a few necessary conditions for marking an activity the root of a new task. I'm focusing particularly on the 'singleTask' launch mode. I'd like to know, for example, whether security, user experience, and such factors decide the launch modes... Can someone educate me about the rationale behind Android tasks? I'm also curious to know the thought process behind their design when they were originally conceived? thanks -- 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 -~--~~~~--~~--~--~---
