A Developer’s Guide to Implementing Chromecast

Written by: on April 17, 2017

With the release of the original Chromecast in 2013, Google immediately had a hit on their hands. Consumers were able to quickly and seamlessly broadcast media from mobile devices onto their TVs. Google also provided a framework for mobile app developers to help with discovery and messaging to a Chromecast device. From there, integration with the Cast ecosystem was a straightforward extension of an app’s mobile strategy. Chromecast immediately bridged the gap between a handset and a “leanback” experience.

As consumers’ expectations evolved, Google released new devices to meet these demands. In 2015, the second version of the Chromecast was released with improved WiFi support and a more powerful CPU to accommodate a rising interest in developing games for the platform. By 2016, the Chromecast Ultra was released which includes ethernet support, 4K output, as well as audio-only devices that act as speakers throughout your home. On top of the connected devices, Chromecast is being built into TV sets which allows consumers to begin casting directly to their new TVs. Fortunately, from a developer’s perspective, supporting each of the Chromecast variants requires no additional effort.

Terminology

When discussing a Cast implementation, there are two important components to consider. First is the sender – which is the iOS or Android device that initiates a connection and provides the user with an interface to control the connection. The second is the Receiver, which is loaded onto the Cast device and displayed via the TV—it will ultimately be responsible for displaying what the user has selected on the sender.

Why This Matters to Designers

Google recognizes the importance of providing guidelines for design and implementation to ensure a consistent experience for users. To achieve this, Google provides and continuously improves their Google Cast Design Checklist. For example, the document communicates that consistent placement of the Cast icon helps the user to understand the button is to connect or disconnect from a nearby cast device. Once connected, the user begins playback as normal within the app. Since the user can begin casting content on the TV, then continue to navigate throughout the app, the Persistent Controls help the user adjust playback from anywhere in the app.

Over time, Google has added components to the framework to facilitate implementing features to keep users engaged after initial video playback. When the sender delivers a message to the receiver to start the first piece of media, it can automatically build a list of videos or media to offer next. From there, the user can interact with the queue interface on the sender to customize their list to match their preferences. Ultimately, following the design checklist provided by Google will help users navigate the split screen experience between the sender and the receiver.

Development of the Sender

When adding Cast capabilities to an existing app, developers should begin by reviewing the documentation for the Google Cast SDK. A significant update was released in the fall of 2016 aligning APIs and supported features across iOS and Android. This SDK provides the developer with APIs to recognize when a Cast device is either on the same network or nearby via Bluetooth LE. While it also helps the developer to connect to these devices, the developer is ultimately responsible for defining the message structure and payload on both the sender and receiver.  

It is important to keep in mind that multiple devices with the same app can connect to the cast receiver simultaneously. Each device connected should show an identical UI telling the users what is playing and allow each user to control playback on the receiver. Developers should also know that a sender that disconnects will not explicitly stop playback on the receiver.  

To start playback of media on the receiver, the sender and receiver can define a message payload structure to send the data directly from the sender to the receiver. In most cases, the sender will provide metadata about the media, usually as either a URL or a unique ID to the receiver. The receiver is responsible for handling this payload and displaying the content on the TV.

Development of the Receiver

The receiver is an HTML5/JavaScript application which runs on the Chromecast device. Out of the box, Google provides three different options: a default receiver, a receiver which can be styled, or you can develop a completely custom receiver. Building a custom receiver allows for the flexibility to implement your UI, as well as implementing a messaging payload structure which works for your application. For example, if you require DRM or pass a unique ID to the receiver, you will need to build a custom receiver. Since the Chromecast device has a slimmed down version of Chrome designed for video playback, writing a receiver will feel very familiar to implementing a simple website.

Your receiver must be registered with the Google Cast SDK Developer Console. This provides you with a key you use to register your app. It also defines where the Cast device fetches your hosted resources when a cast session is initiated.

What’s Next?

As Google has shown with the release of the Chromecast Ultra and the addition of auto-playing and queuing features, we expect Google to continue to support Cast in the future. Consumers will also expect that any app which has audio or video will be able to seamlessly cast it to their Chromecast device. For example, Spotify allows users to connect to their Chromecast Audio device to play music throughout their house.

Cast isn’t Google’s only living room experience either. With the release of Google Home, users can now start video on their Cast by simply saying, “Ok Google.” These Direct Actions will be available for developers to implement the fulfillment of the request in the coming months. As we receive more information, we’ll provide further insights as Google releases more information on Direct Actions and how they can benefit media, communication, and home automation use cases.

 

Chris Mitchell

Chris Mitchell

Chris is a Technical Architect at POSSIBLE Mobile. He has successfully delivered apps to top brands such as Major League Soccer, Pac-12 and Pokémon. Outside of software development, you can find Chris hiking, fishing, and biking.

Article


Add your voice to the discussion: