This is the final post in a series looking at developing for the other tablets coming to market in 2011. So far I’ve looked at the PlayBook and Android devices, and we’re wrapping things off with HP’s recently announced TouchPad.

What is it?

In terms of hardware, the TouchPad is more like an iPad than anything else coming to market, with a 1024×768 9.7 inch display, although it’s more powerful than the iPad 1, with 1GB of ram and a 1.2GHz dual core processor. What makes this a bit more interesting is that it’s running the highly acclaimed webOS, which shows up iOS in some areas like notifications and multitasking.

Unfortunately I’m still waiting to be added on to HP|Palm’s early access program so I haven’t actually been able to look into the tablet specific tools. Rather than wait endlessly, I’ve taken a good look at the current tools as well as researching into what’s to come.

Technologies

webOS itself is a propriety Linux based OS that uses WebKit for all of it’s interface. This means that all of the apps are written using web technologies – namely HTML, CSS and JavaScript. At first this sounds like it’s going to be extremely limiting, but the more you listen to the thinking behind it all, the more it kind of makes sense. And it’s actually not too bad to develop for, although JavaScript is a long way from being my favourite language. The current framework provided to you for app creation is called Mojo, which will be supported as far as possible in the future, but it’s about to be superseded by a completely new one called Enyo. So maybe if you’re thinking of learning this side of things it would be best to hold off a little while and jump straight to Enyo.

Now web technologies clearly aren’t going to cut it when you need high performance, so you can use the PDK to create plugins that run natively. The PDK can also be used for making games using OpenGL and C++. There are several stories of respected indie game devs like Mike Kasprzak and Phil Hassey porting their games to webOS in a matter of a few days. It sounds like it’s easily done if you wrote portable code.

Tools

Again, there are many options here. If you want to use an interface designer and code in your web browser, you can use something called Ares. Ares is certainly innovative, but in my experience it wasn’t really that usable. Eclipse is pretty much the official desktop SDK, but there seem to be a lot of people using lots of different tools. I used Espresso, as I’m used to using it for web dev (although I don’t rate it very highly) and found a plug-in for it. Emulation is done using VirtualBox and Palm has done a lot of work to make things nice and simple for developers. Debugging is done in the terminal and works well, giving good descriptive errors when things go wrong. I did find myself longing for compile time errors though, but maybe with a better IDE I would have had fewer issues.

Documentation and Resources

The documentation for webOS is really good, and there are tons of ways to learn. I watched the Stanford lecture series on iTunes U, which was very helpful indeed. There are also Palm podcasts, forums and an active IRC channel to help you out. The SDK gives you all of the source code for the apps that ship with the devices, like email, messaging, the browser etc. which I found myself using a lot to work out best practices and what type of element I needed to put where.

Costs

There’s no sign-up charge, and no charge to submit an app. What’s more, if you ask nicely, HP will send you a test device for free. I’m told my Pre 2 (worth a fair few hundred quid!) is on it’s way – thanks HP!

Review

4 star – HP|Palm really are proving that people other than Apple can make a decent operating system with decent development tools. In some ways things aren’t as nice as developing for iOS, such as the tools and the languages used, and in some ways they’re even better, like the free devices and more human support. I would definitely recommend that you consider developing for webOS, and if you’ve created a game for the iPhone using portable code, then porting should be very straight forward. I, however, used Objective-C and cocos2d for Flying Cats, and after a couple of days wondering if I could use Cocotron to compile the Foundation libraries for Linux with an ARM processor, I gave up! Maybe that’s possible, but probably not worth it.

Of course, if you’re so inclined maybe you could make a game using entirely web technologies. I can see this being a good option for people without much programming experience, who are a bit daunted by cocos2d and Obj-C memory management. You could quite happily make a game that makes use of all the cool stuff in WebKit, then ship it for webOS, iOS and others.

Final thoughts

I’m glad that I finally found another mobile operating system where the development tools didn’t completely suck. Having said that, is cross platform development really the way forward for tablet apps? One thing I’ve only briefly touched on is market share. Currently, the PlayBook, all of the Android Honeycomb tablets and the TouchPad have a combined 0% of the tablet market share, because they’re not out yet. Apple created a new class of device with the iPad, and what’s more is they seems to have done it cheaper than other companies are managing to a year later. Everyone else is playing catch-up, and I can’t see anything that will make any of these new devices really stand out against the iPad. The trend that we’re already starting to see is that the term “iPad” is becoming synonymous with “tablet”, much like “iPod” is synonymous with “mp3 player”. The iPad is still untouchable, and Apple are about to up their game again.

I probably sound like a bit of an Apple fan-boy, and truth be told, I am. I love OS X, I love iOS, I love the apps and the innovation we see, I love the development tools, and I’m probably on my own with this one but I love coding in Obj-C! There’s simply no compelling enough reason for me to want to do develop for anything else right now. So will I be developing across multiple platforms in near future? Sure I will: for iPhone, iPad and OS X.

I kicked off this series last week looking at developing for other tablets, with RIM’s PlayBook getting us off to an abysmal start. I did promise webOS this week, but as they’re tablet SDK is so new, it’s not instantly available to everyone. I’m in the process of applying for access, so hopefully I’ll be able to report next week. So we’re going to have dessert first with Android and Honeycomb.

Android Tablets

There have been a few tablet devices that have come to market already that run the same version of Android that you find on phones. These have generally been smaller screen devices, such as the 7 inch Samsung Galaxy Tab. What we’re about to see, though, is the new generation of Android tablets running Android 3.0 – a.k.a. Honeycomb – which has been specifically built for tablets. Perhaps the most notable of these, and the most imminent, is the Motorola Xoom. The Xoom boasts a 1280×800 widescreen display, a 1 GHz dual core processor, and 1 GB of RAM. The other forthcoming Honeycomb tablets look to be similarly specced, which may ease the pain of developing for multiple devices, at least in the short term.

The Tools and Docs

In general, it would seem that Google have some very good documentation, and so far there hasn’t been any part of the process of getting set up for development that I’ve been stuck on. However, installing the tools you need is very clunky and slow. The process involves downloading a Java app that connects to the Google servers and gives you list of options for what you can install. I just went for all the defaults and things seem to work OK. You’ll also need to download Eclipse, and install the Android plug-in. Although Eclipse isn’t your only option for an IDE, it seems that most people are using it. There’s plenty of sample projects bundled in to browse through, although I found errors and warnings in the code I loaded.

So far things have been OK, but far from perfect. It seems to me that Google are happy that things are good enough. The experience for developers may not be as polished as it is in Apple’s camp, but it’s passable. With one exception, that means I haven’t been able to do any Android tablet development at all.

The Emulator

When I’m developing for iOS, I use the simulator 90% of the time, and only check on the device occasionally. Being able to quickly deploy to the simulator rapidly speeds up development – perhaps other people work differently, but I’ve found that doing all I can in the simulator is a good strategy for being as productive as possible. Of course, when you’re dealing with devices that haven’t shipped yet, the simulator is your only option. And the Android emulator is woeful. Here it is:

You probably all think I’m dumb for not noticing that it’s rotated wrong, but actually there’s a bug that means that that’s the orientation the emulator is stuck on. But your main problem is that it’s unusably slow. The interface runs at something like 1 frame per second with memory warnings all over the place. There is literally no way you could develop an app using this thing. According to Google:

“Because the Android emulator must simulate the ARM instruction set architecture on your computer, emulator performance is slow. We’re working hard to resolve the performance issues and it will improve in future releases”

Now I’m no architecture genius, but it strikes me that this is a lame excuse. Apple, HP and even RIM have managed to work out how to get a fast performing emulation of their platform on a computer, by compiling it for the native architecture (I think…). What’s stopping Google doing the same? There are signs that emulator performance has been an issue for previous generations of the OS too, so I don’t hold out a lot of hope that it will improve that much.

I’m sure there must be some big technical issues, and I hope it does get better in time. Of course the other option is to hedge your bets and shell out for a tablet, hoping that it pays off, and that nothing else hinders your progress. And in fairness, you should really be testing on a device anyway.

The real issue in my mind, though, is not the emulator. It’s the fact that Google thought it was good enough to ship it as it is and waste everyone’s time who tries to develop for it. I get this constant feeling that third party developers in the Android world are thought of as second rate citizens, and their general approach is “that’ll do – it’s only for the devs”. That’s not an environment I want to work under.

Review

1 star – has potential but really needs an update! Even then, when factoring in the stories you hear from people already developing for Android, as well as platform fragmentation, and distribution and monetization issues, there are just too many things making me nervous. Android has been a very popular choice in the mobile phone market, but looking at the OS and the cost of the devices so far, I see no reason why that should continue in the tablet market. I guess time will tell, but I have absolutely no immediate plans to be developing for Honeycomb, and I’d advise anyone looking into it to at least wait a few months to see how things pan out.

It was over a year ago that Steve Jobs unveiled the iPad. Criticised by many as being “pointless” and “just a big iPod Touch”, it went on to sell nearly 15 million units in the first nine months. That success has heralded the dawn of the post-PC era, and now other manufacturers are finally starting to catch up and produce their own tablets – CES 2011 saw well over 100 such devices on show. The question for iOS developers is should we be branching out onto these other platforms? Over the next three weeks I’m going to take a look at the major new tablet platforms – Android 3.0, webOS, and BlackBerry Tablet OS – and take their development tools for a test drive, looking at what’s possible. And for each platform I’m going to finish with an App Store style review. First up is the BlackBerry PlayBook.

What is it?

The PlayBook is an upcoming tablet from BlackBerry. It’s got a seven inch widescreen display (1024 x 600), a 1GHz dual core processor and 1GB of RAM, which is all pretty impressive, especially when you think about how behind the times BlackBerry’s current phone hardware is. As is their phone software, which is why they very smartly bought out QNX and adapted their operating system for the PlayBook. An interesting feature of the device is the touch sensitive bezels, which mostly do app switching, but the top one is accessible to third party developers. It’ll be out in Q1 this year apparently – I’m guessing it’ll be late March if it ships on time. What’s great is the RIM want to give you a free PlayBook, just for making an app for the device! Awesome – let’s get cracking!

Restrictions

Right now there are two ways you can develop for the PlayBook – using the Adobe AIR SDK or using standard web technologies and the WebWorks toolkit. That is all. So you won’t be porting any 3D games in a hurry, unless you become one of RIM’s selected partners i.e. someone the size of EA.

Choices

So given your choice of the two frameworks, which one do you go for? It’s up to you, but personally I’m really not a fan of Flash. I’m the sort of person that has uninstalled it from their primary browser. I like AIR even less – it’s a surefire way to bring an ugly, clunky user experience to your customers. While it’s tightly integrated into Tablet OS, and BlackBerry’s own apps are written using it, it’s not the path I wanted to take. In my mind, there’s no point gaining skills in a technology that I hope is dying, and I didn’t become an independent developer to do something I hate doing. So I chose the open web standards route and the WebWorks toolkit, which effectively lets you package web apps as native apps on the device. The rest of this post talks from the perspective of using WebWorks.

The Tools

When you sign up as a developer, be prepared to enter all of your details into a lot of forms, even when you’re downloading software as a logged in developer. The documentation is OK, but pretty Windows centric and lacking in some crucial areas. There’s no specific IDE, so you’re free to use whatever web development tools you like. There’s also no stand alone simulator, so you have to use VMWare Fusion to run the simulator. I tried using Virtualbox, but unfortunately it didn’t work. The compile and run is done through terminal commands, which gets pretty clunky pretty quickly. I got to the stage where I had to run and wait for 5 different commands to deploy changes – uninstall the app, remove .DS_Store files, zip the files, compile the archive and install the app. The whole thing is an order of magnitude slower than deploying to the iOS simulator, but in theory you wouldn’t have to test things out on the simulator too much. After all, we’re effectively making glorified websites so we should just be able to test most changes in a Webkit browser and it’ll look the same, won’t it?

Wrong!

My first thought was that as I’m making an app and not a website, I should use a framework. I went for Cappucino as I liked the look of it and knew that people had created stuff for iPhone with it, so it was mobile friendly. However, the WebWorks compiler is very restrictive on file names, which caused issues. Once I got round those, however, it still didn’t work. It was at this point that I started to wonder how I would debug the app. So far all I’ve done is compile and install it to the simulator. Here’s the fun part – you can’t! The official word from RIM:

“There is currently only the command line packager, without any debugging / profiling capabilities.”

It gets better. As we’re making super-apps (I think that’s what RIM calls them), and we have access to WebKit, we can use lots of HTML5 goodies like audio and video tags, and CSS3 fonts. In the simulator at least, none of those work. Flash videos don’t even work in the simulator. There’s also no way to do any form of multitouch gestures in the simulator, and you can’t rotate the device. I guess it’s possible that it all works fine on the device, but it’s one hell of a gamble to ship something you’ve never seen work. I think you might be able to get a HTML 4 and CSS 2 compliant app to work, if you used minimal Javascript and no external frameworks. Basically make a simple website and call it an app, but that’s not for me.

Costs

All the development tools that RIM provide you with are free, and it’s currently free to sign up to the developer program, but you’ll need to buy a copy of VMWare Fusion for $50. If you’ve an individual like me, RIM require that a certified Notary verifies who you are before you can become a vendor. My lawyer friend informs me that the other option, which is to become a registered company, would almost certainly be cheaper, in this country at least.

Review

1-star, should be free! Oh, it is free? Then you should give me a free PlayBook for having to put up with such awful development tools. Oh you do? I’m still not convinced it’s worth it. While all these tools are still in beta, they are so bad that I don’t think they should have seen the light of day. If RIM are treating developers like this now, who’s to say things will get any better? And here we have a ‘vicious for RIM’ / ‘virtuous for us’ cycle, where the tools are bad so developers aren’t attracted to the platform, so apps don’t get developed for it and so the platform fails. I think we’ll see some Flash games get ported, and some BlackBerry fan-boys buy the devices themselves, but unless there is some radical change I can’t see the PlayBook being a major player in the tablet market. Which will be good news for developers, as they’ll have no reason to go anywhere near RIM’s poorly designed SDK.

Next week … webOS!

Update[0]: I contacted RIM regarding the whole notarised deal. Here’s what they said:
Me: As an independent developer I can afford neither to become incorporated, nor to get a notary signature. Could you explain the reasoning behind this?
RIM: We require our vendors to be 18 years of age or older. This is why we require a notary form.
Me: Is there not a way of proving that I’m over 18 other than spending £200 on a lawyer? I could send you a copy of my drivers license?
RIM: We do not except photocopies unless they are notarized. You can try a local bank or family doctor to see if they will notarize your documentation.
Me: OK, but what you ask for is a certified notary i.e. someone legally authorised as a notary (http://en.wikipedia.org/wiki/Notary). Are you saying that this is not actually the case?
RIM: Correct, we would prefer a certified notary but sometimes it is difficult for people to find them so we make exceptions.

Update[1]: Seems this has become a hot topic recently. Jamie Murai details similar experiences, to which Matt Rix responds.