Titanium Mobile for web developers

Fast speed dataflow.

Have you decided to start using Titanium Mobile, but don’t know where to begin? Are you currently a web developer who knows Javascript but who feels a little apprehensive about building an entire application in it? Well, this blog post can help!

What is Titanium Mobile?

Titanium Mobile is an SDK. Just as some browsers provide access to additional APIs, Titanium Mobile similarly extends Javascript (JS) to allow you to interface with native platform elements. Titanium Mobile runs in a native window context rather than a browser window, and thus no DOM exists. In fact, JS inside Titanium Mobile works in a way that more-closely resembles a server-side Javascript, like node.js, than it does a browser implementation. Keep all this in mind from the outset, and it will save a lot of frustration.
While the community has indeed developed a few Open Source frameworks that utilize Titanium, Titanium Mobile itself is NOT a framework.

Understanding the UI in Titanium

On the web, you are used to building a UI with divs in the Document Object Model (DOM), and having multiple pages to work with. With Titanium, most of this concept holds true, with the difference that with mobile development we call them “views”, instead of markup elements, and windows, instead of pages. Now, when laying out your app, the one thing that will immediately become apparent is that we use absolute positioning by default, due to the reduced CPU cycles it uses and hence its superior performance. That said, we do also have horizontal and vertical relative positioning as an option, which make creating layouts more convenient.

With Titanium we also have controls, such as buttons, sliders, switches and tabs to name just a few, which allow the user to intuitively interact with the app.

Does MVC still make sense?

There are a few “MVC”-style frameworks that the community has developed, and you are welcome to give them a try (a quick google search and you will find several). However, we feel it is easier to go with a modular structure, like the one demonstrated in our Tweetanium example app.

Titanium and window URLs

Many new developers see our KitchenSink example app and its use of the URL property, assume that this is a “best practice”, then go on to utilize it as they would page of a website. So let me explain why you would not want to routinely develop using this approach, but also one benefit that you should keep in mind.

The url property we define for windows works much like changing the url in a browser-based app, taking you to a new page. Just like in the browser, the app is now running in a new context or, in other words, it’s like a separate app within your app. The outcome of this is that variables that were set in other contexts are no longer accessible in your new context. To overcome this, browsers use cookies to store and retrieve data throughout a domain and, similarly, your app can set properties to make data accessible throughout an app. The drawback is that data will exist when it is no longer required, unless you explicitly delete it, whereas a modular design approach would result in the data being destroyed automatically.

Sometimes changing context can be a good thing, though. In the KitchenSink, it is helpful to ensure that variables in one window do not pollute the next, to make it clear to developers at a glance what is going on.

So what is a developer to do? Again, I will refer you to Tweetanium, as it provides a great example of how a single-context application is designed.

Cross-device testing

Despite the common misconception, Titanium is not a “write once, run everywhere” solution. Although you may find this surprising, this is intentional, and there are good reasons for it! Different platforms have their own strengths and weaknesses, and so if we made apps behave identically everywhere, it would dilute those strengths and, consequently, alienate your respective target markets. For example, iOS uses a Tab Bar located on the bottom of the screen that looks completely different to the Android Tab Group that resides at the top. However, while there are differences in the user interface implementation that you will need to accomodate, almost all of the business logic will be common to all platforms. Overall, think of it like cross-platform testing (not like ie6 vs safari, but more like firefox vs chrome).


Remember, the aim of Titanium is not to encourage you to transpose existing web apps directly to mobile. Rather, Titanium provides you with the tools you need, in a language you know, to build apps that give your audience a genuinely-native, immersive mobile experience!

Helpful links


  1. Great post, especially that bit about not crafting apps with the URL property. That would have been awesome to know when I first started out.