Developing for the Chromecast, Part 3: Hipstacaster, example receiver

Developing for the Chromecast, Part 3: Hipstacaster, example receiver
november 1, 2013

For the purpose of demoing how to implement a full Chromecast solution, I developed a simple ”cast photos from the cloud to your TV”-solution. This example use-case is simplistic, but I think it fits pretty nicely into the ”cast media to your tv” context. It includes an Android ”sender” app, a Java JAX-RS REST-based Web Application and a HTML/Javascript ”receiver” app.


The HipstaCaster receiver app in action on my TV. Note the title, ownername and description from Flickr metadata bottom-left. The author of the beautiful photo shown on the TV is the flickr user ‘distantranges’ and is part of the returned photos when searching for #sarek (a national park in Sweden).

The typical usage is that you’ll launch the Android app, which will present you with a number of photos in a grid. The actual photos will be loaded off Flickr, but the photo metadata (title, url etc.) will be served by our own REST-service. Enable cast by pressing the Chromecast icon in the actionbar and then click on the photo you wish to view on your TV. The actionbar will also have an icon to display a slideshow of the currently loaded photos on the TV. The Android app will also support incremental load of more photos when the GridView has scrolled to the bottom, changing search tag and reloading the set of photos from scratch.

As stated previously, we need three different parts to accomondate this:

  • A REST based service exposing content we want to cast onto our television
  • A HTML5 web application that displays the content on your TV through the Chromecast device. E.g. the ”Receiver” application.
  • An Android app to act as ”Sender” application

The REST service

This service will provide a clean API to search for photos and retrieve meta-information about them, including URLs to the actual photos. So it’s rather important to note that our REST service will not expose the actual images, only information about them and the URLs to load them from. Technically I decided on something really simple for this, a basic Spring-based Web Application with Jersey as JAX-RS provider. I deploy it as a .war file to a local JBoss 7.1.1 Application Server. Typically it should run on more or less any modern java-based web container.

Internally, we’ll be using the Flickr REST interface through the Flickr4Java library. Optionally, one could consider creating some kind of ”photo fusion” solution where our API could back many photo providing services over one API. Maybe do some OAuth-based thing that can fetch your personal photos from whatever photo sharing services you typically sync your albums to.

Of course, it’s certainly very possible to use the Flickr API:s directly from the Android app, removing the need for the ”middleware” REST service altogether. But for the purpose of clarity, I think having a clean two-method API for the Android app to work with is better than consuming the Flickr API:s directly which involves some api key and token complexities, and it does open up some interesting sourcing-fusion possibilities as described above. Also, the Flickr API:s are quite slow, getting info about 20 images can take everything from 0.5 to 10 seconds. Having a proxy service in between makes it possible to use a bit of caching if necessary.

Our REST API will expose these very basic GET endpoints:

  • /rest/search/{tags}
  • /rest/photo/{photoId}

Actually, the search endpoint is the only one actually used in the current state of things.

 public Response search(@PathParam("tags") String tags, @QueryParam("page") Integer page, @QueryParam("perPage") Integer perPage) throws HipstaException {
     List<TinyPhotoDTO> l =, page);
     return Response.ok(l).build();

You can browse the full Java source code on github.

The Receiver Application

The HTML5 application includes the chromecast javascript, accepts the message protocol (web socket based) channel opened by the Android app and listens to events that tells it to show a photo from a given URL or start a Slideshow of a supplied set of photos. I derived my solution from the Google Tic-tac-toe example.

The Chromecast device uses the API key specified by the sender and looks up the whitelisted URL associated with the API key. The Chromecast then loads the actual application from this URL. For example, the API key I’ve used for development is associated with E.g. my Chromecast will load the Hipstacaster receiver app from a server on my local network. This is Google’s mechanism to keep the Chromecast ecosystem in line. For development purposes, you can send a whitelisting request to Google for your specific device, providing them with URLs.

The index.html page is nothing fancy at all, just remember to include the cast_receiver.js script from google. Note that some examples found online used an earlier version than 1.0. I had severe problems getting the messaging protocol channel established until I updated the URL below to 1.0.

Excerpt from index.html

  window.onload = onLoad;
  function onLoad() {
    var chromecastApp = new cast.receiver.Receiver("[MY API KEY]",
                    [ cast.HipstaCaster.PROTOCOL ], "", 5);            

    var hipstacaster = new cast.HipstaCaster();

So, the basic startup of the receiver application is just a few lines of code. Init the cast.receiver.Receiver object with your API key, your Protocol and then hook it together with your our own HipstaCaster object. The HipstaCaster object basically provides onMessage handling when sender apps sends something and broadcast / per-channel comms for when the receiver wants to send something to connected client(s).

Excerpts from hipstacaster.js

function HipstaCaster() {
    this.mChannelHandler =
        new cast.receiver.ChannelHandler('HipstaCasterDebug');

    /** Listeners */

So, in the hipstacaster object’s constructor method, we create a member instance of the cast.receiver.ChannelHandler and adds an event listener to it for the default EventType.MESSAGE. We then bind a prototyped (see below) onMessage method to handle incoming messages.

HipstaCaster.prototype = {
  onMessage: function (event) {
    var message = event.message;
    if (message.command == 'viewphoto') {
    } else if (message.command == 'slideshow') {

So, nothing very fancy here either. Each incoming event will have a ‘message’ body (you can also get the communication channel from the event to send immediate responses with) and for the tiny little hipstacaster protocol, I’ve specified a ‘command’ property which should be either of the two supported operations: ‘viewphoto’ or ‘slideshow’.

Finally, we also have some provisioning for broadcasting back to all connected sender applications. For the purpose of demoing this, the slideshow will tell the sender each time a new image is shown and it will also inform the sender app when the slideshow has reached the last image.

broadcast: function (message) {
        function (channel) {

The actual viewing of photos, slideshow code etc. is just standard html/javascript/jQuery/css and has nothing Chromecast specific in it. The showPhoto() code called by the onMessage handler to display a single photo looks like this:

var showPhoto = function(photoEvent) {
        var imgLoad = $('<img class="photo" id="currentphoto"/>');
        imgLoad.attr("src", photoEvent.fullsizeUrl);
        imgLoad.bind("load", function () {
            if(isNotNull(this.height) && isNotNull(this.width)) {
                var ratio = this.width / this.height;
                if(this.height > 700) {
                    $('#currentphoto').attr('height', 700);
                    $('#currentphoto').attr('width', 700*ratio);
                } else {
                    $('#currentphoto').attr('height', this.height);
                    $('#currentphoto').attr('width', this.width);

        if(isNotNull(photoEvent.description)) {
        } else {
        $('#photo_overlay').fadeIn( "slow" );

Very plain and probably not JS-ninja compliant code. The just about only noticeable thing is the load callback. Due to the fact that the full image must be loaded into the DOM before we can know its dimensions, the load callback makes it possible to adjust the size of the returned image including retained aspect ratio in case the photo is bigger than the Chromecast’s 1280×720 window resolution. The reason is that we can’t know for sure which screen resolution the Flickr ‘size_large’ will actually return.

Oh, you noticed that ”1280×720” window thing? Yes, that’s right. While the output signal to the TV definitely is 1080p and it plays 1080p content fine off YouTube, the actual size of the browser window seems to be hard-coded to a mere 1280×720. Perhaps one can debug the YouTube application and see how it handles 1080p clips. Probably downscaled to 720 by Chrome internals.

Anyway. feel free to browse the full source code for the receiver app on Github.

In the next and final post, I’ll explain the Android Sender application in more detail.

3 Kommentarer

  1. Sunil 4 år sedan

    Downloaded receiver app on Github. I’m getting R cannot be resolved to a variable when I tried to run it. I added v4, v7 jar files. Is there something I’m missing?

  2. Författare
    ErikL 4 år sedan

    Hi Sunil,

    I assume you are referring to the sender application as the receiver app is the HTML5/JS/CSS one executed on the chromecast. Anyway, the Android sender application was quite tricky to get to compile and run using the Android-branded Eclipse IDE. As I wrote in another part (2), I had to follow the instructions exactly from the Tic-Tac-Toe example to get it to work.

    The R class is auto-generated by the Android Developer IDE runtime based on layout, image files etc. and should just ”be there” if your IDE is set up correctly.

    Without more information it is rather difficult to provide more help. My first step would be following the IDE install instructions here to the letter:

  3. Priyank 3 år sedan

    Hello ErikL,
    This is really great blog and Work I must say.I found very limited things for Cromecast with image slide show during my research. your solution looks best among all.

    I have download the sender app(Android code) and tried to play with it but I stuck in application after running it on device.I found below issues.

    I have nexus 5 phone

    (1) No comecast button appear in Actionbar as shown in you screen shoots.
    (2) I only found setting button on top action bar after click on > Prefrence Screen which is telling me to add tags to load photos – I am not getting what to add in this,I have tried with multiple tags like india,USA and more but it’s just sowing loading after that.
    (3) I can only see ”Loaded 0 Images definitions from Fliker”

    There is one slide show button but no cast button is there.please provide some details on it
    How I can use your application?
    What thing I need to add in your code for my own slide show.

    I really want to know about above queries.Please provide me details on this,It will be very big help for me,


Lämna ett svar

E-postadressen publiceras inte. Obligatoriska fält är märkta *