Today, Google announced their new Chromecast smart TV device and released a developer API alongside it. This isn’t new, as most set-top boxes have APIs for developers. What’s exciting about Chromecast is that unlike all of its competitors, apps on the device itself run in a local version of the Chrome browser instead of as compiled applications. This means that--if Google opens the device up to everyone (right now there’s a whitelist)--millions of web developers are going to be able to build TV experiences for their apps from day one using the same technologies that already power their sites.
Google’s documentation is so far geared towards developers who want to stream media from their sites or apps, but because the device uses a stock Chrome browser and allows you to load any HTML page (with a few restrictions), there’s no reason you couldn’t build any kind of interactive TV experience--say, a slideshow for a news article--into a desktop web page. That’s something that Apple’s AirPlay API, which allows developers to tag embedded media on their site for AirPlay on mobile Safari, can’t do.
Most importantly, the API will be easy to use for anyone who’s ever built a Chrome extension, because its discovery and messaging systems are similar to the chrome.pageAction and chrome.runTime APIs. To detect when a Chromecast device is in range, you simply add a listener for a discovery event coming from the Chromecast extension and add a button to enable Chromecast to your page. When a user clicks on it, you push your second-screen application to the Chromecast, which sets up a messaging service between the mobile device and the Chromecast that looks very similar to messaging between background pages and content scripts for normal Chrome extensions. Google has built-in message handling for common media functions like play, pause, and volume control, but gives developers the ability to add their own custom message types as well.
The Chromecast is in some ways similar to the Companion Web experience that Microsoft announced last week, although it looks like Google’s device won’t allow you to pull up the web alongside live television yet, and the API isn’t built to allow multiple devices to control the screen at the same time (although there are some ways an enterprising developer could make that happen). But what Chromecast lacks in split-screen experience, it’s going to make up for in the ease with which developers will be able to build on it.
We talked to Polar developer Chris Butler last week about the challenges of building for Microsoft’s Companion Web, which isn’t a platform at all, more an interesting idea about web development. Because it relies on the web developer to do all of the work of passing messages between devices, Butler found it challenging to build a multi-screen app that works with Microsoft’s new XBox One.
Google’s Chromecast API treats the TV screen as a special instance of the main app and gives developers a persistent, likely WebSockets-based mechanism with which to pass messages back and forth. This messaging system effectively handles much of the event queuing work Butler had to do by hand. Taking care of these complexities makes developers happy, because they can focus on building instead of debugging. When developers are happy, they build more apps. And platforms that have more (high-quality) apps typically win.
Developer Leon Nicholls sent me a Google+ post about his first attempts to hack the Chromecast on Twitter. We now know that the device uses the DIAL protocol, which was developed by YouTube and Netflix. Nicholls found apps for YouTube, Chromecast (likely the beta "tab casting" from the announcement), Netflix and Google Music preloaded onto the device, but as mentioned above, the DIAL standard allows developers to push any HTML content onto the TV, which means it could potentially be a wide-open platform for web developers.
Other companies that have registered "first-screen" (I.E., preloaded) app names for DIAL include the BBC (iPlayer, News and Sport), Hulu, Disney, Turner Broadcasting (including "Team Coco" and "NBA GameTime"), Slingbox, Redbox and others. This doesn't mean that those companies will necessarily produce applications for the Chromecast specifically, just that they've previously expressed interest in the standard before.
[Ed. note--This is an early look at the API without having access to the device, so if there’s something I missed or didn’t quite understand, let me know on Twitter. I’d also love to hear what you think would be fun to build on Chromecast.]