The following procedure enables you to convert your iOS sender app from Cast SDK v2 to CAF Sender, which is based on the GCKCastContext singleton.
- CAF Sender is still distributed on the Google Cast developer website and CocoaPods, like v2.
- New classes have been added that take on responsibility for complying with the Google Cast design checklist.
- CAF Sender provides widgets that comply with the Cast UX requirements; v2 did not provide any UI components and required you to implement these widgets.
- CAF Sender design is consistent with the Cast Android SDK design.
- CAF Sender supports Bitcode, like v2.
- Closed captioning in CAF is similar to v2.
CAF Sender supports iOS version 8 and later.
In CAF, an explicit initialization step is required for the Cast framework. This
involves initializing the
singleton, using an appropriate
to specify the receiver application ID and any other global
options. This is typically done in the
GCKCastOptions *options = [[GCKCastOptions alloc] initWithReceiverApplicationID:applicationID]; [GCKCastContext setSharedInstanceWithOptions:options];
This step was not necessary in v2.
In CAF, the discovery process is started and stopped automatically by the
framework when the app comes to the foreground and goes to the background,
GCKFilterCriteria classes from v2 are
deprecated and should not be used.
Cast button and Cast dialog
In CAF, the Cast button and dialog are provided by the framework. The Cast button can be instantiated and added to the navigation bar as follows:
GCKUICastButton *castButton = [[GCKUICastButton alloc] initWithFrame:CGRectMake(0, 0, 24, 24)]; castButton.tintColor = [UIColor whiteColor]; self.navigationItem.rightBarButtonItem = [[UIBarButtonItem alloc] initWithCustomView:castButton];
The Cast button can also be added to the storyboard.
When someone taps the button, the Cast dialog is presented automatically.
In CAF, device control is largely handled by the framework. The sender
application does not need to handle connecting to the device and launching the
receiver application. The v2 class
is deprecated and should
not be used. Interaction between sender and receiver is now represented as a
"session". The CAF
class handles session lifecycle and
automatically starts and stops sessions in response to user gestures: a session
is started when the user selects a Cast device in the Cast dialog and is ended
when the user taps the "Stop Casting" button in the Cast dialog or when the
sender app itself terminates. The sender application can be notified of session
lifecycle events by registering a
protocol defines callback methods for all session lifecycle events.
class represents a session with a Cast device. The class
has methods for controlling the device volume and mute states, which was
previously done in v2 using methods on
In v2, the
protocol provided notifications of changes
to the device state, including volume, mute state, standby status, and so on.
In CAF, volume/mute state change notifications are delivered via callback
methods in the
protocol; these listeners are registered with the
All of the remaining device state notifications are
delivered via a
protocol; these listeners are registered with the
As with v2, CAF attempts to re-establish network connections that are lost due to temporary WiFi signal loss or other network errors. This is now done at the session level; a session can enter a "suspended" state when the connection is lost, and will transition back to a "connected" state when connectivity is restored. The framework takes care of reconnecting to the receiver application and reconnecting any Cast channels as part of this process.
In addition, CAF also adds automatic session resumption. If the sender
application is sent to the background or is terminated (by swiping-away or
because of a crash) while a Cast session is in progress, the framework will
attempt to resume that session when the sender application returns to the
foreground or is relaunched; this is handled automatically by the
which will issue the appropriate callbacks on any registered
Custom channel registration
In v2, custom channels (implemented using either a
subclass or a
and delegate) were registered with the
In CAF, custom channels are instead registered with the
instance. The registration can be done in the
callback method. For media applications, it is no longer necessary to explicitly
see the following section for more details.
The v2 class
is deprecated and should not be used. In CAF, it is superseded by the new
class, which provides equivalent functionality in a more convenient API.
It is not necessary to explicitly initialize or register this object; the
framework will automatically instantiate the object and register the underlying
media channel at session start time if the receiver application being connected
to supports the media namespace.
In v2, all media requests issued on the
would return a numeric request ID, and methods on
would provide this ID when sending notifications about request completion or
In CAF, all media requests issued on the
will return a
object; this object has an associated
which can be used to track the progress and eventual outcome of the request.
would send notifications about changes in the media player state on the receiver
In CAF, the
provides equivalent callbacks via its
protocol. Any number of listeners can be registered with the
GCKRemoteMediaClient, which allows multiple sender components to share the
single instance of
GCKRemoteMediaClient that is associated with the session.
In v2, the sender application had to take on the burden of keeping the user
interface in sync with the media player state on the receiver. In CAF, the class
takes on most of this responsibility; see the
documentation for examples on how to use this component.
V2 does not provide an introductory overlay UI.
In v2, you need to implement a mini controller from scratch in the sender app.
In CAF, the framework provides a control bar,
which you can add to the scenes where you want to show the persistent
controls. There are two ways to add the mini controller to a sender app:
Let the Cast framework manage the layout of the mini controller by wrapping your existing view controller with the
GCKUICastContainerViewControllerand adding a
GCKUIMiniMediaControlsViewControllerat the bottom of its view.
Add the mini controller directly to your existing view controller by using
-[createMiniMediaControlsViewController]to create a
GCKUIMiniMediaControlsViewControllerinstance and then adding it to the container view controller as a subview.
In v2, you need to implement an expanded controller from scratch in the sender app.
which you could use to more easily implement an expanded controller.
CAF adds a pre-built expanded controller widget
which you can simply add to your app. You no longer need to implement a custom expanded
-[logFromFunction:message:] method has
been deprecated in favor of