The Chromecast Development Process: Sender Applications, Receiver Applications, & Dogfooding
As developers we see challenges in everyday situations, whether it comes to programming, solution gathering, specs or mundane tasks. Google Chromecast development is a more recent challenge that developers need to tackle as TV Everywhere and Connected Devices become more pervasive. This post will discuss the Chromecast development process, detailing sender application, receiver application, and Google Dogfooding requirements.
Developing Apps for Chromecast
Chromecast is a solution to the problem of streaming content from an application on a device (a “Sender”) to a display that is connected to the Chromecast device itself (a “Receiver”); but, it also comes with its own challenges.
These challenges can be divided into three distinct but interconnected categories:
- Building the Chromecast-enabled sender application
- Developing the receiver application to receive the data
- Meeting Google’s Dogfooding requirements
1. Sender Applications (The Device)
Chromecast supports applications developed for Android, iOS and Chrome platforms. Sending data from the device to the display creates issues dependent on what type of receiver application is being developed, which will be discussed later on.
The main question that needs to be asked when developing a sender application is: “what type of sender application do I need?” Most applications that prospectively want to support Chromecast are existing applications already on the market. Chromecast gives these applications additional leverage in terms of attracting users. The type of sender application that needs to be developed depends on what platform the application is built on Android, iOS or Chrome.
For Android, if the application streams media, there are two options depending on what classes you use within the application. If the application uses the “ActionBarCompat” class then you must use the Cast Companion Library. If the “ActionBarCompat” class is not used, but the “FragmentActivity” class is, then the integration of the MediaRouter cast is necessary. If neither of these classes is contained within the application then a custom button must be created that acts like the MediaRouter button described in the MediaRouter API guide.
The other side of the coin is if the application does not stream media. If this is the case, the application can still stream to the display that the Chromecast is connected with, but there are non-media receiver examples that need to be replicated in order to do so. Lots of options, but it is important to identify what is contained within the application before messing with the integration of Chromecast on the sender side.
For iOS and Chrome, it is oddly more simple than Android. There is a sample app that Google generously supplies called “Google Cast Chrome Sender SDK: Hello Videos” that outlines the steps necessary to get media streaming from the device to the display. Once again, if the idea is to not stream media from the device, there are non-media examples available.
2. Receiver Applications (The Display)
When the device pushes content out to the Chromecast, that content gets displayed on what is called the receiver. In order to display the content, a receiver application must be developed. But what type of receiver application must this be?
A receiver application must provide the UI to display content, handle messages from the sender application to control the content, and handle custom messages that are application-specific (custom receiver only). There are three different types of receiver applications that can be developed: default media receiver, styled media receiver, and custom receiver.
Default Media Receiver
The default media receiver is a pre-built receiver application that makes it easy to stream media directly to a display without any fuss with UI elements. The only question that really needs to be asked for this type of application is whether or not there is a need for custom UI styling. If UI is not important, the default media receiver application is the way to go. Hosted by Google, this receiver does not require you to register with the Developer Console and provides default IDs for use with the application. In other words, it loads the URL of the media and casts it to the display.
Styled Media Receiver
The styled media receiver is used when you want to stream media but have a custom look and feel to the UI. An application using the styled media receiver can have color and branding assets provided through a link to a custom made CSS file.
Custom Receiver
The custom receiver works much differently than the rest of the receivers. If the application provides content such as a game, image gallery, or media types outside of a pre-supported media list, or if there is a requirement for digital rights management (DRM), then a custom receiver application must be developed. The other big difference with this receiver is that the developer must host the application instead of Google, and it must be implemented using the Javascript Receiver API (for external transcoding or javascript transcoding).
Reasons for choosing this route vary. It is possible that the styled media receiver does not contain enough manipulation for the desired design, so using the custom receiver will give more flexibility for that type of development. Pre/mid/post advertising and authorization/authentication functions are other reasons a developer might build a custom receiver application.
3. Dogfooding
Dogfooding is a slang term that demonstrates when a company uses/tests its own product on a wide-spread audience within the company before it becomes public-facing. Google has taken this logic and used it to its advantage to test their products within their own company before they go to market. They’ve extended this practice to Chromecast-enabled applications as well, and thus it is an essential part of the of the Chromecast development process.
Google has created a very strict checklist of requirements that a developer must meet in order to have the application get through the first stages of testing. This includes categories such as:
- Device/OS Coverage
- Device Discovery
- Cast
- Playback Control
- Synchronization
- DRM/Authentication
- UX Guidelines
- Burn-in
- Endurance
- Negative Tests
- Standard Tests
All of these requirements need to happen before the application can go into the “dogfood” phase of testing. The dogfood phase consists of versions of the application with features unavailable to the public. Bugs are discovered in less stable features so that they are not passed along to customers upon release. Often times, dogfooding covers the edge and corner cases not primarily discovered during regular testing. Product quality and usability also change during this phase dependent on the reaction the application receives. It always helps to get as much testing out of a product before it launches to ensure near-perfect results.
The focus on Google Chromecast is in two parts: sender (device) and receiver (display). A development company must make choices when it comes to how they want the application to be built. This mostly depends on what the application is trying to do and what type of content it is trying to stream. Regardless of the choices, developers must also be prepared to go through the Google dog food process in order to meet the requirements set for Chromecast apps.
