Why you should stay away from Appcelerator’s Titanium

Let’s face it – programming on mobile devices is hard: everything’s much more complicated to accomplish than it is on the web or the desktop and, since the platform is fairly new, tools and frameworks are scarce and poorly refined. Plus, if you need your application to run on more than one target OS (iOS, Android, Blackberry) you’re pretty much forced to write a different application for each one of them.

So, enter Appcelerator’s Titanium – what Titanium aims to accomplish is to solve most of these problems, by hiding all the gory implementation details behind a simple and well-defined javascript API. On top of that, it will (more or less) compile your javascript to a different language (objective-c for iOS, Java for Android and soon Blackberry) so you can deploy your application to multiple targets with (supposedly) no changes to your code. And it’s free! Support and other goodies come for a price but the library itself is free for commercial use.

What’s the catch then? On the surface, it’s all good – you pop up Titanium Studio (a modified version of Aptana), write some trivial javascript and you’ve got a working, native app. Great, it took me a day or two to do this in native objective-c – with Titanium, it’s a couple of hours! So you dive head first and build more and more complex apps – animations, database connection, networking, geolocation, it’s got it all!

The more complex your applications become, the more often you encounter some weird glitches – why the navbar’s title not centered? And why sometimes the navigation controller doesn’t pop the last view? Or why the focus event gets called so often, for no reason, only on the device? But you know, Titanium’s so much better than going back to native development, so you deal with all its quirks and carry on. Until bad stuff starts to happen.

Your app starts to crash, seemingly at random. The reason : memory starvation. You see, although Titanium is supposed to take care of memory management for you, it doesn’t always work correctly. Most of the times, especially if your application is simple and doesn’t use many images and animations, the memory leaks Titanium generates over time will be small enough that you won’t even realise that your application is actually leaking. Problem is, when your application reaches a certain level of complexity, those leaks will become evident – in the form of sudden, unavoidable crashes.

There are some hacks, proposed by Titanium’s community that somewhat help to free some memory but they don’t always work and, even when they do, they don’t release all the memory they’re supposed to. Titanium doesn’t let you change your object’s reference count directly (probably because that would break some internals of theirs) so you have no way to dispose of objects yourself.

This leaves you stuck with a frail, buggy application that is ready to blow up at every click… and there’s nothing you can do about it except for a complete rewrite in objective-c or java.

Are you planning to develop mobile apps with Appcelerator’s Titanium? Think twice. It’s tempting but you really, really don’t want to find yourself stuck like it happened to me. Unless it’s either for small, simple applications, or they somehow manage to solve all their memory issues, I strongly suggest you to stay away from Titanium.


What’s so special about Apple products?

Some days ago I read on Reddit about John Resig’s setup:

Redditor : What is your development setup? (Software)

John Resig : I use OS X on an iMac with an extra monitor. For coding I use VIM in a terminal and have a screen session open to IRC in another terminal window. I then have a plethora of browsers open (Firefox, Chrome, Safari, Opera – a VMWare with IEs) for testing. That’s pretty much all that I use and need to use (I have a very similar set up on my Macbook Pro, as well).

So, John Resig actually develops on a mac. Also, down the same thread, some other redditor points out that 95% of the web conferences audience he goes to owns a MacBook or a MacBook Pro.

Well, for the last months I’ve been developing on a mac too and here’s some of the things I’ve had to deal with:

  • There is NO del key : the Macbook/Macbook Pro has no del key. That leads to an array of Hm, now delete / ack, there’s no delete / rightarrowrightarrowrightarrow / backspacebackspacebackspace, which is incredibly annoying because it completely kills the flow. Even worse, you unlearn to use the del key so when you switch back to a normal machine the tendency is to keep using the right arrow/backspace combo or (god forbid) the mouse.
  • Apple key instead of CTRL : on macs, the function that is normally accomplished by the CTRL key is instead done by the Apple (command?) key, which is located pretty much where the Win key would be on a Windows keyboard. This is annoying because it forces you to unlearn the convention which you’re used to (for no apparent good reason) but the worst thing is that the behaviour is NOT consistent from application to application, meaning that in some applications (example : nano) the CTRL key is behaving as usual and the Apple key does nothing (or does something completely unrelated to what you want to do).
  • You can’t cut a file on Finder : it seems that there is no way to cut a file and paste it somewhere else in finder. Even if there were a way to do that, there’s no keyboard shortcut for it (ctrl-x and apple-x do nothing) and there’s no mention of a cut option in the context menu. Also, since there’s no DEL key, if you want to delete a file you have to use the option in the context menu to do that.
  • Git is very slow : git commit takes an eternity to complete, for no apparent good reason. A commit which takes a second or two on my old laptop running Kubuntu or on a Windows machine will take 30-60 seconds on a Mac. Also git push is sensibly slower but not as much as git commit.
    Since it takes an eternity to commit my work, I’ve started to commit less frequently. That lead to a big loss of work on a couple of occasions.
  • Limited customization: I really don’t like the dock (that panel with all the applications icons) and I wanted to recreate something similar to what I use on Kubuntu, so one bar on the left with all the program launcher and a taskbar on the left. Turns out I can’t have a taskbar at all and the only thing I can do with the dock is to choose which side of the screen it has to be on.

On top of all this, my impression is that Apple machines are very slow compared to PCs with similar specs: a colleague of mine needed to clone a remote git repository so I’ve asked him to open a terminal – it needed a good 30 seconds for the terminal to start. On my Kubuntu laptop (which shares similar specs with my colleague’s MacBook) I can open a dozen in five seconds or so. Also, sometimes applications freeze for some seconds, again for no good apparent reason, and you have to wait until they come back up.

All in all, my experience with macs so far has been far from positive: I guess that if you’re a “normal” user you wouldn’t care one bit about all the things I pointed out but, as a programmer, I find all of this extremely annoying.

But anyway, since I have to work on iPhone/iPad applications, I thought that I could well pay a 100/200 € more for a mac machine and then dual boot linux – that way, I could both work on my mobile projects and still have linux on the same machine for everything else. I’ve wanted to change my laptop for a while now and this is what I had in mind, so I went to the online Apple Store and made myself a MacBook pro with similar specs. And I was once again surprised at the outcome:

The ACER AS594, my original choice – € 749.99

A MacBook Pro with similar hardware – € 2.149,00

That’s almost 3 times the price. John Resig thinks it’s worth it. 95% of web developers think it’s worth it. Do you? If so, would you please tell me why? Because, in all honesty, I don’t understand what’s so special about Apple products.

How to: get Titanium WebView’s content height

I’ve been working with Appcelerator Titanium and, compared to the hell that is native iOS application development, I’ve been quite satisfied so far… except from the occasional bug/glitch that forces me to write some ugly workarounds.

A notable example is when you need to get the content height of a WebView. Let’s say you have two elements inside a single ScrollView: one is a View of any kind with a given height (for example, an ImageView) and the other is a WebView. You want to scroll both the ImageView and the WebView at the same time so, when you slide a finger on the device vertically, the ImageView scrolls up and you see more of the WebView‘s content. Problem is, there is not a contentHeight property on the WebView control and you need that height to set the height property of the WebView to avoid its native scrollbar to be active: if you don’t set an height to the WebView it will display a vertical scrollbar for its own content, hence avoiding the scroll on the external ScrollView.

Fact is, there is actually a way to get the WebView‘s content height: the WebView has an evalJS() method which allows you to execute arbitrary JavaScript inside the WebView (as you would inside a browser). The trick is to ask the WebView for its own document.height and take that as the content’s height, as follows:

actualHeight = webView.evalJS("document.height;");

The only catch is that you will get the real content height only after the WebView has finished rendering. If you are rendering from an external URL you can use the load() event, which will get called when the page has finished rendering, otherwise you’ll have to set a timer, like this:

myTimer = setInterval(function () {
    actualHeight = webView.evalJS("document.height;");
    if(actualHeight > 1)
            webView.height = actualHeight;
            scrollView.contentHeight = imageView.height + webView.height;            

and then dispose the timer with myTimer.clearInterval(). Hope this helps!