audio

In our last installment, I wondered why software developers collectively allow iPad web applications to stink. I think the reasons are mostly non-technical.

Last time, I tried and failed to use Google Drive to host some static content. Unsurprisingly, the culprit was a web page that worked poorly on the iPad. I eventually got Drive hosting static content by finding the 'Desktop' view. Even then, I had to click through a "The browser you're using may not support all the features of the desktop version of Google Drive" to get there. The Google Drive hosting hack is one step more complicated than sharing a folder. You also have to open your HTML page in Google Docs and press 'Preview' to get an URL. That step does not work on the iPad no matter the browser mode.

I hauled out a laptop and repeated the process. I got the URL. I opened it in the iPad. Success.

The app that I'd like to share with you is the HTML5 audio player I built this summer for a memorial service. The player is a straight client-side web app. It runs fine out of Google Drive. Here's the lin....

Oh. Never mind. I'll go to jail if I share the link with you. You're not allowed to have my music. I can't afford to license a hundred tracks of commercial music for a free web app. I can't replace ten playlists with a random collection of Creative Commons tracks and have a memorial that is representative of my friend's actual tastes and habits.

No problem. Ads for 'All Access' audio from Google Play, a streaming subscription service, are in heavy rotation on the blog now. They say it works on every device. You and I can both subscribe and I'll fish out the URLs for these playlists and put them into the web pag....

Oh. Google Play may work on a lot of devices and in the browser, but not in the browser on all those devices. I tried to open play.google.com on my iPad and I got nothing but an empty page and the message 'database error: Error: SecurityError: DOM Exception 18'. Too bad. It worked in Safari in 2011 when Sharon Vaknin wrote about it for CNET. It wouldn't have helped me then. Google didn't offer an all-you-can-eat service that would allow me to build a player for the music pooled in a subscription we share.

No problem. Google's just the latest entrant in the subscription music biz. One of the others will have done this properly. I'll try iTunes Rad... No I won't. That would never work. Who am I fooling? I'll try Spotify. Hmm. Spotify seems to use flash on my laptop. On the iPad browser, spotify.com offers only account maintenance functions. I'll try Rdio. Rdio redirects to the App Store in the iPad browser. No, thanks. If Google can't play me some subscriptions tunes with HTML5, then they can at least let me search for an HTML5 audio subscription app.

Hmm. forte.fm. That plays audio in the browser on the iPad. forte.fm is actually an HTML5 Rdio client built for the app-poor BlackBerry BB10 environment. It works on the iPad. It looks good! It almost works! It seems to play only track previews on iPad. I haven't had time to diagnose this strange behavior.

So Rdio works in iPad's Safari except when we get it from Rdio's official web site. I can deal with that. I'll just do the same trick in my web pag... Oh. forte.fm violates the Rdio API terms of service, which require that 'Your application will at all times display and promote the ability to subscribe to the Rdio Service, including, without limitation, making available and displaying promotions of Rdio’s subscription tiers, and without limiting the generality of the foregoing, will at all times make available ecommerce opportunities (including Rdio subscription tier offers and Rdio a-la-carte download offers) for free trial users and registered users listening to 30 second clips of music recordings.'

I don't want to clutter a web page with a bunch of Rdio branding. I'd be grateful to them for serving the streaming tunes but my premise is that this would work only because the end user of the web page was already paying Rdio for access to those tunes.

The branding issue is actually the smallest problem with using Rdio this way. The bigger problem is that their API requires a key. If I get an API key, I'd have to keep it secret from you. That's right. If I want to deliver a web page that presents you a selection of the music you already pay for, then I need to keep a secret from you to do it. I can't give you a client-only app and keep a secret from you. Rdio didn't invent this ridiculous model. They just didn't think hard enough before adopting it.

On to Grooveshark. Their HTML5 player works on the iPad. I'll just check their API developer term...
Oh. Same problems as Rdio. Never mind.

Most developers resort to some form of web hosting to square this secret circle. They spin up a lot of very complicated machinery to bring up a web server that runs PHP for no better purpose than to hide this API key from you. This is crazy and wasteful. Google actually show us the way here. AdSense works. AdSense uses an opaque identifier just like all these API keys. I get to share it with you.

I didn't really believe in the browser until I saw Google Maps. It wasn't just the best web page I had ever seen -- it was one of the best programs I had ever used. It delivered a smoother interface to the actual world than most games provide for their imaginary worlds. It didn't just embarrass many other mapping solutions, it embarrassed data visualization tools across domains. The easy, and easily available, API is a cherry on top. The simplest example from the developer site is really simple. You can try it yourself without credentials.

I keep believing in the browser. Surprisingly, Google Maps still embarrasses other data tools -- including much newer music offerings from Google themselves and from others.

Now we have two non-technical reasons that web apps lag: hosting and copyrighted assets. We'll visit more in the next installment.