Ti.Next is going to be fun

So I haven't been very active on my blog lately, sorry for that. I've been busy with work and some personal projects (expect a post on my aquarium project relatively soon). I've got some fun stuff to talk about though, so first up I'm going discuss what I've been working on at work recently. Our CEO, Jeff Haynie, recently wrote a blog post talking about the next version of Titanium, codenamed Ti.Next. In short, it's going to be awesome.

To understand why the new architecture is so awesome requires understanding the old architecture. If we look at the Android implementation of the Titanium SDK, we notice that the vast majority is written in Java, the native language for Android development. The codebase is very specific to the Android platform. If we look at the iOS implementation, the situation is even worse, with 100% of the code written in Objective-C. This makes maintenance and testing quite difficult because the addition of a new platform results in a linear increase in the amount of development and testing resources needed. In addition, the people we bring on tend to be well versed in one platform, but have little training in the others. In my case, I know the Mobile Web platform inside and out, but to me the iOS and Android platforms might as well be written in Greek.

This approach worked fine when there were only two platforms, but within the last year we have also brought on Mobile Web, BlackBerry, and Tizen, and we have plans to bring up Windows Phone 8. It has become obvious that we need a new approach.

Fortunately there has been a confluence of events that led to several of us having basically the same idea simultaneously, yet independently. What if we moved as much of the SDK implementation into JavaScript as possible? By doing so we can share code by default across the platforms, only forking platform specific code when absolutely necessary. even when we do have to fork, it's still written in JavaScript making it easy for SDK developers to move from one platform to another.

There is another major advantage we can get from moving to this architecture: parity. Right now, each platform re-implements the SDK spec on their own. I think we have a talented team of developers, but we're still human and make mistakes and there are several instances where a method that is supposed to be the same across all the platforms actually isn't. By moving to this new architecture, these kinds of human errors become impossible since there is only one front-end shared across all of the platforms.

This also gives us a chance to implement a layout algorithm similar to the one I designed for Mobile Web which takes the Titanium SDK layout parameters (which are very expressive, but complex) and boils them down to simple left/top width/height values that can be easily set by the platform. The advantage to using a mechanism like this is that we get instant layout parity across all platforms, something which we lack today.

I am fortunate enough to have gotten in on the ground floor of this rewrite. So far it's all R&D, and I can't really talk about specifics, but suffice to say I've been digging pretty deeply into the guts of the first platform we are going to implement this new runtime for. It's been really fun. I haven't had a chance to do any C++ work in some time, and it holds a special place in my heart because it was the first programming language that I learned in my first programming course back in high school (in the late 90s). There's just something about going back and programming in C++ that makes me feel all warm and fuzzy inside :). As part of the change, I am no longer working on the Titanium Code Processor. While there is a slight twinge of sadness, I'm pretty happy about it overall because it means I can pour myself into Ti.Next.

There are a lot of challenges that lie ahead, but I think that we can deliver a new SDK implementation that will be more performant than the current one, much easier to maintain, and will be a lot easier to extend as well. It's going to be fun.