Niall's Blog

Quick Introduction

Over the past month or so, I have been using JQuery Mobile to build a HTML5 mobile/tablet front-end for a strength training website I've developed. While I have built native Android and iOS applications before (in Java and Objective-C, respectively) the promise of a single codebase which would work on most major platforms, as well as the ability to iterate quickly in HTML and JavaScript, was very appealing.

JQuery Mobile & HTML5

To build a mobile app using HTML5 and JavaSript, you will need to write quite a bit of JavaScript. However, the UI controls and handling for a touch device are quite different from a standard web application. You will therefore want to take advantage of some kind of existing mobile HTML5/JavaScript framework (unless you have a lot of time and want to write everything from scratch yourself). There are a number of choices out there: jQTouch, Sencha Touch etc.

I have been a fan of JQuery for many years, enjoying its minimalist philosophy and the excellent core and community-contributed features and plugins. JQuery made JavaScript development tolerable to me. So, having heard good things about JQuery Mobile from Chris McDonough (Author of the Pyramid Python Web Framework), I figured I'd give it a try.

JQuery Mobile & HTML5: 3 Advantages

1. Easy to learn and Quick to Iterate:

   After reading the JQuery Mobile docs and also reading the JQuery Mobile book from O'Reilly, I was able to build a working, rough version of my app over a weekend. That is with no prior HTML5 / JQuery Mobile experience. Compared to Android and iOS, it is far faster to build out your UI and logic using JQuery Mobile and HTML5 than either platform natively.

   I found the learning curve for Apple's Interface Builder quite steep, and it also takes time to learn the quirks of the Android layout system. Furthermore, it is quite complicated to hook up a list view (ListView on Android, UITableView on iOS) to a remote datasource, and have it looking pretty, with native code. Using JQuery Mobile, I was able to leverage all my existing JavaScript and HTML/CSS knowledge to do this very quickly. I didn't have to learn a whole new abstraction with adapters, delegates etc. I just wrote JQuery code.

2. Avoid App Store Approval Madness & Debug Build Hell:

   One of the most painful things in developing for mobile, which by definition means being on iOS, is dealing with the Apple App Store approval process. In order to get a native app to your iOS users, you must go through a lengthy process (days, possibly weeks). Not only must you jump through this hoop on initial release, but for each upgrade, also. This adds greatly to the complexity of the QA and release cycle, in addition to simply adding time. Since JQuery Mobile apps are merely a special type of web app, they inherit all the wonderful qualities of that environment: As soon as the user reloads your site, they are "upgraded" to the latest version. Pushing bugfixes and new features is instantaneous. Even on Android - which with much less stringent Market requirements is the Wild West compared to the Apple environment - it is still nice to simply have the users upgraded without even being aware it is happening.

   An extension to this is how easy it is to distribute beta/test builds to users. Simply tell them to point their browser at a URL and they have it! No DRM madness for iOS nor even APK distribution with Android to think about.

3. Cross-platform & cross-device:

   The fact that my app worked immediately on both Android and iOS - along with many other platforms - is a massive advantage. As an individual developer, it is a huge effort to maintain a separate code base for each platform. Writing a quality mobile application for a single platform is a full-time job, having to re-do that for each platform takes a lot of resources. The fact that my app will work on both my Android and iOS devices equally well is a huge bonus.

   Furthermore, especially with the massive proliferation of Android devices in all shapes and sizes, making your app look presentable on a huge variety of screen resolutions is a real challenge. For serious Android developers, device fragmentation in terms of screen size (scaling from the downright tiny to quite large) actually represents a considerable development cost. With the browser rendering your application in a way that looks reasonable on every device, you don't have to worry about this to anywhere near the same extent.

JQuery Mobile & HTML5: 3 Disadvantages

1. Slower Than Native:

   The biggest drawback in my opinion is that even on the latest Android and iOS hardware (dual core Tegra 2 Android phone, dual core iPad2 tablet), JQuery Mobile applications feel noticeably slower than native. Especially on Android, where the browser is surprisingly (since Google is a web-focused company) far slower and buggier than on iOS. I haven't yet tested my app on older Android devices but it may be downright unusable there (e.g. G1 Android phone).

   I believe that in the next 12-24 months hardware will catch up sufficiently (e.g. quad-core devices coming in 2011) that this will be less of an issue. But today, it is a definite drawback. Also, if you are solely targetting iOS, you can count on the performance of the browser being at least reasonable (unlike Android, BlackBerry, etc).

2. Quirky:

   JQuery Mobile is still beta software, and as such I have encountered bugs. That being said, the team is extremely responsive in addressing issues on GitHub. I think one of the big problems is simply quirks across various browsers on different platforms. I am certain that this will be ironed out over time. The applications also can look quirky in a visual sense - while I think the JQuery Mobile team have done a great job with their widgets and themes, it is still fairly distinct from native. How much this really matters to users is not clear, but it is something to be aware of.

3. Limited Capabilities vs Native:

   Obviously, JavaScript running in a browser does not have full access to many features of the device. A common example being the camera. However, tools like PhoneGap help greatly with many common issues. Indeed, I have started working on deploying versions of my app for iOS and Android with PhoneGap - using native Facebook bindings - and am quite impressed. I will be writing about my experiences with PhoneGap and native bindings in future posts.

Conclusion

To sum it up, I believe that JQuery Mobile and HTML5 is a viable platform for mobile application development. However, it does not (yet) suit all classes of applications. For simple content display and data entry-type apps (as opposed to very rich multimedia/gaming applications) it can be a great force multiplier compared with native. I certainly am happy with how it has turned out for my app - I simply do not have the time to maintain a port of my strength tracker app for both Android and iOS.

Over the course of the next 1-2 years, as hardware gets faster and devices proliferate, I believe HTML5 (and JQuery Mobile, PhoneGap, etc) will be even more important technologies in the mobile app space.

Niall O'Higgins is an author and software developer. He wrote the O'Reilly book MongoDB and Python. He also develops Strider Open Source Continuous Deployment and offers full-stack consulting services at FrozenRidge.co.

Tweet

Video: An Obvious Killer App for Tablets

After a decade or so of various failed or underwhelming attempts, it is now blatantly obvious that Apple kicked off the consumer tablet revolution with their launch of iPad in 2010. By getting the hardware, pricing, UI and application ecosystem right, they have managed to sell 15 million units in 2010 alone (April - December), bringing in $9.5 billion.

An obvious killer app for this kind of device is video. At the distance you hold a tablet it has the same apparent size as a massive TV screen. The easy-to-hold and carry form factor, the long battery life, the high quality screen and speakers - and apps like Hulu Plus, Netflix, ABC and CBS pretty much have the TV and movie situation covered, with more services and apps coming all the time, to both iOS and Android devices.

In the not-too-distant future, practically everyone will have a tablet, and everyone will want to watch video on them. Awesome!

1) NVIDIA Tegra2 Chip Performance Surprises: Not What They Claim To Be

You've probably noticed the recent explosion in Android handsets and tablets powered by the NVIDIA Tegra 2 chip. It offers extremely impressive performance with a dual core ARM Cortex-A90 clocked at 1Ghz, and powers the latest devices including the Motorola Xoom, Atrix, Bionic and Samsung Galaxy Tab 10.1 along with a host of others just-released or near-release.

Tegra 2's Dirty Little Secret
What you may not be aware of amidst all the marketing is how poorly these Tegra 2 chips decode video. Tegra 2 is not capable of playing just any old video format. While technically it supports H.264 at 720p and 1080p, it specifically only supports the "Baseline" profile which means two reference frames and no B frames.

This means you must take your existing HD video files and re-encode them into a special format using a program like handbrake. According to Anandtech, that puts a 2 hour movie at around 8 GB - too big to fit as a single file on a typical microSD card formatted with FAT32.

Additionally, with those kinds of space requirements, streaming 1080p HD video for viewing on your device quickly becomes extremely bandwidth intensive (~10mbps). Almost certainly too high for most consumer Internet connections - according to DSL reports average Internet connection speed in USA is 4.7Mbps.

In other words, your brand spanking new, top-of-the-line 2011 dual core 1Ghz tablet cannot simply play any 720p/1080p HD video file you throw at it. Unlike a cheap PC or media center, in order to watch video on your shiny new Tegra 2-based tablet you:

• Almost certainly will have to re-encode your video specially for the device.
• Need a ton of storage space, approx. 8G per movie, possibly having the video split across multiple files.
• If streaming true HD video in 1080p baseline profile, need a very fast (~10mbps) Internet connection. (FWIW BBC iPlayer HD streams are 720p @ 3.2 MBPS. These HD streams are not available on iPad since that only supports baseline too!)

Ouch! Rumour suggests this is one of the reasons why HTPC (Home Theater PC) manufacturer Boxee ditched the Tegra 2 platform for the Intel Atom.

2) Samsung's Hummingbird CPU: DivX Certification

An interesting tidbit about Samsung's Android devices: Many of them - including 7" Galaxy Tab and the Galaxy S phone - are DivX certified! What does this mean? It means they can play pretty much any old HD video file (at least 720p high profile) you throw at them without the friction of painful, space-wasting conversion processes!

What about the soon-to-be-released Galaxy Tab 10.1? We don't know exactly, however all information so far suggests it will be powered by the same NVIDIA Tegra 2 chip. Unless Samsung does something custom, this device will have the same video limitations as the Motorola Xoom.

However, there is speculation that the other tablets Samsung is planning - in particular an 8.9" device - may use the next generation Samsung CPU named Exynos. This dual-core CPU could well have the same DivX certification as the Hummingbird devices, offering these devices superior video playback capabilities compared to Tegra 2.

This may mean that consumers interested in good video playback support should hold off on the otherwise very promising Galaxy Tab 10.1 and wait for an Exynos-powered device instead.

3) Tegra 2 Honeycomb Exclusivity: But Won't Last Long

Android 3.0 AKA Honeycomb is the first tablet-optimized version of the OS. If you want to be able to truly take advantage of the extra screen real estate afforded by the tablet form-factor, you will want a device with Honeycomb.

The first round of Android 3.0 tablets are all powered by Tegra 2. According to the SVP of Cellular Products at Qualcomm the reason for this is that Google partnered with Motorola on the initial launch devices. For whatever reason, Motorola chose Tegra. However, Honeycomb will soon be ported to and running on processors from other vendors.

As soon as Google open-sources Honeycomb, we should see a flood of Android 3.0 tablets from vendors like Acer, Asus, HTC, Samsung and others with much better video playback support - which means much better value for consumers!

Niall O'Higgins is an author and software developer. He wrote the O'Reilly book MongoDB and Python. He also develops Strider Open Source Continuous Deployment and offers full-stack consulting services at FrozenRidge.co.

Tweet

Since I got the N1 a few days ago, I'm quite interested in hacking for the Google Android platform. One of my favourite things about Android is that the SDK is freely available for Windows, Mac and Linux. In fact there is even an an effort to port to *BSD systems, although that still seems FreeBSD-specific and in the early stages.

Anyway, I decided to do my Android development under Ubuntu. While its pretty straight forward to get things set up, there are a few gotchas and little pieces missing from the Google docs to install the Android SDK on Ubuntu.

Download and unpack the SDK

First step is to download the SDK from the Android SDK page. I got the Linux/i386 version. Untar it to some convenient location. I just dropped it into my homedir. Then add /tools to your shell $PATH:

# assuming your shell is bash
$ echo 'export PATH=$PATH:~/android-sdk-linux_86/tools' \
     >> ~/.bashrc

Now you should have the SDK tools in your path to make using Android SDK easy! To verify, try running adb help and you should see a bunch of output.

Configure USB for your device

This is optional I suppose since you can use the emulator. However I really wanted to be able to debug on a physical device (my Nexus One). This is one area where the Google docs are lacking, at least for Ubuntu Karmic (9.10). You will want to refer to the Developing on a Device page, if only for the USB Vendor IDs table.

You need to create a file called /etc/udev/rules.d/51-android.rules on your system. Its contents should be (you might have to change vendor ID):

SUBSYSTEM=="usb", SYSFS{idVendor}=="0bb4", SYMLINK+="android_adb", MODE="0666"

Note that "0bb4" is the HTC Vendor ID. If you don't have a HTC phone (e.g. G1, N1) - then you'll need to look up your vendor ID at the page I linked above, or this copy of the table here:

Manufacturer	USB Vendor ID
Acer	0502
HTC	0bb4
Huawei	12d1
LG	1004
Motorola	22b8
Samsung	04e8
Sony Ericsson	0fce

You might need to reboot or restart udev (`sudo service udev restart') in order for this to take effect.

Enable USB debugging on your device

The next step is to enable USB debugging on your device so that it becomes available to the Android SDK USB system. Hit Settings -> Application Settings -> Development -> Enable USB Debugging to turn it on.

At this point you can plug in your device, and adb should pick it up:

$ adb devices
List of devices attached 
HT9CRP806806    device

Install Eclipse and ADT Plugin

You don't have to use the SDK with Eclipse, but I figured I'd give it a shot to check out the tools and to hold my hand a bit in terms of project creation. Again this is mostly documented by Google, but you can take a few shortcuts on Ubuntu Karmic:

$ sudo apt-get install eclipse

Now to get the ADT plugin, you have to follow the instructions from Google. I had to disable https for some reason to get it to install, and use a plain http URL instead.

Create an AVD

At first, it wasn't entirely clear to me that I had to actually go and create an

Get Platform SDKs
Click "Available Packages". Then click "Add Site" and enter https://dl-ssl.google.com/android/repository/repository.xml. This will populate your available packages list with a whole load of SDK platform versions and so on. Install whichever ones you want to be able to use. I just went with 2.1 for starters since thats the version I run on my phone. Presumably when you get around to compatibility testing for your app you will want to also install earlier versions. Correctly configured, it should look like this:

Create virtual device (target)
Now that you have a platform sdk available, you can create the AVD. Click "Virtual Devices" and then the "New" button. You should be presented with this dialog:

Its pretty clear what to fill out here. One thing to note is that if you want to be able to access the 'Net from within the emulator (as you almost certainly do) you need to add "GSM Modem support" to the AVD. Click "New" under the Hardware area to do this.

Running the Android SDK Emulator

Once again, start the AVD manager (by typing 'android'). Now you can select your AVD and click "start". It can take a little while for the emulator to boot:

There you have it! To get started with building a project and getting it running on the emulator, try playing with Eclipse. It makes it pretty easy to get started. I hope to write more about Android development as I learn!

Niall O'Higgins is an author and software developer. He wrote the O'Reilly book MongoDB and Python. He also develops Strider Open Source Continuous Deployment and offers full-stack consulting services at FrozenRidge.co.

Tweet

This week I bought the Google Nexus One phone. I've been very impressed with the device so far. Here are some of my thoughts. Keep in mind that this is a hacker's perspective and I'm not nearly so interested in eye candy and user experience as many people might be.

On the hardware

What impressed me most about the N1 was the hardware, and its hackbility. The highlights as I see them:

• 1 Ghz Snapdragon CPU - almost twice as fast as iPhone and Motorola Droid
• 512M RAM
• Very,very nice 480x800 OLED display
• 5MP camera + flash
• Easily removable battery (unlike e.g. iPhone)
• Micro SD card slot
• Hardware multi-touch support
• 3g modem - which can be used for tethering
• WiFi

Back in 2005 I presented a paper at EuroBSDCon on Porting OpenBSD to the Sharp Zaurus. I liked the Zaurus device, and I see the Nexus One as a much more evolved equivalent computer, with in-built 3g and wifi.

On the Android OS

I liked the concept of Android when it first came out but after seeing the G1, figured it needed some time to mature. My impression then was that it lacked polish and that the hardware available just didn't have enough power. Now, though, with the advent of the Nexus One, I think its awesome.

Highlights for me of the Android operating system:

• Open Source - You can download the source tree and compile your own ROM if you like
• Free Multi-Platform SDK - The iPhone is a nice piece of hardware, but I don't own a Mac (and don't want one) so could never develop for the platform. The Android SDK, on the other hand, is freely available for Windows, Mac and Linux - so I can actually use it!
• Multitasking - I didn't actually realise that iPhoneOS didn't support multitasking until recently but that seems like a huge disadvantage.
• Activity micro-app model

Android Activity Model

Many people don't seem to like this, but I'm quite impressed so far. Applications on Android are really a collection of micro-applications called "Activities" which are executed in a stack, and are expected to be able to handle being garbage collected by the OS and resumed later. This provides two very interesting things:

• You have the illusion of running as many applications at once as you like. If the application isn't actually in memory when you try to access it, it will be resumed and its state re-initialised to what it was previously.
• It provides a very interesting mechanism for code-reuse and use of third-party functionality.

For example, lets say your application on Android needs to prompt the user to select a point on a map. Instead of having to call some Google maps library or similar in-process, you actually execute the Google maps activity (which is a separate process) and it sends you back information.

While this isn't conceptually so far removed from linking library code into your process memory space and calling functions that way, it removes an awful lot of complexity - no need for shared library linkage for one - and improves security and robustness of your application. Should the thirdparty activity crash, because it is in a separate process, it shouldn't take your app down with it.

My favourite use of this model so far is Snaptic's 3Banana Notes, which provides a note taking activity to other applications. This allows third party applications to save any note-like state to your Snaptic account, and get syncing etc for free. Pretty cool idea.

Conclusion

I am super happy with the Nexus One and Android so far. I was able to hack together a simple stopwatch application for the platform in about 90 minutes - and that includes installing Eclipse and getting it set up. I'll write some blog posts on developing for the phone soon. However, its not without its flaws. Its pricey, at $580 unlocked. Android could do with less frivolous eye candy and more focus on responsiveness in my opinion. The virtual keyboard doesn't seem as good as on the iPhone. Also I'd love to get more battery life out of the device - but it seems like all these smartphones are power hogs.

Niall O'Higgins is an author and software developer. He wrote the O'Reilly book MongoDB and Python. He also develops Strider Open Source Continuous Deployment and offers full-stack consulting services at FrozenRidge.co.

Tweet