DeveloperTown

Start from the beginning with “We can create an app for that!”

So, we now know that one of the best canvases for your genius idea in this latest paradigm is mobile devices. We also have been over the native versus web dilemma. Last time we went over native versus native-native, and began talking about how abstraction platforms like Titanium can be useful in the delivery of quality solutions. Now we will dig into Titanium a bit. First, the good:

For me the most important thing about this particular abstraction is the language. If I were to do a series of posts about the “interactive web”, JavaScript would be King Kong of that discussion. JavaScript has had an interesting life from the perspective of application developers. It used to be an unwanted, glazed over, unfortunate necessity step-child that you threw in at the end of a project to make it appear a bit more interactive. However, now with the proliferation of AJAX-based applications and the general maturation of the web developer, it has risen to one of the most prominent positions in the app dev world. Given that many of the application developers that are at the forefront of the general tech movement are in the interactive web space, it makes JavaScript a sexy language to build your entire application with. JavaScript is not just for the UI anymore. You may have heard of rising star development platforms such as Node.js. Well, Node is not the only player in the server side JavaScript world, and I believe we are just at the beginning of the JavaScript movement.

The Titanium creators must believe, like me, that JavaScript is going to continue to play an increasingly important role in application development. I believe they have done a great job in allowing those JavaScript nuts to use their “hard won” skills as a foundation for productivity when creating native mobile apps.

Some of the Titanium competition (and even Appcelerator themselves in the early days of Titanium), make the claim that you can use all of your web dev skills when creating native apps. This is a decent MVP for creating an abstraction, but it is Not a good solution. Basically, it is putting a native wrapper around a browser. Not cool…not cool at all. Titanium has an entire framework that uses the JavaScript language, but has almost nothing else that translates directly from your current web dev skills. This is a good thing though… It reminds me of desktop app development, but with a new age web-esque event-driven OO twist.

I am also a fan of the eclipse IDE, which is what the Titanium IDE is built on top of. The framework is organized and well thought out. The documentation is pretty decent as well. Some stuff is android-y (like interacting with a hardware keyboard and menu buttons) and some stuff is Apple-y (like having a common top toolbar and swipe to delete gestures), and Titanium allows you to do both. You will lose some portability when you take advantage of platform-specific features, but it is a billion times easier than writing two completely different apps. Once you get the hang of where things are and how they interact with each other, creating quality solutions becomes very fluid and rewarding process. Overall, after you get over a few hiccups (which I’ll cover in the post about the bad) it is a pleasant and fast development experience.

Bottom line:

JavaScript goood…

Not utilizing a web browser wrapper and calling it native (if you want a web app, build a web app), gooood…

A very understandable and flexible framework that allows each platform to reach their potential…goooooooood…

I am a computer technologist/scientist, and I remember writing multiple reports throughout school about the great portability wars going on between Microsoft (with .Net backed by their CLR) and Sun (with Java backed by their JVM). The basis of this war was Microsoft said, “You can write in any of our languages, C#, F#, VB, etc, and they will all be converted into machine code by the CLR and run the same on any of our Windows-based machines”. Sun said, “You can write in Java and it will run on any platform that has a JVM built for it…which essentially converts the Java code into machine code”. In my opinion neither approach achieved true portability.

Portability in its purest sense is the ability to write once, and run anywhere, and this is even more important when talking about the array of platform options you have with mobile devices.

We have been discussing what the options are on our journey to deliver our innovative services to our potential customers. So lets say we want to go native…now we have to decide what platforms to target. The dominant markets include Apple’s AppStore and the Android Marketplace, so when building an app the last thing you want to do is build the same app multiple times on multiple platforms. Who cares though right…in the end we just want portability.

As with most attempts at portability, you usually start with a language/framework that you like, and have it compile down to the underlying platform’s language. In the mobile space there have been a few attempts at this, and the competition to be the “go-to abstraction” is heating up. We at DeveloperTown have done our research, and decided that the best option at the moment is a development environment called Titanium, built by Appcelerator.

Deciding to go with an abstraction like Titanium has its pros and cons. Biggest con is that with any abstraction you are at the mercy of the abstraction. To an extent, I’ll include the previously mentioned Sun -v- Microsoft battle. They basically put easier to use, more productive languages and frameworks on top of a compiler. Titanium does the same thing…it puts JavaScript on top of Java for Android, and Objective-C for iOS. Yes, you give up control, and put yourself at the mercy of the abstraction when you don’t use the native-native language/framework. But, the pros and cons of building on an abstraction in many instances outweigh the cons but, it is not all good…as we will see, there is some good, some bad, and some ugly…