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 <[email protected]> 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 <[email protected]> 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 > [email protected] > > 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 [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -~----------~----~----~----~------~----~------~--~---
