Retrospective on Appcelerator Titanium and Alloy
Working as a Front-End JavaScript developer there would naturally come a time when you would need to work on a mobile solution. There are couple of ways to handle it, from writing a pure website for your users to access your content to coding a native implementation and putting it up on the play/app store. And many more in between.
Appcelerator Titanium and Alloy MVC #
One of the solutions that are in between is Appcelerator’s Titanium and Alloy MVC Frameworks. This solution allows those familiar with #webdev technologies such as HTML, CSS, and JavaScript to produce native apps without really needing to learn Objective-C, Cocoa, Java, and the Android SDK. Other solutions that produce the same or close to the same functionality as Appcelerator is Facebook’s React Native and PhoneGap (also known as Apache Cordova). And Many More.
This post isn’t really about whether building the app natively is better than using these frameworks to facilitate the process but rather what to watch out for in my short time working on Appcelerator’s Titanium and Alloy MVC.
Parameters on my retrospective: #
- Medium complexity application (DB, Offline, Users, Native-specific code, Native-specific design, no i8ln, etc)
- Developed using a mix of CoffeeScript, SCSS, and Titanium
- Developed iOS first before porting to Android
- Did not use Titanium Studio (link has a login-wall) but rather opted for the CLI interface (with Grunt)
- Used a Macbook Pro because Apple makes you use their products to develop iOS apps (not a Titanium limitation but an iOS one)
Android Gotchas #
toImage()function is really just buggy for Android compared to iOS where it works perfectly. Example is usingtoImage()in a ScrollView where it does not take the whole scroll view but only a section slice on top no matter where you may have scrolled to previously- You need to use the media property of an image blob for Android but just the blob itself for iOS (
img.toImage().mediavsimg.toImage()only) - You cannot use
rgba(RR, GG, BB, AA)for styling but rather should use the Android hexbang version of#AARRGGBB - There is no centralized font loading mechanism unlike for iOS which poses problems for dynamically adding a font since Titanium does not provide end points to do this (only build time)
- Very sluggish emulator (which isn’t really a Titanium problem nor is it inherently a Macbook or Android problem but just a curse of circumstance) to the point where it takes almost 5 minutes to load up a fresh build (mostly waiting for the signing and installing of the APK onto the emulator)
Retrospective #
The Titanium framework works as expected for the majority of items you need for a native app. It has extensions to allow you to create modules for specific native implementations (written in native code ofc) that you might need otherwise. However the support it has for the Android platform compared to iOS may be tricky and daunting to trust so walk with caution especially for the points I highlighted above. While it may get some time to get used to doing CSS in the “TSS” way or HTML in the Alloy way, it is fairly intuitive to an experienced “JavaScript” developer. The JavaScript however is fairly limited in that the Ti objects are hard to debug and use and the JS code itself is generally just more strict in all aspects.
Pros:
- Learn once, write everywhere
- Very similar to webdev structure
- Extension points for true native modules
Cons:
- Lack of Android support
- The Appcelerator way or the highway
- Limits the freedom of JavaScript