It doesn't really have anything to do with the binder. It's just that generally if you see two separate entities working together, one is providing some more basic functionality that another is using. So an application is a client of both the window manager and activity manager. Also the activity manager is a client of the window manager based on the layering of the stack -- that is, the window manager knows nothing about an "activity manager," but the activity manager makes calls on the window manager to tell it what it would like to have done. (And both of these are clients of the package manager, etc.)
On Sun, Feb 22, 2009 at 8:36 PM, stefoid <[email protected]> wrote: > > 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. > > > -- 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 -~----------~----~----~----~------~----~------~--~---
