SBAppContextHostView is a UIView subclass that is used for displaying an application when it is not actually open, or when it is being manipulated. In iOS 5 apple split the management and tracking of contexts into SBAppContextHostManager, leaving SBAppContextHostView to simply be a container for the CALayerHosts which represent each window and not handling any logic code.
Where it is used
SBAppContextHostView is used for effects that need to seem as if they manipulate the application itself. 1 example of this is the multitasking bar. When the multitasking bar is shown it slides the application up to reveal the bar, but without effecting the app itself. The way it does this is by enabling context hosting on the application so the app displays into its SBAppContextHostView rather then onto screen directly. This means the switcher can then move this UIView up above the multitasking bar without effecting the application itself.
How it fits into SpringBoard
Each SBApplication has an SBAppContextHostManager to monitor the applications contexts. Each SBAppContextHostManager has an SBAppContextHostView. Below iOS 4 the SBAppContextHostView managed displaying the CALayerHosts and tracking contexts. In iOS 5 and above this has been split up into 2 separate parts so that access to the view can be controlled by the SBAppContextHostManager, now that there are more classes using it. When an object asks an SBAppContextHostManager for the view it instead returns an SBHostWrapperView with the SBAppContextHostView as a subview, so that it can then hand it to another object without causing the first any problems (besides a now empty SBHostWrapperView).
As this UIView is little more then a container view for CALayerHosts the weirdness the comes from working with them is inherited by SBAppContextHostView. For example, the view (semi) ignores it's frame and renders at the size it wants to. This is not completely true as with clipsToBounds turned on it will crop the part of the application showing to the rect specified as the frame, but the application will not scale for it. For a more detailed overview of the potential problems with using this class look at CALayerHost itself.
- Render tree and superviews
SBAppContextHostViews always wants to be in the render tree. If they aren't and the app creates a new UIWindow (copy & paste menu, UIAlertViews and UIActionSheets are a few examples) then it will crash the render server (SpringBoard until iOS 6 when it became BackBoard. This means it always has to have a superview. Using SBAppContextHostManagers methods to enable and disable context hosting will prevent this from happening.
- Don't touch SBAppContextHostView itself
You should never use SBAppContextHostView directly. Instead go through the SBAppContextHostManager which will give you an SBHostWrapperView to use with the SBAppContextHostView as a subview. This allows the SBAppContextHostManager to manage all the different objects that want to use the SBAppContextHostView for different things with minimal conflicts.
- Demonstration: http://www.youtube.com/watch?v=EYt0OtxgSZs
- Header: http://github.com/kennytm/iphone-private-frameworks/blob/master/SpringBoard/SBAppContextHostView.h