Difference between revisions of "SBAppContextHostView"

From iPhone Development Wiki
Jump to: navigation, search
m (Clarified the meaning of the sentence.)
 
(11 intermediate revisions by 4 users not shown)
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.
+
'''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.
 
 
  
 
== Where it is used ==
 
== 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.
+
SBAppContextHostView is used for effects that need to seem as if they manipulate the application itself, for example, the multitasking switcher. When the switcher is shown, it slides the application up to reveal the bar, without affecting the app itself. This is accomplished by enabling context hosting, via the app's corresponding [[SBAppContextHostManager]] class. This allows the SBAppContextHostView to display the app, rather than having the app display normally, and take up the entire screen.
 
 
  
 
== How it fits into SpringBoard ==
 
== 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).
+
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 [[SBHostWrapperView]]).
 
 
  
 
== Special considerations ==
 
== Special considerations ==
* Resizing
+
=== 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 than a container view for [[CALayerHost]]s, the weirdness that comes from working with them is inherited by SBAppContextHostView. For example, the view (semi) ignores its 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 />
  
* Render tree and superviews
+
=== 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]].
+
An SBAppContextHostView ''always'' wants to be in the render tree. If they aren't and the app creates a new [[UIWindow]] (copy and paste menu, [[UIAlertView]]s and [[UIActionSheet]]s are a few examples) then it will crash the render server ({{applink|SpringBoard}} until iOS 6 when it became [[BackBoard]]). This means it always has to have a superview. Using [[SBAppContextHostManager]]s methods to enable and disable context hosting will prevent this problem from happening.
  
* Don't touch [[SBAppContextHostView]] itself
+
=== 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.
+
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 ==
  
 
== References ==
 
 
* Demonstration: http://www.youtube.com/watch?v=EYt0OtxgSZs
 
* Demonstration: http://www.youtube.com/watch?v=EYt0OtxgSZs
{{IPFHeader|SpringBoard|.app}}
+
* Header: http://github.com/kennytm/iphone-private-frameworks/blob/master/SpringBoard/SBAppContextHostView.h
 +
{{occlass|library=SpringBoard.app|navbox=1}}

Latest revision as of 16:09, 7 September 2015

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.

Where it is used

SBAppContextHostView is used for effects that need to seem as if they manipulate the application itself, for example, the multitasking switcher. When the switcher is shown, it slides the application up to reveal the bar, without affecting the app itself. This is accomplished by enabling context hosting, via the app's corresponding SBAppContextHostManager class. This allows the SBAppContextHostView to display the app, rather than having the app display normally, and take up the entire screen.

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

Special considerations

Resizing

As this UIView is little more than a container view for CALayerHosts, the weirdness that comes from working with them is inherited by SBAppContextHostView. For example, the view (semi) ignores its 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

An SBAppContextHostView always wants to be in the render tree. If they aren't and the app creates a new UIWindow (copy and 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 problem 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.

References