The Tages-Anzeiger TV-Sélection iPad app has been available for download in the Apple app store for about a week now.
Huh?
TV Sélection is an app that lets you watch TV shows on your iPad. The focus is on shows in four different categories, hand-picked by the arts and entertainment editorial staff of Tages-Anzeiger, one of Switzerland's biggest newspapers. At the same time you can watch any other show on a wide range of channels by using the search functionality, with just a few minutes delay from the time it airs on TV.
NIWEA!
From a technical point of view, the app was implemented completely using Javascript, HTML5, and CSS, and wrapped as an iPad application using Phonegap. While we didn't take advantage of Phonegap's big selling point of being able to deploy the same code to multiple device types, being able to use HTML/JS/CSS played to our strengths. The other advantage though, was that we were able to develop and test large parts of the app directly in the browser, without having to constantly rebuild the code and run it on the device or a simulator. And that right there is the concept of NIWEA – writing code that can be re-used with no or very few changes across multiple platforms.
Where NIWEA breaks
When you're running on a device you want to take advantage of that devices native functionality. That may be the camera, accelerometer, or contacts. In our case we had three use-cases: We wanted to show notifications when not in the app, we wanted to use the devices keychain to store login details a bit more safely, and we wanted to take advantage of the fact that millions of users have their credit card information saved in their iTunes store account. We were able to do this by using phonegap plugins, one for local notifications, another to access the keychain and a third to handle In-App purchases.
And that's where the NIWEA concept cracks a little. Since these plugins rely on Objective C code to interact with the system, that functionality won't work on other devices. In some cases there may be plugins for your other device as well, and you can drop them in with little or no changes. In other cases you may have to write your own plugin, or just not offer all the features on every device. Since, again, we were only building for the iPad we weren't impacted much. We wrote a quick mock to simulate the keychain using cookies so we could continue testing in the browser. The missing local notifications hardly impacted us, and In-App purchases ended up being easiest to test on the device itself.
Look ma, no server!
While Phonegap was new to everyone on our team, it wasn't the only interesting thing from a technical point of view. One of the limitations of the whole project was that everything should run on the app – there is no backend, there are no servers.
OK, that's not entirely true – we access the tv shows and playlists through a (non-public, sorry) Zattoo API. We didn't control this ourselves though, and so anything that needed server-side code had to be planned and coordinated with Zattoo's developers. Since this obviously generates some overhead, every feature was examined to see how it could be done without requiring a backend. Want to send an email with debug information? Instead of sending it from a server, use a mailto link to open the iPads Mail app with some prefilled content. Want to use Push notifications to let the user know when his license expires? Sorry, push notifications require a server, but we can use local notifications instead, we just lose some flexibility because we have to trigger them when the subscription starts. In-App Purchases? There's a bunch of back-and-forth between Apple's servers and a callback URL to verify receipts and such – in this case Zattoo ended up extending their API to handle Apple subscriptions, with us simply passing on the receipt data we receive when the purchase is made.
More fun stuff
Other interesting details: We used WebSQL to cache the shows locally and allow you to save shows in your favorites. Probably because the WebSQL spec isn't being developed further there isn't a lot of documentation on what SQL operations you can actually use with it, so that was a bit of trial and error. Also, having database calls be asynchronous just seems like unnecessary complication.
We used the HTML5 video tag to display the video stream of the show. In general this works fine, but one thing to note is that if you use the default iOS media player instead of building your own controls, you lose the possibility to catch javascript events on the player area. For example, we were able to catch the touchmove event everywhere on the page to prevent you from being able to scroll/drag the page up and down, but we weren't able to prevent dragging on the player interface.
Finally, we used YUI3 as a javascript framework, where the main thing worth highlighting is the ScrollView module, which handles the vertically sliding list of shows. This worked well, but as the scrollable area grew, we did start seeing performance problems. To resolve this we decided not to display shows older than 30 days, which made scrolling much less jumpy! The other awesome feature of YUI3 which we used, and missed while using jQuery in another project, is the possibility to set dependencies when loading a module. The module will then wait to be initiated until all the required modules are loaded.
Let me at it!
Go ahead! The app is available for free in the App Store, and you'll receive a seven day trial in which you can watch any show. Unfortunately, you'll only be able to watch the shows if you're within in Switzerland due to licensing restrictions.