Difference between revisions of "SBAppContextHostView"

From iPhone Development Wiki
Jump to: navigation, search
m (Created page with '? == References == * Demonstration: http://www.youtube.com/watch?v=EYt0OtxgSZs {{IPFHeader|SpringBoard|.app}}')
 
Line 1: Line 1:
?
+
[[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 [[CALayerHost]]s 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 [[CALayerHost]]s 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 ==
 +
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.
 +
 
  
 
== References ==
 
== References ==
 
* Demonstration: http://www.youtube.com/watch?v=EYt0OtxgSZs
 
* Demonstration: http://www.youtube.com/watch?v=EYt0OtxgSZs
 
{{IPFHeader|SpringBoard|.app}}
 
{{IPFHeader|SpringBoard|.app}}

Revision as of 01:30, 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

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.
You should never use SBAppContextHostView directly. Instead go through the SBAppContextHostManager which will give you a SBHostWrapperView to use.


References