This post is a little outdated! Like I said a few paragraphs below, Titanium will change in the course of its development—and it certainly did. While most of the information I wrote here are still valid (in terms of what’s gonna be possible and what Titanium aims to bring), the technologies and architecture of the platform has radically changed in PR2. I’ve written a follow-up post regarding Titanium PR2, which you should read after you finish this one.
I love Adobe AIR. In fact, I’ve been developing AIR-based applications for my clients since the first betas were released. It’s been almost a year since the first stable version was released and it’s apparent that AIR has certainly changed the course of RIA development history.
But time and again, AIR and I have our disagreements. There are a lot of good things in AIR, don’t get me wrong, but sometimes I wish there was something more—like a better plugin architecture or a more useful custom deployment system. And while I highly appreciate the efforts of the team behind AIR, I’ll admit that every now and then, I google “AIR open source alternative” just to see if there’s something better. No luck—until now that is.
In this post, I’ll be looking at Titanium, its similarities and differences between Adobe AIR and why you, as a RIA developer should be interested in the project. And believe me, from what I’ve seen, it’s bound to be the next big thing in RIA development for the PBW.
Please remember that Titanium is preview software and everything I write here is based on the Preview Release 1 (PR1). Things may change through the course of it’s development, and my main point in writing this is to introduce Titanium and contrast it with Adobe AIR. Also, this post wouldn’t be possible without Marshall Culpepper, the head developer for Titanium, who answered all of my questions and gave me insight on how Titanium works.
If you’re not interested in reading through a whole lot of words, you could jump to the Quick Giddyficator section to get an overview of why you should be excited.
An Open AIR?
We all knew it was inevitable: someone, somewhere will eventually create an open-source alternative to AIR. It’s how things work these days: if you release closed-sourced software, a free and open source alternative is bound to appear. And in the case of AIR, that could be Appcelerator’s Titanium.
But don’t form conclusions yet. While it may seem as something like an open-sourced version of AIR (and it really tends to look like one in some points), Titanium is really a different beast—which is why I insist on using “alternative” rather than “version.” The platforms may have the same goals, but they have different ways of reaching them.
A Little X-Ray Vision
Internally speaking, the only thing AIR and Titanium have in common is the use of Webkit to parse and display the resources. Other than that, each platform uses a different approach in their architecture.
In creating AIR, Adobe used a forked version of Webkit. Basically, HTML-based applications are run using the AIR HTMLLoader class that sits on top of Flash. It’s kinda like having a web-browser within a flash movie with the API’s exposed. Flex based apps don’t really need Webkit, since they run on flash itself.
On the other hand, Titanium, as of PR1, binds several technologies together:
- Webkit (via the native libraries in OS X and via Chromium in Windows)
- Google Gears (for the initial desktop bridge—more on that later)
Titanium also uses GTK+ and Ruby (for the build system). And because it’s brought to you by the same folks who created the powerful Appcelerator platform, it’s only fitting that they include their powerful platform as well.
The possibilities are endless.
A glance at the internal workings of AIR and Titanium reveal basic similarities between the two. Essentially, AIR and Titanium apps are composed of three things:
- A generic binary for launching the app.
- The application descriptor
- The resources for the app itself
When you launch an AIR or Titanium app, the application binary reads the descriptor file, which contains the settings for your app. The parameters are then processed and the application looks for the necessary files to run your app in the application’s resources.
The first big difference is that AIR relies on a system-wide runtime: the main AIR runtime should first be installed on a user’s system because all AIR apps use the same shared libraries. On the other hand, Titanium apps (in PR1) are self-contained applications: everything your application needs in order to run—your app specific files and the runtime itself—is included within every app.
Titanium’s approach eliminates one of the biggest roadblocks to AIR adoption: the need to install too many things. With Adobe AIR, one has to install the runtime first and then the AIR app itself. While the seamless install mechanism in AIR certainly eases the burden of the process, nothing really beats the simplicity of dragging and dropping a Titanium app into your Applications folder—for OS X at least.
Titanium’s approach would also be a godsend for all developers who want a way to customize the installation process. Because Titanium apps are generated as native OS X and Windows apps rather than archived files, developers now have a way to create their own installation process—perhaps rolling their own native installer apps.
Of course, there’s the downside involving the file size of Titanium apps: since the runtime libraries are also included in the package, a Titanium App would significantly be bigger. AIR apps distributed via a .air file are small because they only contain the app specific resources and the descriptor file; the actual binaries for AIR apps are generated during the installation process rather than during packing time.
Marshall said that this is only for PR1, at least. For the next release of Titanium, we may see a different approach to runtime usage: a Titanium app would be able to either use the system-wide runtime or use a packaged runtime within the application—similar to how Rails apps could freeze gems.
That would be the better way, I think—to leave the decision of whether they want smaller applications with external dependencies or larger files that could run standalone to the developers.
Roll Out the Development Kits!
The AIR SDK's main tools are the Application Debug Launcher (or ADL) and the AIR Developer Tool (or ADT). ADL is used to launch apps during the development phase (via the
adl application.xml terminal command) and ADT is used for packaging and code signing the final app.
AIR is lenient when it comes to your development process: there’s no strict directory structure needed and you could pretty much roll out an app with all resources within a single directory. You’re expected to create your own directory structure and there’s no command to create new air apps or to generate application descriptor files (although the SDK does contain a sample descriptor file, as well as other useful libraries).
On the other hand, the Titanium SDK is very Rails-eque. It contains tools for the Appcelerator platform and the useful
app terminal command, which is used to create and package Titanium applications. A simple call to
app create:project projectDir/ projectName titanium would generate the necessary files needed for a new project. The dummy project created by the command is actually a fully working documentation app, which can be run by using the
app launch:project command.
One thing that I don’t like though, is the fact that Titanium generates too many files. The only necessary files for a Titanium app are the Titanium Application XML (tiapp.xml), the aid file (a file that contains a unique ID for each app used for tracking) and your initial HTML page. Using the
app create:project command will also add the Appcelerator libraries to the initial project—which, while a great platform itself, isn’t the only library everyone will use. Fortunately, Marshall said that future versions of the SDK will have options of whether or not to include the Appcelerator libraries or whether to use your own favorite libraries.
Another thing that bugs me is that when you use it to create new projects or package projects into apps, the Titanium SDK fetches the needed template files and runtime binaries from a remote source. While I somehow agree with Marshall in the sense that this ensures that you have the latest and most stable version for your app, it kinda bugs me that I might not be able to create a new project using the SDK during one of those 3-hour, internet-less bus trips to Tarlac. Updated, Dec. 12: Apparently, I was slightly wrong. While Titanium does fetch the template files and runtime from a remote source, it does it only once and it catches it. Everytime a new project is created or a project is packaged, the SDK pings the server to see if there are new versions. If not, the cached files are used. Hooray for bus coding…
A Developer’s Cocktail
If asked what’s the best part about Titanium, I’d answer without hesitation: the limitless possibilities.
There’s the fact that Titanium is open source software—anyone can access the code and modify it to fit their own needs. With the right coding skills, you can take the platform into heights that are currently not possible on any RIA platform available today.
There’s also the possibility of framework encapsulation via plugins. Ajax framework developers could roll out Titanium plugins that feature their libraries and leverage them by exposing other desktop-only functions like file-system access and database connectivity. Not to mention the fact that it would also be possible to create something like a Rails or Django plugin that would run a local version of the Framework within Titanium itself—which would provide ways of creating Ruby or Python powered apps that could run without a system-wide installation of the interpreters.
What’s Usable Now?
The Titanium team announced the availability of the first preview release last December 9. Like any preview software, it’s bound to have a lot of little nasties and limited capabilities.
But don’t let that turn you off. Even if it’s a preview release, the current version of Titanium already has a solid API based on Gears, and gives you access to a host of functions for:
- Local Databases CRUD
- Filesystem access
- Basic media playback
- Native window and menu support
- Network detection
There’s also an NPAPI based plugin framework already in place if you want to start creating plugins—although it would be better to wait for the next release, since Marshall mentioned they’re planning to create “a richer and more modern API soon.”
Aside from the official SDK, you can also download some of the demo apps on the Titanium site. There’s Playtanium, the Youtube desktop player, and Tweettanium, a twitter client.
In case I’ve lost you through the several hundred words above or in case you just want a quick overview, here’s the main reasons why you should be excited about Titanium:
- It’s free and open source software released under the Apache License, Version 2.0.
- It uses some of the best open-source software today: Webkit, Google Gears, JQuery, Ruby, GTK+ and the Appcelerator Open Web Platform.
- It features a powerful and extremely useful SDK.
- PR1 packages the runtime with the app itself, removing the need for users to install a system-wide runtime. PR2 will include the option of either including the runtime in the app or using a system-wide, self-installed runtime.
- You’ll be able to use a slew of technologies for development: HTML and Ajax, Flash and Flex, Silverlight, and a whole lot more.
- You’ll be able to use web MVC frameworks without too much modification—provided there’s a plugin created for it.
- It’s library and technologically agnostic: bring your own tools!
The Future of the PBW
As I said, before, I love Adobe AIR. It’s one of the things that changed my life as a developer and i’ll be forever grateful for it. But there’s a time when you realize that the tools you’re using are binding you too tightly, and you want something more.
While I’ll still be using Adobe AIR for my next projects because it’s already stable enough to support mission critical projects that my clients need, I’m keeping my eyes on Titanium. And as a sign of my whole-hearted support for this new project, I promise that as soon as a stable release comes out, I’m gonna port all my previous client works from AIR to Titanium—free of charge (yep, my dear clients, free of charge). And from this day on, let me be known as a Titanium Preacher. Not Evangelist, Preacher.
Titanium might still need a lot of polishing before it could shine as the ultimate RIA platform for the PBW. But looking at the initial preview release and the goals set forth by the team behind it, it’s apparent that Titanium has real potential to become the future of the PBW. Its way of leveraging technologies to take them to new heights, its open and free nature and its well-designed architecture: all of these will contribute to its eventual success.
And it will take the power of us developers to take it there. So if you’re interested in learning more about Titanium, you can head out to the official website at http://titaniumapp.com. The Preview Release 1 SDK is available from their downloads page and you can also check out the demos. There’s also documentation on the site, as well as other useful information on the Github wiki for Titanium (where you can also check out the source.)
You can join the community by posting through the official forums or the official IRC channel, #titanium_app at freenode.net. And if you do get stuck or come across some bugs, don’t hesitate to ask info from the places above, or post tickets at the official JIRA.
And be sure you subscribe to Keetology: I’ll be posting more articles and quick start guides in a few days for your reading please. Everything to retain my title as a Titanium Preacher…
In case you missed the notice atop this post, let me repeat: this post is a little outdated. Please check out what’s new in Titanium PR2 on a folllow-up blog-post here.