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 🙂