Difference between revisions of "SBAppContextHostView"

From iPhone Development Wiki
Jump to: navigation, search
Line 11: Line 11:
  
 
== Special considerations ==
 
== Special considerations ==
 +
* Resizing
 
As this UIView is little more then a container view for [[CALayerHost]]s 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.<br />
 
As this UIView is little more then a container view for [[CALayerHost]]s 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.<br />
You should '''never''' use [[SBAppContextHostView]] directly. Instead go through the [[SBAppContextHostManager]] which will give you a [[SBHostWrapperView]] to use.
+
 
 +
* Render tree and superviews
 +
[[SBAppContextHostView]]s '''always''' want to be in the render tree. If they aren't and the app creates a new [[UIWindow]] (copy & paste menu, [[UIAlertView]]s and [[UIActionSheet]]s are a few examples) then it will crash the render server ([[SpringBoard]] until iOS 6 when it became [[BackBoard]].
 +
 
 +
* 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.
 +
 
  
  

Revision as of 17:52, 28 November 2012

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 view).


Special considerations

  • Resizing

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 want 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.

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.


References