uh, 'client and server'? Are we talking about the Activity Manager Service (service) and whatever is calling it (client)?
I imagine if I was to delve into information about the Binder mechanism for IPC that this would make more sense. Ill mark it as 'interesting but not relevent right now' cheers On Feb 23, 3:06 pm, Dianne Hackborn <[email protected]> wrote: > Usually when you see a token, it is an IBinder object that has no meaning to > the one using it except as some unique identity. That is, the interesting > thing about is not whatever interface may be behind the IBinder (if there is > one at all), but rather its existence as a unique object that both the > client and server can share and nobody else can spoof. > > > > On Sun, Feb 22, 2009 at 7:36 PM, stefoid <[email protected]> wrote: > > > cheers, Dianne. > > > I am methodically trying to understand relevent functions. One thing > > I have come across which I havent tracked down is 'token'. I see that > > it is something that implements IBinder. I suppose it is some kind of > > reference to an activity that is used by other parts of the system. > > Who uses it and how is it used? > > > On Feb 20, 8:34 pm, Dianne Hackborn <[email protected]> wrote: > > > On Thu, Feb 19, 2009 at 10:29 PM, stefoid <[email protected]> > > wrote: > > > > mHistory is used to record the 'visual' order of activities that are > > > > revealed as the user pushes 'back'. > > > > Yep. > > > > > 1) why is mHistory a single stack? You could have made each task in > > > > mRecentTasks point to a different stack instance - its own stack of > > > > activities, and have the order of tasks in mRecentTasks define the > > > > order in which the different tasks were revealed as the user pushes > > > > back through the activities of one task into the activites of the > > > > next. I assume there is something fundamental I am missing that is > > > > the reason. > > > > This is mostly legacy. The original implementation was a simple stack of > > > activities, and the concept of tasks was added later on top of that. If > > I > > > had implemented the current design all at once, I would have done it has > > a > > > more complicated data structure, but that is not how it evolved. At some > > > point that should probably be reworked, but it hasn't been worth the > > effort > > > so far. And ultimately you do need all of the history records in a > > single > > > Z-order list to manage them with the window manager. > > > > 2) is the order of tasks in mRecentTasks important? > > > > mRecentTasks is really not that relevent -- it is just an LRU list of the > > > most recent tasks the user has activitied, whether running or not. Its > > only > > > purpose is to show the recent tasks dialog when you long press on home > > (or > > > for anyone else wanting to do a task management kind of thing). > > > > It is very important to be aware that this is not -running- tasks, but > > > recently used tasks. More like a "recent documents" list in a word > > > processor than a "process list" in a process manager. > > > > -- > > > 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. All such questions should be posted on public > > > forums, where I and others can see and answer them. > > -- > 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. 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-framework" 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-framework?hl=en -~----------~----~----~----~------~----~------~--~---
