Appcelerator Titanium: From a developer's perspective

The API docs are incredibly sparse, however, helpful enough for the nuts and bolts of dealing with our JSON API, storing to plist files and using the built-in HTTP client. I am currently wrestling with structuring our app such that it fits to one of the paradigms given in the Kitchen Sink; this has been incredible tough. As noted by others, sliding and scrolling behavior is erratic.

Our current iPhone interface is a fully manifested jQtouch web app, and I have pushed the performance of the app as far as possible. It isn't terribly slow, however, it one of the main bottlenecks users have in interacting with our service.

I originally set out wrapping our jQtouch app in PhoneGap - a simple task. However, given the way that PhoneGap works, the performance was no better than the current web app. I then completely rebuilt the app in jQuery Mobile (Alpha 3 at the time), loaded it into Phone Gap and discovered that the interactions and load time were slower than my original jQTouch app. This isn't to knock jQuery Mobile or PhoneGap; rather it is a reminder that for a full jQuery Mobile or jQTouch app you are looking at loading 140-200Kb of JavaScript every time you open the app. If Nitro ever comes to homescreen apps, this will be less of an issue.

The long and short of it is that while PhoneGap certainly gives you infinite flexibility in what the UI of your app can do, you have to be vigilant about keeping your load times down by minimizing frameworks. If you already have built an iPhone web app that meets your performance requirements, load it into PhoneGap.

Alternatively, if you want a fast, lightweight app with a UI that mirrors one of Titanium's demos given in their Kitchen Sink, then I believe that the struggle is worth it. All of my commentary is working under the assumption that you have no Objective-C experience.

I recommend downloading the app Wunderlist to get an idea of the extent to which one can customize a Titanium app.

This is the line that builds and runs my project:

  /Library/Application\ Support/Titanium/mobilesdk/osx/1.6.0/iphone/builder.py "simulator" "4.2" /Users/jehlke/workspace/titanium/Manabi "org.manabi.mobile" "Manabi"

That said, some comments: - JS Warnings. It's true that one-line ifs, property existence checks, function closure suggestions, etc. can get a little annoying. My solution is to write JS which is 100% JSLint compatible, which is fair IMO.

- Titanium Warnings. These get annoying. I get dozens of "[object TiUIView] has an auto height value of 0, meaning this view may not be visible" warnings which are completely useless and don't identify the offending View for me to fix. Also, I get about a dozen errors like ": CGContextDrawImage: invalid context 0x0" which give me no indication which is the offending image. Etc.

- Performance. While native, our application runs a little sluggish and certain views are choppy when scrolling, and some style properties have bizarre rendering behaviour (layout: 'horizontal', width / height: 'auto', etc)

- Minor Revisions. The author is right, some minor revisions introduce pretty bad issues. 1.6.0 introduced some very noticeable performance degradations in TableViews, so we're still on 1.5.1 for now.

- Documentation needs work. The API reference is lacking any mention of certain parameters, which is frustrating. The wiki has more detailed information and has essential reads to understand things like TableViews, but I didn't find this resource for several weeks into my project. Many undocumented side-effects exist, like quirky behaviour on horizontal layouts, etc. Here's an example of the kind of confusion which results: https://appcelerator.lighthouseapp.com/projects/32238/ticket... The "headerPullView" feature for pull-to-refresh is currently undocumented magic.

- Barcode support is disappointing. Titanium+ introduced Barcode support, but does not support the usual 1D barcode. The additional libraries that exist (TiBar, zbar, etc.) are very difficult to compile in without XCode hackery, and sometimes don't work on the devices themselves, making debugging very difficult.

- Bugs in XHR with Content-Type and passing Arrays, requiring workarounds when integrating with Rails. Arrays get sent as "( key1: value1\n key2: value2\n)\n" .. seriously :)

- Titanium Developer required me to click "Launch" to start the application until I read Gene Tsai's comment on the original article which gives you command-line aliases to start your application. Awesome tip :)

At the end of the day, Titanium Mobile is a great solution, but be prepared to be patient while the platform matures, and to get creative in architecting alternate solutions when your initial approach doesn't work. I'm confident the wrinkles I point out above will be ironed out in time.