Just more development things.

Some of you (who are you?  WHO ARE YOU?!?!?) may have noticed the following in a recent blog post concerning the Vizio SmartCast products:

Whatever transport controls the speaker supports are hidden away as swipe and tap gestures within the ring.

Truthfully there are only two supported gestures: play/pause (the “tap”) and next-track (the “swipe”, which can occur in any direction).  And being the deranged soul I am, and in the name of Progress(tm), I decided to dive down the rabbit hole that would hopefully end in being able to use these gestures to control my (11-year-old-)music system.

Some background.  What I really like about Cast is that it really does provide a comprehensive bridge to the hardware that’s rendering your content.  I talked briefly about the API’s messaging abilities and how I primarily use my own messaging solution to have clients (“remotes”) talk to the Cast devices (as “renderers”).  But I have to say, there was an embarrassing level of giddiness on my part once I was able to turn said ring on the Vizio devices and watch volume level automagically change in my music system interface.

That sort of dark magic is powered in large part by the messaging features in the API.  And the closer you come towards full Cast API compliance, the more your powers level-up:

• rich media metadata (including images) in the Google Home app and Cast notification
• a track scrubber that updates in real-time on certain Cast clients
• interaction via the (much maligned-)Cast nofitication that appears on your Android device when something is Casting on the network

Sooo… like some Dr. Frankenstein groupie I’ve settled on an implementation that mixes Google’s magic with my own amateur code and the result is something wonderful, horrible, and awesome to behold!

Riiight.

Sparing the hyperbole: I got to the end of the rabbit hole, and can now use the Vizio gestures to control the music system.  I’m listening for the transport messages (as defined by the Cast API) coming from the Vizio devices and acting upon them.  These tend to map directly to the transport controls that would otherwise appear on the web player, but which are hidden when the player is running on Cast.  I’m also responding to Cast status requests that various clients send (including the Vizio devices).  And to top it all off, in the case where a Cast-capable client is actually connected to an existing Cast receiver session, I’m using the Cast messaging API to send transport messages to the receiver app directly – again, these map to the hidden transport controls on the receiver.  This happens in place of using my remote/renderer messaging solution.

Cool.  What else?

Is that an app in your pocket, or…?

Accessing the music system while out and abroad has taken on many, many, many different forms over the years.  Names that come to mind:

• GSPlayer
• XiaaLive
• Winamp

All of these things were eventually replaced by the web player powered by HTML5’s AUDIO tag.  And that’s great and all, but for mobile in particular I’ve wanted something more streamlined and purpose-built.  Plus it’s been an ongoing battle going up against things like “Gesture requirement for media playback” and Chrome’s tendency to kill timers on tabs that have been backgrounded for some time.

I’ve toyed with writing an app to resolve this but – newsflash – I didn’t write one, and I still haven’t written one.   What I have been angling for instead is to backdoor my web player into some container that would let it have all the rights of a native-app citizen, kind of like I backdoor’ed the web player into Cast as a receiver app.

And the good news is that there’s a lot of work underway to make first-class citizens out of web apps. Progressive Web Apps, Instant Apps, even the old “mobile-web-app-capable” meta tag that started it all.

So to that end I’ve finally gotten to a point where most pages are presentable/usable on mobile.  And, crucially, the web player will pin to the bottom of the page and stay there while you navigate the site.  And boy was that fun.  Remember, I’m not a design guy – so getting this thing to work in portrait/landscape wasn’t pretty (and the CSS/JS still isn’t pretty, but whatever).

Anyhow we’ll see what container this thing eventually ends up in (Cordova app?  Tasker app? PWA? Is “Add to Homescreen” enough?)  I’ll report back here once I know more 🙂

I mentioned in some other post that I’d post a picture of the UI I designed for display-capable Cast devices playing music from my music system. So here’s an example:

This is taken on my tablet set to impersonate a Cast device, so the UI is a little more cramped than it appears on a TV.

Pretty much sums up the experience though.

So it’s taken me the better part of two weeks to implement and many months of contemplation, but I finally have a fully-functional Google Cast implementation in the music portion of my home automation system.

Why two weeks?  Much of it was spent doing research.  Most of it was spent spinning my wheels before realizing that a lot of the pieces I’d need to complete the project were already in place.

I don’t recall how much detail I’ve gone into in this blog about the technical details of my web-based music system, so I’ll just summarize.  As far as playback is concerned there are two ways to actually listen to music on my network; either via a SHOUTcast server, or by accessing the music files directly over HTTP. SHOUTcast was the method of choice in the early years of development and eventually it became possible to add transport control functionality to control the SHOUTcast stream.  As a result the entire experience resembled a web-based player and the tunes were on-demand.  But it wasn’t really a web-based player, so the next phase of development was to implement a real web-based player that accessed the music files directly.  And as is the case with all modern web “apps”, that player uses HTML5, Javascript and CSS to work its magic.

So that’s the history.  When implementing Cast I followed much the same path; the first crack was to use the Default Media Receiver and have it stream from SHOUTcast.  This worked – surprisingly – but again the limitations of such a setup (mostly a result of buffering lag) proved onerous.  I deliberated, and researched, and deliberated some more, before deciding that the Cast device had to access the music files directly.  How?  Where to start?  And then it hit me.

IFRAMEs.

I don’t remember what came first; the Internet(tm) or my own “Aha!” moment.  The Internet(tm) said that it was possible to browse arbitrary websites on a Cast device by loading those sites into an IFRAME.  My “Aha!” moment came when I realized that my web player – the HTML5, Javascript and CSS player – used the very technologies that underpin Cast’s receiver “apps” and should therefore be able to run directly on a Cast device.

Put your web app in an IFRAME and by George you have it

Of course there was some “glue” to sort out.  Most important to a Cast implementation is that the receiver app stays resident, otherwise Bad Things(tm) happen.  Well, more like Undesirable Things(tm): the Cast device may go back to its default state, or at the very least your sender will lose connectivity to the (non-existent) receiver.  So I had to code a small receiver and get a little creative on the host side to make sure that the web app and receiver stayed in sync.

But mostly – it just kinda worked.  The web player runs in an IFRAME and the receiver app runs in “top”.  The web player – if left to its own devices – will just trundle through the server’s playlist until there are no more songs to play.  Or, with the correct settings, the player can be controlled from any other device accessing the music system.

How to control your Cast audio player

This is the interesting part.  Obviously you can’t interact with a web app running on a Cast device.  The Cast APIs have a robust messaging system that allows two-way communication between the sender app (which you can interact with) and the receiver app.  This is great, and I imagine it works well for transport control.  But I didn’t use it a great deal for two reasons:

1. I had already developed a way for a “remote” to control a “renderer” in my music system (see the last couple of paragraphs of this post).  That is, any device – the “remote” – can access the system and see a representation of another device’s web player – the “renderer”.  The remote queues commands on the web server which are subsequently picked up by the renderer, effectively making transport controls available to the remote.
2. While I appreciate Google’s concept of senders and receivers, my only desire is to have a device load the web player onto a Cast device and then have the Cast device communicate with the web server directly.  I don’t need the sender to maintain connectivity to the receiver.  This mirrors the existing status quo where any device – smartphone, tablet, PC – is just a client to the code running on the server.

I do use the messaging API to setup the receiver app and load the IFRAME.  But once the web app is loaded on the receiver, all messaging goes through my code running on the server.

So ya, add in some housecleaning and Bob’s my uncle.  I even designed a new web player interface specifically for display-capable Cast devices; something that looks a little more presentable on a TV.  The audio-only Cast devices just run the same player that any old smartphone/tablet/PC web browser gets.  I may reduce this to the bare essentials at some point but it’s really not necessary to do so.

I may post some pictures at a later date.  You know, if the adoring masses that frequent this blog demand as much.