Note: Titanium and PhoneGap are a couple of platforms for developing hybrid applications for mobile. These platforms are not written in the programming language that is native to the phone, but they can be distributed on a verity of mobile platforms.

Recently I’ve published on Github the newest and most extraordinary quizzing platform, named Just-Quizzing. I’ve build it for personal use, but because a few colleagues found it useful, I made it public.

In the initial version, for publishing the application to my Android phone, I used SL4A. I needed a way to use the application when I was on the move and didn’t have Internet access. Unfortunately it didn’t have automatic update for the quizzes. I’ve hoped that with time SL4A will have a clearer path, but the platform lost its initial momentum and I decided to write a mobile app.

I had to choose between PhoneGap and Titanium. In the past I’ve used PhoneGap because the app size was too big in Titanium, but I wanted to give it another go. In 2011, when I first wrote about Titanium, the initial app size was about 4M. Today it doesn’t seem that big, even though it isn’t small.

The perspective will be mostly about Android, even though the app was built to work also on iPhone.

I used SDK 3.1.3, without the Alloy framework.

Alloy has it’s own learning curb and I wanted to avoid it. The prupose of the application was to be a portable version for the quizzes from the server and I didn’t want to make a big time investment.

The total development time was a little more than a week.

First impression

Things don’t work as you expect them to, there isn’t a lot of flexibility. From the total allocated time, more then a quarter I was trying to do a “flyout menu”, like in applications such as: Facebook, Google Plus and Youtube. It was a total disaster! The only options that seemed to work were using an external module or using Alloy widgets.

It seems like when converting relative coordinates, where the user touched the current element, to the general coordinates on the screen there is a big discrepancy and it is impossible to do a sliding menu effect in a decent manner. In the end I totally abandoned this effect.

The speed is not that good when it comes to rendering elements. To be honest, I was expecting a better speed. There are some tricks that help, like pre-rendering the views before displaying them, but for this you must guess what the user will do next, which is not always possible.

Another thing that bothered me was that when the menu button is pressed on Android you can’t take a particular action, let’s say open the side menu that I’ve mentioned before. In PhoneGap for instance, no menu is opened, it must be built-using HTML from the ground up.

When Titanium came out, they were stating that you could develop once and distribute to multiple platforms. Now I was surprised to find that the approach had changed. In the Kitchen Sink, the application that showcases the features of the platform, each platform type initializes the application in it’s own file. One of the reasons is that the design is done dynamically if you are not using Alloy, not trough layout files.

One of the first things that I tried with Titanium was to see the size of a “Hello World” app. Packed, the application has about 8.5M, installed on the phone, it takes up about 16M. I don’t know what you think about that, but for me it is a lot! What is strange is that my final app occupies about 8.4M packed and installed about 16M, almost identical to the original application. The reason is simple, the images replaced by me are a few kb smaller, resulting in an application a little smaller than the one that I started with.

Why does a Titanium application take up so much space?

I had to do some searching before finding the answer. In 2011, when I first tried to research, I only found that all the libraries, needed or not, are packed inside and for this reason it takes up so much space. This wasn’t the cause! Meanwhile, I found the real reason. An application runs a “bridge” between Android and JavaScript. The source code is not “compiled”, as was the initial belief, but just interpreted.

The JavaScript code is interpreted using one of the available engines in the app (V8 and Rhino) and it calls other components that build the native graphing elements.

The issue is with the engines. They are quite big and are packed in every application. And, as if they weren’t large enough, there are 3 of them, each with its’ own purpose:

• V8 – for newer Android version (after Gingerbread 2.3);
• Rhino – for older Android versions (before Gingerbread 2.3);
• x86 – for Intel processors.

These 3 engines occupy a total of 19M, unpacked on my computer. Thus, without eliminating some of them, we can’t get the app size to decrease.

One way Appcelerator is trying to tackle this size issue is to give up Rhino, breaking this way compatibility with older Android versions.

Community

There is a very active community. On the forums and Q/A platforms it’s full of questions and answers! I must admit that I was impressed in this aspect. Some questions are relatively old, even from 3 years ago.

Learning curb

For a week and almost a half, out of which almost a quarter I searched how to do a view moving effect, which in the end didn’t work, I must say it went pretty fast!

I must admit, I’ve played with it 3-4 years ago for a few days and I remembered a few things, like elements of type window, view and label.

The fact that I was able to find answers fast on questions about Stackoverflow, gathered in a few years, but also that the documentation is pretty well organized, helped a lot.

Also on Youtube there are some useful tutorials.

Development environment

In the first versions there wasn’t an IDE, the applications were written with an editor of choice, then packaged and tested using the platform.

Now there is an IDE based on Eclipse. The name is Titanium Studio. It has a pretty nice autocomplete, which helps in a lot of cases. It also has some drawbacks, like in my case sometimes the syntax highlight didn’t work, without any clue were the problem was. Also, project management seems a little strange and it had some issues with import and export of the projects.

There isn’t a default visual tool for editing elements in the page. Both Xcode and ADT allow for editing elements with drag & drop. It turns out there are tools for this, but they are not free.

Emulators are not very configurable. The good part is that you don’t have to worry, you select the operating system and display type and Titanium will automatically configure an emulator. The bad part is that I might wish for a clearer resource management.

Another disadvantage is that sometimes the application will crash before the emulator starts and if you try again it will try to start a new emulator without any luck, case in which the emulator has to be closed. Run Project clean and try again, careful not to miss the moment when the screen can be unlocked, or the scenario will repeat.

For iPhone logs do not work when it comes to OS X Mavericks.

Good parts

It is easy to learn.

The documentation is well done and where something is not clear, surely somebody asked the question before.

There is a fairly large community.

The IDE is easy to use.

It’s easy to see what is possible to achieve with the Kitchen Sink app.

The app doesn’t look like a web page in a WebView!

Bad parts

The app size is quite big (16M on the phone).

The graphical elements are only a subset of the platform.

It isn’t very fast, because the code is interpreted and not compiled, to be able to interact directly with the OS.

There isn’t a visual editor.

There are some issues on integration with emulators, both for Android and iPhone.

Conclusion

If you are a JavaScript connoisseur and you need an application fast and also want to have native graphical elements, then probably Titanium is for you.

If you want performance, probably you need to look for something else.

I don’t have enough experience with the Android SDK to be able to build this application in the timeframe I had available, this was my compromise.

To be honest, I’m not sure wether PhoneGap was a better option or not, speaking for my case. Today there are a lot of JavaScript libraries out there built especially to emulate native graphical elements into a PhoneGap application. The difference is not necessarily visible and, in the end, maybe sometimes the app doesn’t really have to look like a standard app, maybe a completely different interface is more appropriate.

Last week I wanted to make an mobile application (Android). Initially I wanted to use Titanium, a platform that I’ve played with in the past and I was nicely impressed.

But after I downloaded the compiler and made the first application I had a surprise, the “Hello world” app had about 5M. How did it get so big? Simple, Titanium compiles the application into native code but there is no clear method by which to determine what APIs are used, so the minimum necessary APIs are compiled in order for all features to work. The perspective of an app bigger then 5M didn’t impress me, so I’ve started searching for alternatives.

I’ve installed Phonegap, I wanted to make a game on this platform for a long time, but because the installation is not as elegant as it is for Titanium I wasn’t very delighted. I’ve made a “Hello world” app and it had only… ~200k! A reasonable size in my opinion.

Of course there is a reason for that size, PhoneGap is giving access to a lot of features like: accelerometer, camera or contacts, but nothing on the presentation layer. The presentation is made exclusively with HTML, CSS and JavaScript.

The entire PhoneGap project is based on the fact that most platforms have a “web view” that can parse a web page.

But because the project is not as “packed” as Titanium new features can be added relatively easy. For instance, for Android there are a decent number of projects that add new features to the platform. Loading them is not very difficult, but is not plug & play. Basically there are Java modules for Android that expose an API that can be called from “web view”. This can be an advantage, because there is a community that is developing features that don’t necessarily need to be in the “core”.

For simple apps that only list or display information, the platform is a interesting alternative, especially because there are a lot of JavaScript and CSS frameworks for formatting mobile pages like: jQTouch, jQuery Mobile or XUI. The platform is great for packing applications of this nature. For instance if you have an HTML app for mobile and you want to add some native phone features and to distribute the compiled version, PhoneGap does a great job.

On the other hand, even if you can access for instance the menu button, you can’t create a native menu.

As a conclusion, this is a platform that has a completely different approach to Titanium. If Titanium is based on the fact that an application will compile to native code with native APIs, all the code base is written in JavaScript and web view is only one of the options available, PhoneGap’s approach is that the presentation is made exclusively in a web view using HTML(5) + CSS and only some device specific APIs can’t be accessed from the browser and are not presentation related to be exposed, like: vibration, buttons, etc. Taking that into consideration I don’t think that the two platforms can be really compared, only the developer can decide what approach is best.