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.
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
Acknowledging the Kroll cost
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?
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:
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.
The table structures in Titanium also provide bulk or individual modification APIs. Consider the following examples:
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.
When flushing the views within a hierarchy, you can either loop over the children array or call removeAllChildren.
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.
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!
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