Within the comments of my Chromecast post last week, there were quite a few people defending the product saying, "For $35, it does what it is advertised to do."
That observation also applies to your Android phone: For $600, your Android does what it is advertised to do. It makes calls, plays music, gets on the internet, ships with an outdated version of Android (which never sees updates), and provides a tired user experience.
Yet, over the Android phone, those same commenters will start change.org petitions, participate in tweet campaigns, and create a general rabble in the hopes of influencing the not-Google-manufacturer to unlock the phone and make it as open as possible.
Sure, the Chromecast does what it is advertised to do. But that's not interesting to me. I'm interested in seeing what the Chromecast can do, that wasn't advertised.
I've been having a lot of fun hacking on my Chromecast. The first (sorely) missing feature, sending videos and pictures from your device to Chromecast:
This got a lot of coverage on various social networks and blogs. One of the viewers directed me towards a funny statement that @gruber had posted on Daring Fireball:
That’s what I assumed yesterday as well, but I’m pretty sure now that’s not the case. Chromecast only streams video from the web; it has nothing like AirPlay. You can’t send video from your phone to Chromecast.
Well, that's odd. Certainly, he realizes that Chromecast is a platform, and not an appliance... right? It's not limited to what the platform can do out of the box.
I guess not. Gruber seemed stuck on whether device streaming is built in. As if it would not be possible if it weren't built in. As if the Chromecast was not in fact a full fledged mobile computer; and instead an unextendible appliance. A toaster. An Apple TV.
I took a quick poll of my followers on what they'd like to see next. Most of the request seemed to be around either streaming from a local media server or cloud storage; two hours of hacking later:
Chromecast is a platform. It doesn't matter what comes built into it. What matters is what developers can build on it.
Rewriting await on top of yield has proven to be extremely easy. Roughly 130 lines of code over the course of a couple hours. Whereas, the original implementation I did over a year ago took 1600 lines of code over the course of several weeks.
The "await" keyword works with legacy synchronous functions that take a final callback argument:
And the "await*" keyword works with new generator functions:
The code is up on my fork on Github for anyone to grab. Enjoy!