Event dispatching is relatively simple.  There are two major models:

- Focus-based dispatching is used for key events and trackball events.
- Position-based dispatching is used for touch events.

In all cases, the dispatching you probably care about starts with an IPC
coming from the window manager into your process, telling a specific window
about an event.  This is received in the internal VIewRoot class.  This in
turn simply calls the appropriate dispatchXxx() function on the top-level
view of the hierarchy, which dispatches it down to child views based on
either the current focus target or the x/y coordinate of the event as
appropriate.  Most of the code for dispatching down the hierarchy is in
ViewGroup.  Ultimately View will receive the dispatchXxx() call and turn it
into an onKeyDown() etc.  The View class and its subclasses will also in
variation situations look at the raw events they are receiving to perform
higher-level callbacks like onClick().

Another important common pattern we have for low-level events is returning a
boolean indicating whether the receiver handled it.  If you return false,
the framework will try to perform a callback on the next target.  For both
focus and position dispatching, this means doing a callback on the parents
up the view hierarchy until someone handles it or we reach the top.  In
addition, returning true on a down of a touch event "locks in" that view as
the target, allowing to receive the following moves and final up event
regardless of where they occur on the screen; if you return false you will
not receive any more events until the next down.

We don't use any messaging for dispatching an event and the corresponding
actions that result -- this is all done through callbacks -- so in general
if you break into the debugger from a callback you can see the primary chain
from receiving the original raw event in ViewRoot through to the call you
are getting.

And of course you can look at the source code to see the actual
implementation.  There isn't a -lot- to deal with -- ViewRoot for the
initial receipt of the event, the dispatch functions on ViewRoot for
deciding where the event goes, View for the low-level callbacks, and the
appropriate class for higher-level callbacks.

On Mon, Feb 2, 2009 at 10:37 PM, Craig <[email protected]> wrote:

>
> Hi Dianne,
>
> One of the persistent problems I've had over the years developing
> GUIs, whether it be MFC, wxWndows, Swing, or now Android, has been
> understanding the exact flow of events within the framework. All is
> well if simply overriding onItemClick() is enough to get the job done.
> But as soon as an app starts getting complicated, and I need to do
> something a little different it can become a lesson in frustration
> trying to get that event to fire in the right place at the right time.
> Once you put class inheritance (i.e. overrides and handler functions),
> view hierarchies (i.e parent-child relationships), and runtime
> listeners, all in the pot, it's anyone's guess where that event will
> end up, or how best to do what you want. Given the framework soure
> code, you can try and follow the chain of events, but that is often
> impossible; without it, well, google is your friend.
>
> One example of frustration from my Android experience was trying to
> get checkbox views clicking independently of a list view row (i.e.
> *not* like the CheckBoxPreference), and still behaving normally in all
> other respects.
>
> So my question: is there a high level overview of the framework design
> philosophy, how it fits together, and specifically, the routing
> algorithms for events. I think I've read the sdk docs inside out now
> and I haven't seen one. It would be very helpful.
>
> thanks and regards,
> Craig
> >
>


-- 
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
-~----------~----~----~----~------~----~------~--~---

Reply via email to