Hi.
My name is Chris B. I'm a developer
advocate on the Google Cast team.
In this episode of DevBytes, I'm going
to cover some of the essentials of creating a Cast web sender
app that runs in Chrome.
Currently, the Google Cast SDK is available for three
platforms-- Chrome, Android, and iOS.
In this video, I will focus exclusively
on the SDK for Chrome.
In order to build a Google Cast web sender application,
you will lead to install the Google Chrome
browser and the Google Cast Chrome extension.
If you already have Chrome installed,
make sure you are on version 32 or higher.
To get the Cast extension, visit the Google Chrome Web Store
and search for Google Cast.
The Cast extension is what allows
web senders to communicate with Cast receivers.
With Chrome installed and the Cast extension ready to go,
let's take a peek at the Cast sender life-cycle for a moment.
Once a Cast sender application has been loaded,
the app will detect and initialize the Cast APIs,
get notified about available receivers,
connect to a receiver, and begin exchanging messages
over the established connection.
Closing up the life cycle is disconnection
from a receiver device.
Let's take a closer look at each phase of life cycle.
Chrome sender applications are constructed
using HTML, JavaScript, and CSS.
Sender apps can be hosted locally during development
and then move to production servers when publishing.
A Google hosted Cast sender JavaScript resource provides
the API that your sender application uses to communicate
with the Cast extension, which manages
the interaction with Cast receivers.
A Chrome sender application must detect and initialize
the Cast API before communicating
with the Cast receiver.
Prior to using the Cast APIs, the web sender application
needs to first check that they're available.
This is accomplished by looking for the existence
of chrome.cast JavaScript namespace
and checking the chrome.cast.isAvailable Boolean
flag.
Depending on how the web sender application loads
its resources, it may need to set up a retry timeout
to detect the Cast APIs.
With the detection out of the way,
the web sender application is now
ready to initialize the Cast API.
Initialization connects the web sender to the Cast extension
and lets the extension know that the web app is Cast enabled.
Performing the initialization consists
of creating a sender request object that
holds the application ID of the receiver that will launch.
Then, constructing a new API config object,
which takes the session request object as well as a session
listener and receiver listener callbacks.
Lastly, the web sender calls the chrome.cast.initialize function
and provides the API config object along
with the success and error callback.
When the success callback is invoked,
the web application has successfully
initialized the Cast APIs.
However, there is one more thing that the application
needs to wait on before proceeding.
Looking at the API config constructor,
the receiverListener passed in performs an important role
in the discovery Cast devices.
Cast web sender applications delegate the management
of available Cast receiver devices to the Cast extension.
The API config that the app creates
is passed along to the Cast extension.
And the receiverListener is invoked.
The receiverListener is passed a string parameter
that should be checked for the available value.
Any other value should be treated
as no receiver devices available.
The receiverListener will be invoked whenever
there is a change in the availability of receiver
devices.
The web sender should display the Cast icon
when the receiverListener reports
Cast receivers are available.
Now that the application knows when
to show a Cast icon to the user, we
can explore how to request a session on a Cast receiver
device.
It is actually quite simple.
The sender can call on chrome.cast.requestSession
and provide a success and error callback.
The success callback will be passed a Cast session
object that can be decorated with update listeners.
The success callback is dependent on user action
and may not be invoked.
Let's take a look.
Use the receiverListener as a way
to determine if the web sender application should
show the Cast icon to the user.
When the user clicks the Cast icon,
the Cast extension will show a list of available Cast receiver
devices that can be connected to by the sender.
If the user closes the list without selecting a device,
the request session error callback will be invoked.
Otherwise, if the user selects a Cast receiver device,
then the extension will communicate
with the Cast receiver to set up the communication channel.
Once complete, the success callback of the request session
function will be invoked.
With a connection established, the sender application
may now communicate with the connected Cast receiver
application.
Messages are exchanged between the sender and receiver using
namespaces, also called protocols.
These messages are used to invoke behaviors
on the receiver application and to update the sender
application as to the state of the receiver app.
One example of message exchange would
be to load some media onto the Cast receiver.
The Cast APIs come bundled with a media API that
enables a sender app to tell the receiver to load and playback
media, such as video.
In this case, the media info object
gets created that bundles information about the media.
This object is then used to create a load request
object that gets passed to a session function called
load media.
The load media function serializes
the data and communicates with the receiver application
over the media namespace.
Sender and receiver applications must
agree on the supported namespaces
in order to communicate with each other.
The last part of life cycle is the disconnection
from a receiver.
When a session is first established,
the session app is passed a session object.
Adding an update listener to the session object
allows the sender app to know when a session has ended.
The session listener function is passed a Boolean value.
If this value is false, then there is no connection.
The user can initiate a disconnect
by clicking the Cast extension and choosing stop casting.
This will trigger a session update listener
when the session is torn down.
And there you have it, the life cycle of a Cast web sender.
We're very excited to see what you build with Google Cast.
To get you going, we're providing
a number of resources.
You can discover more about the details of the Google Cast SDK
at developers.google.com/cast.
The design checklist will go a long way in guiding you
down the path to creating great second screen applications.
You can find sample Cast sender and receiver apps
at github.com/googlecast.
Use Stack Overflow for questions and comments.
Tag them with google-cast.
In future DevBytes, we will dive deeper
into the Cast sender SDK for each platform
and the Cast receiver SDK.
Join the Google Cast developer community on Google+ for pro
tips and share your experiences.
It's now up to you to go out and create great Chrome web sender
applications.
Happy casting.