Now that the PilotSyncer can take multiple UITypeHandlers, each representing a subset of PilotFrames handled b the application there needs to be some notion of synchronization between then. For the case where one UI handler is about full screen views and one is about dialogs - the handlers need to be able to decide when to clear down its own views.
Take the following example. The stack is made up of frames
A, B, C
where A, B handled by a UITypeViewHandler, and C is handled by a UIDialogTypeHandler. Lets say D then is pushed on the stack, which represents a full screen view and we want to hide the dialog as its not currently top of the stack. UIDialogTypeHandler needs to have a callback saying something else has rendered a full screen view, so it can clear down its own views.
This is related to #19 which also needs to be aware of what views are full screen in for display logic.
Again we need to query if the new view is full screen - if yes, then all other UITypeHandlers should have a clearAllUI() call. If no then no call needed. UITypeHandlers will default to values depending on the type handled i.e. the UIVIewTypeHandler should return true by default for isFullScreenUI(Frame) whereas a UIDialogTypeHandler would return false. This should be overridable as an implementor may want some select views to return false.
Maybe UITypeHandler.isUIOpaque() would be better than UITypeHandler.isUIFullScreen()
You may be wondering what the point is of clearing other views when a new full screen view is rendered. Reasoning is that we may have a ViewHandler rendering into a rootView, a FragmentHandler rendering into a container view, and a DialogHandler raising dialogs. With multiple handlers there is no simple way of sorting the Z ordering of these respective root views.
Now that the
PilotSyncercan take multipleUITypeHandlers, each representing a subset ofPilotFrameshandled b the application there needs to be some notion of synchronization between then. For the case where one UI handler is about full screen views and one is about dialogs - the handlers need to be able to decide when to clear down its own views.Take the following example. The stack is made up of frames
A, B, C
where A, B handled by a
UITypeViewHandler, and C is handled by aUIDialogTypeHandler. Lets say D then is pushed on the stack, which represents a full screen view and we want to hide the dialog as its not currently top of the stack.UIDialogTypeHandlerneeds to have a callback saying something else has rendered a full screen view, so it can clear down its own views.This is related to #19 which also needs to be aware of what views are full screen in for display logic.
Again we need to query if the new view is full screen - if yes, then all other
UITypeHandlersshould have aclearAllUI()call. If no then no call needed. UITypeHandlers will default to values depending on the type handled i.e. theUIVIewTypeHandlershould return true by default forisFullScreenUI(Frame)whereas aUIDialogTypeHandlerwould return false. This should be overridable as an implementor may want some select views to return false.Maybe
UITypeHandler.isUIOpaque()would be better thanUITypeHandler.isUIFullScreen()You may be wondering what the point is of clearing other views when a new full screen view is rendered. Reasoning is that we may have a ViewHandler rendering into a rootView, a FragmentHandler rendering into a container view, and a DialogHandler raising dialogs. With multiple handlers there is no simple way of sorting the Z ordering of these respective root views.