Currently, overlapping Views will fight over events because there is no concept of their depth in the context of event handling. For example, if two buttons overlap, and a click is issued in their overlapped area, the top button will not necessarily win.
This is [probably] why Apple has the responderChain. The chain can be built by sorting the View hierarchy by zIndex descending (opposite order of the rendering chain). The chain must be rebuilt at each frame, because each frame might result in modifications to the View hierarchy. Alternatively, we could require an explicit trigger to rebuild the chain if the former is too inefficient. But this might become daunting and error prone, too. It might also be possible to simply reverse the draw list from the previous frame, and use that as the responder chain for the next frame.
jdolan
commented
7 years ago
Currently, overlapping Views will fight over events because there is no concept of their depth in the context of event handling. For example, if two buttons overlap, and a click is issued in their overlapped area, the top button will not necessarily win.
This is [probably] why Apple has the
responderChain. The chain can be built by sorting the View hierarchy by zIndex descending (opposite order of the rendering chain). The chain must be rebuilt at each frame, because each frame might result in modifications to the View hierarchy. Alternatively, we could require an explicit trigger to rebuild the chain if the former is too inefficient. But this might become daunting and error prone, too. It might also be possible to simply reverse the draw list from the previous frame, and use that as the responder chain for the next frame.