Recently I got a new project to develop a mobile app as frontend for a complex IBM Notes application. Target platform is iOS first and Blackberry 10 later, maybe even Android. The customer selected Appcelerator Titanium as platform and Domino To Go as framework for working with IBM Notes data. Offline capability with storage of relatively big datasets was mandatory, so any mobile web or hybrid approach was out of the game.
I know there are posts in the Web saying how ugly Titanium is, how many problems it has et al. From my experience, all of that is not true, at least not today. The Titanium development environment works smooth and stable, every API works as it should. The API documentation is very good, and Appcelerator even offers a lot of additional documentation for topics like how to setup the native SDK for iOS, Android and Blackberry 10. Furthermore, the Q&A section of Appcelerator’s website is excellent and a reliable source for solving development questions.
Since I know Titanium for a long time now, I’m aware that in the early days of Titanium things were completely different. There were lots of memory and stability problems and documentation was poor – but as I said above, all of those problems are gone, at least in my experience.
When working in an Alloy Titanium project, you are motivated to modularize your code with the CommonJS technique, which is also a good thing because it prevents namespace issues and offers a well-established system to split your project into manageable pieces.
In that project, the customer uses Domino To Go to synchronize about 100.000 datasets from Notes views to the device, so they can be used offline. There are three components that take time during the synchronization:
1.) Domino To Go on the Domino side needs to run through the view, read view entries and build JSON data.
2.) The device needs to download the JSON data from Domino.
3.) The JSON data needs to be processed on the device to transform then into a NotesView-like data structure and store it in the SQLite database on the device.
First, a full synchronization took more than 3 minutes in the simulator. After some optimization, we managed to bring this down to about 40 seconds. After the first full synchronization, caching techniques are used, so next synchronisations will be even faster.
But, from my point of view, 40 seconds for about 100.000 view datasets is not that bad after all 🙂
The only ugly thing with developing a native iOS App is the amount of work needed to be able to deploy the app on test devices first, and for the enterprise distribution later. To deploy on test devices, you need apply for the Apple developer program, which can take some days until Apple checked and processed your application. Then you need to understand their system of provisioning profiles and all the certificates you need.
For every test device you need to get it’s UUID, enter it in the member area of the iOS developer center, create a new provision profile, download it and install it on the Mac. Sure, you will do this work seldom, only when you got a new test device, but for new developers, it takes some time to understand this procedure.
But the Apple procedures have nothing to do with Titanium. I think, Titanium is a very good choice to develop native mobile apps. I like mobile web apps, too, but so far, I like working with Titanium better.