All we are saying is give MADPs a chance

In 2010 and 2011, one of the most pressing questions facing mobile development projects is the question of whether or not you’re writing the app in native or HTML5. (Implicitly, these options always had an “excluded middle” option: the hybrid app that uses a combination of HTML5 and native features. In fact, I’d argue that there are very few pure HTML5 apps — that almost all HTML5 apps include some native functionality, say to access device features like the camera or GPS, even if that amount is small.) LinkedIn, for example, said of their HTML5 iPad app that it’s about 98% HTML5, but that’s still around 2% native. I’d hazard to guess that that’s a higher percentage than most HTML5 apps could report.

But in 2012, a real, third option has appeared increasingly viable: cross-platform mobile development tools that allow a developer to create an app in a (mostly) platform-neutral way and create executables for different mobile platforms. The industry (which, let’s face it, loves to give awkward acronyms to things) is currently referring to these things as Mobile Application Development Platforms (MADPs — I tend to pronounce that “mad peas”, but I think that’s idiosyncratic). I’m hoping that geeks of the world attach a better name to these products any day now.

Part of what intrigues me about this third option is that its popularity seems to be tied to some disillusionment with HTML5. Facebook recently (and famously) rewrote their mobile apps as native rather than HTML5 apps for reasons related to performance and ease-of-development. And that experience is becoming more common than the industry expected.

One of the key value propositions of HTML5 has been that you can write an app once for the different mobile platforms: iPhone, Android and Blackberry. (Okay‚Ķ and Windows Phone. But I’m including it under duress). Organizations that primarily need to support cross-platform development are increasingly looking to MADPs, rather than HTML5, to get the job done.

And it’s not that these MADP offerings didn’t exist before 2012. I recall sitting in Adobe presentations back in early 2011; Adobe was telling us about their AIR (Adobe Integrated Runtime) strategy for mobile. The promise is simple: you can build an app using their dev tools, writing code in ActionScript, and then push deployment buttons to get executables for iPhone, Android, or Blackberry. Before this year, though, the use of such tools seemed fairly rare. Perhaps because these tools tend to be pricey. Or perhaps organizations are waiting for some standards or market leaders to emerge in this space. Whatever the reason, our clients were talking to us about native versus HTML5; they weren’t talking about MADPs. But this year, that seems to have changed.

Earlier this year, for example, one of our financial services clients came to us having already decided for themselves that they were interested in IBM’s Worklight platform and wanted us to do a proof of concept on Worklight to put the tool through its paces.

Now, to some extent, Worklight is one of the most vanilla-flavoured MADPs. Primarily, its focus is facilitating cross-platform HTML5 app development (with common native call-outs typical of hybrid HTML5 apps — if you want to use the camera, for example, in your HTML5 app). Under the covers, Worklight makes big use of PhoneGap (now called Apache Cordova) in its client API component. But some of the things that it offers over and above the PhoneGap features include a rich development IDE (built as Eclipse plugins). Its integration with, for example, the iOS simulator seemed a bit indirect — you could push buttons to publish the Worklight project as an XCode project, and then build and run that in XCode itself, but there are a lot of button pushes in that process. Not a huge deal, to be sure, but it stands out compared to some of the other offerings in this space.

And I should stress that I don’t want to undersell the value of a tool like Worklight. My colleague, Rom, found it tremendously powerful for putting together an app that needed to be deployed to Android, iPhone and Blackberry. But my more general point is that some of these tools are becoming very sophisticated and in some surprising ways.

For example, I was recently experimenting with another MADP: Appcelerator Titanium. Like Worklight, Appcelerator’s development environment (“Titanium Studio”) is built on top of Eclipse — in particular, the download includes a customized version of Eclipse with its plug-ins included. One of its differences from Worklight is that Worklight is still mostly geared toward creating cross-platform HTML5/hybrid applications; when your screen needs to show a button, it’s probably an HTML component — possibly styled via jQuery Mobile or Sencha Touch frameworks, but still an HTML component.

The Appcelerator Titanium platform, in contrast, tries to get as close as it can to a native experience: to add a button to a screen, a developer would write JavaScript code that calls an Appcelerator JavaScript API class for creating buttons. Under the covers, the Appcelerator platform creates a native button and adds that to the screen.

Here’s a block of code for a sample Appcelerator app:

function HelloWorldView() {

  var self = Ti.UI.createView();

  //label using localization-ready strings from /i18n/en/strings.xml
  var label = Ti.UI.createLabel({
    color:'#000000',
    text:String.format(L('hello'),'World'),
    height:'auto',
    width:'auto'
  });
  self.add(label);

  //Add behavior for UI
  label.addEventListener('click', function(e) {
    alert(e.source.text);
  });
}

In this example, both the view and the label are created as native widgets. What’s more, Appcelerator hides the differences between the different platforms from the developer: when executed on Android, you get an Android button; when executed on iPhone, you get an iPhone button.

The precise mechanism that Appcelerator uses to execute that JavaScript at run time still eludes me, I must confess. This StackOverflow answer seems to suggest that the JavaScript is compiled into a more concise (but still interpreted) binary format. When I run the code in my local iPhone Simulator, I’m a bit less certain (because I still see the JS files bundled along with my app). But however it’s doing what it’s doing, it almost seems like magic.

It’s also true that the integration between Titanium Studio and, for example, my iPhone Simulator is very nice. With one button-click, I can get Appcelerator to compile, bundle and deploy my app, and run it in the simulator. It’s a tighter integration than Worklight offers (although to be fair our Worklight experience is a few months out of date — it may have improved in this area).

What makes Appcelerator even more attractive is that it’s an open source project, with a freely-available version of its development platform. It’s hard to beat that.

Another tool — sort of the Cadillac of MADPs — is KonyOne. Again, like Worklight and Appcelerator Titanium, its development IDE is based on the Eclipse platform. Like Appcelerator, it allows developers to write business logic using JavaScript, although that’s a recent addition; earlier versions favoured a language called Lua. Because, uh, there’s clearly a huge Lua developer base to make use of. (Okay, to be fair, there are Lua programmers in, for example, the video game space).

One of the big areas where KonyOne differs from Worklight and Appcelerator relates to its approach to creating screens and views. Kony provides fairly comprehensive GUI tools to lay out forms and screens. Developers can specify the size of components, colours, margins/padding and other attributes of screen components visually, using a typical property-driven paradigm. Presumably, internally, this information is stored in some proprietary internal format, but Kony claims to be able to use these UI definitions to generate either native or HTML versions of the UI. Similar types of GUI-driven developer UIs can be used to invoke remote services. KonyOne strikes me as exactly the type of product that Enterprises like to buy, and unsurprisingly, it seems priced for Enterprise consumption. But Kony still has a high buttons-per-dollar quotient, as they emphasize the kind of GUI-based development environment that Enterprises seem to love.

I think that each of these tools — Cordova (PhoneGap) alone, IBM Worklight, Appcelerator Titanium, and KonyOne — can be useful for different types of projects. It’s an unfortunate truth that there’s a huge amount of choice and a huge amount of change in the MADP space at the moment. It’s not a new space, but as I said, I feel like these products have started to become more mainstream in 2012. If you’re starting a new mobile project, you probably need to seriously consider using one of these tools.

It's only fair to share...
Share on FacebookGoogle+Tweet about this on TwitterShare on LinkedIn

Leave a Reply