Titanium to Native Android: These aren’t the frameworks you’re looking for

Titanium to Native Android: These aren’t the frameworks you’re looking for

A little about the developer

Having been working with the Titanium mobile application framework for the better part of the last year, I have developed an appreciation for what it does and what it tries to do. Creating a true cross-platform framework that tries to do almost everything that each native framework can do and unifying those into a singular codebase is definitely a challenge, one that Appcelerator has done well. After working on several projects with the framework, I feel that my programming skills and my understanding of the mobile world have drastically improved.

That being said, I wanted to start working more in the native world to get a better understanding of what Titanium was doing behind the scenes. This led me to start exploring the native frameworks for iOS and Android. I have focused on Android as I have a decent Java background. I’ve always believed that the best way to learn something new is to just dive in and figure stuff out as you go. Thus, I decided to recreate the very first application that I worked on after starting at Shockoe. The new application was dubbed Doorman as that was ultimately it’s basic purpose. It’s meant to act as a virtual doorman for people walking into the office. After getting the API setup, I jumped into writing the code and learning more about Android.

My Impressions of Android

My initial impressions of native Android development were very good. While it did have a learning curve, once I started to get a better understanding of activities, intents, services, etc it was a breeze to work with. It did miss some of the libraries that Alloy had access to like Moment, Underscore, and Backbone but I learned to work around them. Probably the most noticeable difference in the Android world coming from Titanium was the sheer amount of developer support found on the web and documentation. In addition to the amount of documentation put out by Google, the number of Stack Overflow posts with developers having similar problems really helped me with detailed explanations and examples from responses. It was indeed a breath of fresh air for a new developer just starting to get their feet wet. Even working with third party libraries was simple as they were optimized to work within the Android environment and I could use them directly rather than having to create a separate module to link the two together. Appcelerator did have a lot of detailed documentation that I heavily relied on, especially when working on the already existing codebases that used components and proxies with which I wasn’t very familiar. However, there were times when I ran into an issue that I couldn’t resolve with the documentation. The fewer number of developers post on internet made it more difficult to find a resolution if my fellow Shockoe developers couldn’t help me.

Setting up Jenkins

Once I was comfortable enough with the state of the application and API that I felt a test build was necessary I moved over to work with Jenkins, our build environment. Initially, I was a bit nervous about getting the build setup. I hadn’t yet built the application through the command line but instead was using Android Studio. As it turned out, it was a very simple process to get the builds created and uploaded after some research into Gradle, a fantastic build tool for Android applications. With just two shell commands I was able to build the application and get the .apk file to send to AppTracker, our in-house distribution service. I was amazed how easy it was to get setup. However, it didn’t take long for me to realize that the app was showing errors when trying to install on a device. Turns out that I wasn’t signing my apps before uploading them. Oops. Again, with the help of the large number of Android developers on Stack Overflow, I was able to determine that I needed to adjust my Gradle scripts a bit. I just needed to link a .keystore file to the Gradle build command then bam, signed .apk files to upload to AppTracker. The app was then ready to install on device.


Overall, I really enjoyed the experience working in the native world. I learned a lot about the what is going on behind the scenes when developing Titanium apps. I believe that this understanding will help me to become a better developer going into the future. While I know that Titanium won’t be going away anytime soon as it is a great tool for creating quality applications and a relatively small time frame from not having to create and maintain two separate codebases, I would love to continue learning more about the native world.

Profiling Titanium: Getting a picture of the Kroll toll

Profiling Titanium: Getting a picture of the Kroll toll

As cross-platform developers, we all know that maintaining speed in a complex codebase is of paramount importance. When you’re adding layers of abstraction to your code in hopes of being able to share large portions of it across disparate platforms, the little steps you have to take to synchronize your common code with the underlying platform specific code can quickly add up to a massive slowdown that leaves you with an application that performs and feels no better than a mobile web application plopped into a WebView.

The Kroll Bridge

Titanium effectively acts as a three tier framework. At the lowest level, there is a layer of native code used to implement core application functionality. These are your views, your HTTP clients, and your other pieces of code that reach out and allow you to interact with device features like the camera and geolocation service. On top of these platform-specific native layers lies a platform-specific bridging layer, which allows you to abstract away the complexity of these native objects and translate them into Javascript-land objects (called proxy objects). Finally, on top of this bridging layer lies your application-specific Javascript code, which is where the bulk of your application logic will reside.


Titanium’s abstraction and bridging layer is known as the Kroll Bridge, and it represents the single biggest bottleneck in a Titanium application. The Kroll bridge is exactly what it sounds like, it’s a connection between the native objects in your application provided by the Titanium SDK and the Javascript proxy objects that stand in their place within your Javascript code. Every time you update one of your proxy objects, the Kroll bridge gets to work synchronizing your changes to the native object. Because of this automatic synchronization logic, it’s easy to make a huge number of Kroll calls without really recognizing what you’re doing, which leaves you with an application that has no obvious performance issues (from a code perspective) that has distinct slowdowns when placed on a physical device.

Acknowledging the Kroll cost

Titanium provides various methods of sending data back and forward between your Javascript code and your native code. For the most part, these can be divided into the categories of bulk operations vs sequential operations. Going in to this blog post, I had intended to write at length about the virtues of batching your calls and minimizing your Kroll crossings, however it seems like there may be more nuances to the performance concerns in Titanium than I had thought! For the purposes of this blog post, I’ve taken a look at how long various operations block the Titanium thread.

I’ve prepared a couple of minimal test cases, with built-in timestamping and simple profiling code, so feel free to test these cases on your own devices! For each of these tests, we’ll run some operation 1000 times and take the difference in milliseconds between the start of the operations and the end. Note that this testbed only takes a look at how long different operations tie up the Titanium thread. Many of these tests tie up the UI thread for a substantial amount of time as well, and will cause the app to become unresponsive. The UI thread performance of these tests are outside of the scope of this blog post, I’d like to circle back in a few weeks and take a closer look at the UI impact of these tests as well.

I ran all of my tests on a Nexus 5 running Android 6.0 Marshmallow and an iPhone 5 running iOS 9.1. I ran six trials of each of these tests, and averaged the results. I’ve published the test code on github. Take a look, give it a clone, and follow along on your own devices.

Creation arguments vs Create then set

Titanium provides factory methods to create proxy objects, which allow you to interact with native objects that you may need multiple instances of. Optionally, these methods accept a creation dictionary describing its initial state. Of course, you can just make the proxy and then configure it later, what’s the difference?

var newView = Ti.UI.createView();
newView.top = 5;
newView.height = 40;
newView.width = Ti.UI.FILL;
newView.left = 5;
newView.right = 5;
newView.backgroundColor = 'red';
var newView = Ti.UI.createView({
    top : 5,
    height : 40,
    width : Ti.UI.FILL,
    left : 5,
    right : 5,
    backgroundColor : 'red'


On iOS, this behaves largely as expected. Creation with arguments returns a little faster than the creation followed by sets. On Android, however, in addition to being substantially slower, the creation dictionary actually slowed the creation process down!

Sequential updates vs applyProperties

Similarly, Titanium provides both individual property set APIs as well as a bulk application API. Take the following examples:

view.height          = 80;
view.backgroundColor = 'blue';
view.left            = 10;
view.right           = 10;
	height          : 80,
	backgroundColor : 'blue',
	left            : 10,
	right           : 10


Oddly enough, we observe the opposite behavior here from view creation! Android performs as expected, with the bulk API yielding better performance. iOS on the other hand runs quite slowly, and the bulk API is slower than the sequential sets.

TableView population

The table structures in Titanium also provide bulk or individual modification APIs. Consider the following examples:

for(var ii = 0; ii < 1000; ++ii){
	var newRow = Ti.UI.createTableViewRow({
		top : 5,
		height : 40,
		width : Ti.UI.FILL,
		left : 5,
		right : 5,
		backgroundColor : 'red'

var tableData = [];
for(var ii = 0; ii < 1000; ++ii){
	var newRow = Ti.UI.createTableViewRow({
		top : 5,
		height : 40,
		width : Ti.UI.FILL,
		left : 5,
		right : 5,
		backgroundColor : 'red'




Finally, an expected result! The bulk population API is massively more performant than the individual population API. Android is still a little slower than iOS, but that is mostly expected.

View Removal

When flushing the views within a hierarchy, you can either loop over the children array or call removeAllChildren.

var children = theWindow.children;

for(var ii = 0, numChildren = children.length; ii < numChildren; ++ii){


Another API that performs differently on iOS vs Android. On iOS, the call to removeAllChildren is almost immediate, whereas on Android the call takes even longer than looping over the entire child list and removing them individually.

Event Firing

Titanium exposes a built-in eventing API used for communicating between native code and Javascript code. Additionally, Backbone exposes an eventing API for communication between Javascript objects. I frequently see the Titanium eventing API repurposed for use in Javascript-land communication, let’s see what the impact is.

var startTime;

var handledCount = 0;

function testListener(){

	if(handledCount === 10000){
		var endTime = new Date();
		var delta = endTime - startTime;

		alert('fired 10000 Ti.APP events in ' + delta + 'ms');

		Ti.App.removeEventListener('testEvent', testListener);

Ti.App.addEventListener('testEvent', testListener);

startTime = new Date();

for(var ii = 0; ii < 10000; ++ii){
var startTime;

//since events fire asynchronously, we need to keep track of how many were handled.
var handledCount = 0;
var eventingObj = _.extend({}, Backbone.Events);

eventingObj.on('testEvent', function(){

	if(handledCount === 10000){
		var endTime = new Date();
		var delta = endTime - startTime;

		alert('fired 10000 Backbone events in ' + delta + 'ms');

startTime = new Date();

for(var ii = 0; ii < 10000; ++ii){


Another substantial difference. Backbone events perform consistently (and impressively well!) on both platforms, whereas Titanium events are much slower on iOS, and are a little slower on Android.


The clearest take-aways from these tests are that one needs to be much more careful while modifying the view hierarchy on android, that Ti.App events are quite slow, and that there isn’t a one-size-fits-all performance solution for Titanium. There’s no magic bullet that you can adopt in your codebase and not have to worry about platform-specific performance issues. Android’s slowness when handing creation dictionaries and iOS’s aversion to applyProperties makes it more difficult to write platform agnostic performant code. That being said, in the general case, applyProperties is still worth using, because of the small performance hit we took on iOS and the performance bump we get on Android (which is usually the issue from a performance perspective).

At the end of the day, there’s no substitute for profiling your application and making use of the platform-specific Alloy preprocessor directives (OS_ANDROID, OS_IOS) to deal with platform-specific performance issues. And now that we’re armed with concrete data, we’re ever so slightly better equipped to do that!

Appcelerator Titanium iOS Debugging with XCode

Appcelerator Titanium iOS Debugging with XCode

Earlier this week, I was debugging and I was reminded of the sheer power of the XCode developer tools, even in the context of a not-quite-native application like a titanium application.

The Problem

Andrew was working on an application that will load in a large number of images and PDFs from a remote server and display them to the user, in-app. However, when we got to the point that we would be displaying a certain one of our images, we saw this in the Titanium console:

[ERROR] invalid image type. expected TiBlob, String, TiFile, was: TiBlob -[TiUIImageView setImage_:](TiUIImageView.m:687)

Sorry, what? It seems like something odd is happening at a native level, and Titanium is getting too confused to return a sensible error message. Well, guess it’s time to open a support ticket with Appcelerator and wait for them to figure out what the issue could be, right?

Wrong. One of my favorite things about Appcelerator Titanium is its open-source nature. What we can do from here, is open up the native project generated by Titanium and debug it with the normal native debugging tools. When you build a Titanium application for iOS, a (pretty much) normal XCode project is generated from your project, compiled, and run on whatever test device you have selected. In situations like this, we can take that project and manually re-build it in XCode for debugging purposes.

Opening your project in XCode

To open your project in XCode, first run

ti build -p ios --build-only

in your project’s directory. This will ensure you have a native project generated for your Titanium project. From here, all you need to do is open XCode, and open up the XCode project in the build/iphone folder.

Path to a Titanium project's compiled XCode Project

Setting Native Breakpoints

Now that we’ve got the project in XCode, we need to set up a native breakpoint so that we can see what the issue is with the Objective-C code that Titanium is executing on our behalf. Fortunately, the message that Titanium printed out gave us a selector name:

-[TiUIImageView setImage_:]

. Let’s go ahead and set up a symbolic breakpoint for that selector:

Add a breakpoint in XCode by clicking the second icon from the right in the side bar, and then clicking the plus in the bottom right

Add the symbol from the error as the symbol name

Enter the XCode debugger

Now that we’ve got our breakpoints set up, we can run the project in XCode, and execution will stop when our breakpoint is hit in the Titanium SDK code.

The debugger will automatically pause execution when you hit a breakpoint.

Let’s go ahead and step over a few commands and see if we can figure out exactly what’s going wrong.

Step Over

Huh, it looks like we’re having some issue turning our Titanium file into a UIImage that we can apply to the native UIImageView. Let’s use the variable inspector to figure out exactly why we’re failing to convert this into an iOS image.

XCode variable inspection

Well, one look at the MIME type is enough to see exactly what’s wrong. Our file isn’t an image! Even though this didn’t tell us exactly where the issue was, it was enough to direct our debugging (we eventually figured out that we were accidentally saving a PDF file as an image – oops!). Issues like this are why I’m very quick to reach for XCode when I see a native iOS issue – it makes it much easier to figure out what parts of your code might be incorrect when you can easily trace through Appcelerator’s code!

Rapid Titanium WebView debugging with Chrome Developer Tools

Rapid Titanium WebView debugging with Chrome Developer Tools

Any Web Developer worth their salt is already familiar with the awesome Chrome Developer Tools package that ships with Google’s Chrome Browser.  What you might not know is that Android 4.4 introduced a powerful new native debugging tool for native Android/HTML5 hybrid apps that allows you to attach Chrome Developer Tools to a Web View running on a physical android device.  As part of our continuing mission to help you tame the Mobile Monster, we’ve taken the liberty of wrapping the code to enable this functionality in a Titanium-ready mobile module.  To make use of this new functionality in Titanium, you will need :

  • A laptop with the Google Chrome Browser
  • A phone running Android 4.4+ (and a charging cable)
  • An app built with Titanium SDK 3.4.1.GA +

Getting Started

First, download the pre-built module below.

[ No module needed on Android 4.4.x+ ] (update)

To make use of the module within your Titanium project, you just need to un-zip the module into your modules folder, and add it to your modules tag in your tiapp.xml.  We recommend only including this module for the development deploy type, since this is purely a debug tool.


Now, just build your app to an Android 4.4+ device, and you will be able to attach chrome developer tools to any web view within your app.

Attaching Chrome Developer Tools

Once you have your app on your test device, and have your test device connected to your development laptop, open Google Chrome and type chrome://inspect into the address bar.  This should open you up in the devices tab.


The Chrome developer tools device perspective

Then just click inspect.  A normal Chrome developer tools window will open, allowing you to inspect your element as normal.  In addition, you can click the new icon in the top-right of the screen to get a live preview of your WebView directly within the inspector window.

The Chrome Developer Tools inspector with on-device preview


And that’s it. You now have a full-featured Chrome Developer Tools window attached to your Titanium app’s WebViews, allowing you to use all of the same web development tools that you are familiar with from normal HTML/CSS/JavaScript apps to develop Titanium/Mobile Web hybrid apps.

68% of F100 Companies are now using Titanium (tiConf 2014)

68% of F100 Companies are now using Titanium (tiConf 2014)

This weekend the team at Shockoe had the opportunity to visit and speak at tiConf 2014 Manhattan.  The guys from  Tipsy & Tumbler found an amazing venue in Midtown, blocks away from Penn Station and Madison Square Garden.  Jeff Haynie opened up the conference on Saturday morning with an overview of Titanium and Appcelerator and then showcased some of the new features being released in June.   Jamil Spain wrapped up the weekend with the features and benefits the Appcelerator Platform gives its users.

All of the speakers had incredible content, but to summarize some of our favoirtes..

Jeff Haiyne (AppC Co-Founder) – Appcelerator and Titanium are quickly being adopted by some of the largest companies.  By using Titanium with the Appcelerator Platform, companies are eliminating point tools to scale mobile across the enterprise, they are driving further innovation with new app capabilities, and the platform is enabling them to measure the overall usage and success of the entire mobile app portfolio.  Some of the key facts he introduced include:  65,000 mobile apps deployed on over 200 million devices and more than 70% of Fortune 100 enterprises count on Appcelerator for their mobile success.  Check out his slides here:  AppC tiConf 2014

Matt Apperson (Apperson Labs) – Matt showed us how to use RapidDev by Apperson Labs to speed up the development of Titanium apps.  He also demo’d tools and techniques to improve app testing, check out his deck for more info:  RapidDev

Jamil Spain (AppC) – Jamil continued the day by talking about documentation best practices; documentation for software development is critical, but do we do it right.  Titanium brings an added level of challenge because of the cross platform capabilities, enter the npm module titanium-jsduck to save the day, read more here:  tiDev Documentation

Day two brought a series of incredible speakers again, while we cannot mention all of them, here is a quick summary about a few

Tony Lukasavage (AppC) – Tony kicked off Day Two with a conversation about tiAlloy.  He spoke about the roadmap, best practices, and stability.  Check out more about his presentation here:  Leaner and Meaner

Edwin Huertas & Alex Otanez (Shockoe) – Shockoe shared best practices focussed on building stronger partnerships with enterprise clients.  By using Titanium and the Appcelerator Platform, we spoke about creating long lasting client relationships and delivering faster enterprise innovation.

Trevor Ward (The Warped Coder) – Did you know that there are thousands of Mobile Device/OS permutations?  Trevor demo’d the setup process for the Genymotion emulator, a replacement for the standard Android emulator for development.  An easy to use tool that helps get passed a few of the testing pitfalls we all face.

A very special thanks goes out to Boydlee Pollentine and Tipsy & Tumbler for putting this event together

While we can’t mention the full speaker line-up, we had a blast in Manhattan, met some great people and learned a lot of new skills.  We are looking forward to the next tiConf.  Join us in Santiago Chile as we bring tiConf to Latin America fall 2014 –  tiConf Org

Shockoe Helps Homes.com House Hunters Find Perfect Rental

Shockoe Helps Homes.com House Hunters Find Perfect Rental

Mobile technology is changing the fundamental interactions between business and customers in meaningful ways not foreseen a decade ago.  Even a traditional business model, like car rentals, has been disrupted by a rapidly expanding company with what seemed a niche idea, due to the flexibility that mobile technology gives consumers.

Why can’t the same principle apply in the home rental space?

Homes.com is part of the fifth-largest real estate listing portal network with over three million homes represented in the United States and that’s the question that they asked us at Shockoe.com.

Since then, we have been working with Homes.com to enchance their collection of iOS and Android apps.  One of the first joint projects was released on October 16th to great acclaim.  Homes.com’s industry knowledge guided the thoughtful design and solid codebase that Shockoe supplied and the brand new Homes.com Rental app is averaging 4.9 out of 5 in the Google Play Store and 5/5 stars on the iOS App Store in just a week’s time.  And as a recent study showed, app ratings are now more critical to rankings, thus exposure, than ever before

So how did Shockoe and Homes.com do it?

The new Rentals app was built with today’s sophisticated renter in mind.  The app is the first in the market to offer current commute times for points of interest such as user’s place of employment, gym or shopping, tailoring the app to today’s ever busy consumer.  This of course hits the three keys to mobile real estate: geolocation, geolocation, geolocation.

Now, on-the-go consumers can easily browse an expansive database of rental listings on the Homes.com app, which has built-in extensions to Homes.com’s sister site ForRent.com.  ForRent.com is the exclusive provider of apartment listings on the Rentals app. Homes.com developed the smartphone app for effortless use on both iOS and Android devices and included iOS7 features such as natural navigation gestures.

“With year-over-year rental search traffic growing on Homes.com by more than 514 percent on mobile devices, our first priority in designing the rentals mobile app was to create an optimal shopping experience for renters,” said Brock MacLean, executive vice president of Homes.com. “The new app allows consumers to customize searches, instantly view and save listings, and connect with agents or property managers. Whether a renter is searching for a place to celebrate, create or unwind, the place to find it is Homes.com.”

The mobile app enables potential renters to tap into current listings filtered by user preferences.  Filters run from standards like price, size and type of residence to many extras like fireplaces, parking or (a mobile first for the industry) pet-friendly rentals. Map searches are made simple with slide and tap navigation, all while referencing a geo-targeted map for an easy view of points of interest throughout the search experience.

How did Shockoe create this for Homes.com in such a short timeframe?

From the beginning, Dominion tasked Shockoe with building the revisions in the Appcelerator Titanium codebase to create an amazing user experience across multiple operating systems and devices while improving overall app performance.  Rebuilding a unified codebase for Homes.com within Titanium offered Shockoe.com a chance to make big changes to simple usability and interface aspects of both mobile app experiences. For example, the older version of the mobile app made dynamic selection difficult in the area overview map.

Due to past experience, the Shockoe development team decided a whole new map design was necessary since the map function is a crucial. While it sounds daunting, we know it would end up being a major time saver since the redesign would be built just once in the Appcelerator Titanium toolset.  The new map function would then be instantly reflected across both iOS and Android versions for multiple form-factors and the functionality could be re-used and applied to other projects down the road for Homes.com.

Shockoe has been a longtime partner and evangelist of Appcelerator.  The cross-platform nature of Titanium enables us to meet deadlines and budgets that would be impossible had we designed for each platform separately.  Our experience with Titanium makes an already accelerated schedule even shorter.

We at Shockoe look forward to collaboration with Homes.com and their sister site ForRent.com in coming up with new and interesting ways to help the companies enhance products and tie themselves together in the mobile environment.  With an economical foundation on which to fortify their ability to acquire and cross-sell their customers in the mobile space, look for many more good things to come from the teams at Homes.com and ForRent.com.

How can Shockoe help your business take a great idea and make it a disruptive force in your industry?

Download the new Homes.com Rentals apps – [Google Play] [Apple App Store]

About Homes.com®
As one of North America’s top online real estate destinations, Homes.com® Rentals inspires consumers to dream big. From affordable houses to luxurious estates, condos, apartment rentals and more, Homes.com features nearly 3 million property listings and a user-friendly format, making finding your next home easy. Visitors to the Homes.com blog will find a collection of rich content and posts on DIY projects, painting, organization tips and more, providing the ultimate resource for everything home related. From finding your first apartment to buying your first home, upgrading, downsizing and everything in between, Homes.com is an inspiring and engaging partner in every phase of the home buying or renting process.

Homes.com is a division of Dominion Enterprises, a leading marketing services and publishing company headquartered in Norfolk, Virginia. For more information, visit www.dominionenterprises.com.

About ForRent.com®
As one of the nation’s leading online home search destinations, ForRent.com® inspires renters to discover their next apartment, loft, townhouse, or condo. ForRent.com features rental listings in a user-friendly format, making finding your next home an easy exploration. Visitors to ForRent.com’s apartment living blogFacebook pageTwitter account and Pinterest boards will discover relevant content and can join the conversation surrounding their home decorating style, rental tips and more, serving as the complete resource for renters in every part of their living experience.