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.
- show quoted text -
On Mon, Feb 2, 2009 at 10:37 PM, Craig <craig.b...@gmail.com> wrote:
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
So my question: is there a high level overview of the framework design