Mobile development frameworks

Why should you use a framework?

I recently started investigating the ways I could develop a mobile application (especially Android), which is the right and/or fastest way and how could I improve my overall thinking when it comes to mobile development. The only method I used ’till now is the native one. I relied on Android application framework and I liked to take care of all the little details, even if those details slowed the development process a little bit. I’m talking about details like custom layouts on multiple screen densities. Not necessarily a hard thing to do, but still time consuming. Sometimes even working with system services seem hard to debug or test properly. I wanted a tool that could help me with those little details and let me concentrate on application logic, rather than the sub-components.

But after discussing with other developers, I discovered PhoneGap, an application framework, which allows developers to write native, mobile applications using HTML5 and JavaScript. And it isn’t the only one. I found out that there are a lot of other frameworks like this one, which provide high level APIs  for the most common mobile components and even more, can open the mobile development world to a web developer. You can find a list of the most used frameworks here. But wait, there’s more. Most of these frameworks are multi-platform, which basically means that you can cut the development costs in half, by coding once and deploying that code on Android, IOS, WP7 and other platforms. This seems to be great, but portability has it’s own costs.

How does it work ?

What PhoneGap actualy does is create a web container inside a native application in which you can run your own JavaScript code, using HTML5 for the user interface and taking advantage of the main system features through a JavaScript API. You can do almost anything that you can do in a browser, including AJAX calls in order to exchange data. Here are some samples of some quick cool stuff:

Taking a picture:, onFail, { quality: 50,
    destinationType: Camera.DestinationType.DATA_URL
function onSuccess(imageData) {
    var image = document.getElementById('myImage');
    image.src = "data:image/jpeg;base64," + imageData;
function onFail(message) {
    alert('Failed because: ' + message);



navigator.geolocation.getCurrentPosition(onSuccess, onError);
// onSuccess Callback
//   This method accepts a `Position` object, which contains
//   the current GPS coordinates
var onSuccess = function(position) {
    alert('Latitude: '          + position.coords.latitude          + '\n' +
          'Longitude: '         + position.coords.longitude         + '\n' +
          'Altitude: '          + position.coords.altitude          + '\n' +
          'Accuracy: '          + position.coords.accuracy          + '\n' +
          'Altitude Accuracy: ' + position.coords.altitudeAccuracy  + '\n' +
          'Heading: '           + position.coords.heading           + '\n' +
          'Speed: '             + position.coords.speed             + '\n' +
          'Timestamp: '         + new Date(position.timestamp)      + '\n');
// onError Callback receives a PositionError object
function onError(error) {
    alert('code: '    + error.code    + '\n' +
          'message: ' + error.message + '\n');



// Vibrate for 2.5 seconds
// Beep twice!
    'You are the winner!',  // message
    alertDismissed,         // callback
    'Game Over',            // title
    'Done'                  // buttonName
//Alert callback
function alertDismissed() {
    // do something


Of course you can make use of those other common features like file system, contacts and so on, but what bothers me is that the application will look and feel like a web application. I mean, it’s basically just a mobile browser and, from the user-interface point of view, you are limited to it. This might not be a problem for some users or clients, but others expect to see the native UI, the native theme, transitions and accessibility. Here are some screenshots of some cool apps made with PhoneGap.

A dashboard Buttons and forms A journal (basically, a list) A list of options


As you can see, there is a lot of flexibility in terms of design, and you can reach a very large scale of devices and platforms, after all it’s just HTML, CSS and Javascript, therefore you have to accept that you can never mimic the native look and feel using this type of approach, but still you can use a touch-optimization framework like jQueryMobile (or Sencha’s Touch visual features) in order to create a “mobile” feel. It looks good, but the web-browser  is still felt.


Titanium Mobile still uses JavaScript as a main application language but it also fixes this UI issue by rendering native user interface components at runtime, using the native  javascript interpreters from each platform. And yes, you would still have the cross-platform advantage (although Titanium’s approach is “write onceadapt everywhere“). It looks wonderful and the UI is so consistent and responsive. One issue that bothers me is that you don’t have access to declarative layout, meaning that each component has to be manually initialized… Even so, the fact that it reaches a large scale of devices makes it very suitable for companies that need to reach many users. Let’s see how some visual components are initialized in Titanium:

A simple button:

var button = Titanium.UI.createButton({
   title: 'Hello',
   top: 10,
   width: 100,
   height: 50
{"You clicked the button");


A slider:

var slider = Titanium.UI.createSlider({
    top: 50,
    min: 0,
    max: 100,
    width: '100%',
    value: 50
var label = Ti.UI.createLabel({
    text: slider.value,
    width: '100%',
    height: 'auto',
    top: 30,
    left: 0,
slider.addEventListener('change', function(e) {
    label.text = String.format("%3.1f", e.value);

Titanium UI on iPhone and Android
As you can see, Titanium’s APIs are straight-forward and easy to learn. You may notice that there is a naming convention that all the methods that return new UI elements start with the word “create”, thus being more verbose. Each UI component has it’s own implementation on each platform, so if you create, let’s say, a button, it will always be native on Android, IOS, WP and on the other platforms supported. Just take a look on the following screenshot, notice that it represents the same application on Android and IOS.

So, which one ?

It all depends on the project. I would use PhoneGap for an improved version of a website, if the company or the product already has a website. This would be much efficient, because you already have the data model which you can use through AJAX calls. Being able to access some device functionality like local storage or geolocation might enhance a website’s experience on the mobile world. An example of a good PhoneGap application would be, in my opinion, Facebook for Android. If I were to learn something from it is keep that web feel on the mobile and do not try to mimic the mobile UI using HTML, you might realize that you have started on the wrong foot. But, again, it all depends on the goal. If your goal is, let’s say, to sell computer parts, maybe it’s better just to create a mobile version of your website, having in mind that a user is familiar with browsing a website on the mobile device.

I guess it all comes to pleasing the user. That’s why, in some cases, the native look and feel is a must. And it’s not just all about the looks. It may look good, but it’s more than that. A native UI has many things besides looks. It has accessibility, it is fast, it is power efficient and, above all, it’s the UI the user has grown familiar with. We should consider other aspects, too, like package size. Of course you can expect the smallest size from a native application (up to 100 Kb, without any assets). Using PhoneGap you can expect an application size of a few hundred kilos, but with Titanium, the basic HelloWorld application can be 10 times larger, reaching 3-4 Mb. It is true that package size grows proportionaly with the number of the devices supported (different screen densities), but the framework adds its payload nevertheless. If size is a concern, you might not want to use Titanium.

Finally, you can use any application framework, as long as you do not want (or need) to create games or interact directly with low level features like services, graphics etc. And Titanium and PhoneGap aren’t the only ones. Here is an extensive list. One thing that still needs to be mentioned is that most of these frameworks are extensible through plug-ins, so if you need some custom, exotic functionality, you can implement a plugin yourself.

by Vlad Stefanescu

Leave a Reply

Your email address will not be published. Required fields are marked *