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 its 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 as 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 the 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 by 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 a 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 a device.


Overall, I really enjoyed the experience of working in the native world. I learned a lot about 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.