Disclaimer: I am a software developer at Clio and this post is also published at Clio Lab; since I am an author, I believe it is okay to publish here.
There’s a saying at Clio: “draw the fucking owl.” Last year, for me, that owl was an iOS app. This year, it was the Android app. From absolutely no Android app development experience to leading a team of six amazing product members and building a full-spec practice management app, it’s been truly an amazing journey.
On September 22nd, when I witnessed the launch of the Android app at the Clio Cloud Conference in Chicago, I was absolutely amazed at how everything came together.
It’s hard to believe that it was only eleven months ago that we started the project. I was definitely nervous. It wasn't really because of the new responsibilities that came with being a team lead; it was because I had no experience with Android, yet I had to lead a team of developers and make a million decisions. I powered through a handful of Android development books and met with a few key players in Android development communities in Vancouver. I want to thank Jerome from Amazon, Mike Worth, and Jeff Stautz from HootSuite for giving me advice and tons of tips. I also went to a local mobile app development shop, SteamClock Software, and arranged a workshop; in two days, we covered topics like multi-threading, UI implementation, animations, best practices, and some major differences between iOS and Android. These were just some of the steps I took to get into the Android game.
Our team started with one product manager who oversaw both Android and iOS as well as API, one UI designer/developer, and three developers including myself. We added another developer and a new mobile QA analyst. Hiring was/still is challenging because there’s a lot of pressure to make a decision with just a few hours of interviewing, but I had to make a call. Criteria for a talented software developer remain consistent regardless of the field, but I’m definitely a lot more comfortable interviewing now with the experience and knowledge I’ve gained.
These are some of the things I look for from candidates: a deep understanding of the Activity and Fragment lifecycles, various issues with a runtime configuration change, consequences in dealing with a runtime configuration change in a variety of situations, threading, and processes, UI view elements, database knowledge, Java skills, experience with major HTTP libraries, etc. For a QA analyst, I’d like to see experience in Continuous Integration systems and configuring with mobile environment, various integration testing tools for mobile app development, and some programming experience.
It comes down to: "if you have to plan for an Android app release and need to have support for thousands of devices, multi-OS versions, and a variety of screen resolution sizes, what is your plan to meet our quality standard with these conditions and being able to confidently ship an app at a release date?" We've been working on that since the beginning and are still trying to get it right. If you can give me a solid answer for this question, you’re all set. Come chat with me. :)
Development and Tooling
One of the best decisions we made at the beginning was being aggressive about setting support for OS versions. Although the Android market is getting much better with adopting newer OS versions (especially thanks to the release of Android 4.4), many Android developers suffer from supporting older versions of OS. Having looked at the market and where it’s going, we determined that we’ll be able to cover a majority of US Android market with version 4.1 and up, and decided to go with ‘minSdkVersion 16.’ Looking back now, we definitely made a good bet. In fact, about 85% of our Android customers are on Android 4.4, which is very impressive.
We all use Android Studio for IDE. It got a lot better and more stable after Version 0.8 which came out at this year's Google I/O, and I see fewer crashes and less hassle every time I upgrade to a new version. Gladle is used as the build tool as it’s a default build tool for Android Studio. It has its own learning curve, but it’s highly customizable and comes with many preconfigured commands. For distribution, we use Google Play. It makes it very easy for us to do alpha and beta testing; this has definitely been an important part of our development cycle. Four months after starting the project, we started doing alpha testing with internal people; a month before the public release, we beta-tested with users. This gave us a lot of valuable feedback and caught hundreds of bugs prior to the public release. This built-in alpha/beta release functionality in Google Play Store is a unique advantage for Android vs. iOS development, and I am hoping to see this space improved for iOS development.
Our best friend for crash reports and monitoring builds is Crashlytics; their bug reports and detailed information about exceptions logs are a golden asset to developers.
About testing... coming from Rails development with Rspec, writing tests for an Android project is not as friendly and can get frustrating. We use Roboletric for JUnit testing and Instrumentation tests bundled with Espresso. Setting them up alone took us a few weeks to figure out. There are so many gotchas with these testing tools, and we sometimes spend more time writing tests and trying to get tests working than actual app programming. This is one place where I would like to see more improvement for Android development. We use dependency injection; we started with Roboguice and later on switched to Dagger. It gives you a lot of flexibility and lets you change configurations to deal with different environments for testing, development, and production.
For an HTTP client, we started with Retrofit but switched to Volley; Volley offers a lot more flexibilities, and it offers multi-threaded HTTP requests, providing a capability to manage request queues.
Oh and 65K DEX methods limit... you should know this since you will have to eventually deal with it. Read more about it here or from Jake Wharton.
If I had to give one piece of advice to a new Android developer…
It would be this: "an activity can be destroyed at anytime, and your code has to survive that." Activity lifecycle is by far the most important piece of this puzzle; without understanding this in-depth, you will not have a reliable application. This detailed chart for both Activity and Fragment lifecycles describes its complexity. Print that out and absorb it. All of it.
This well-defined article from our best friend Crashlytics describes the three most important issues that everyone will face: 3 Key Ways to Increase Android Support Library Stability.
In fact, for the last few weeks since the beta testing and continued through public releases, we've been constantly fighting with these issues. Understanding these problems and addressing them throughout the project is a key to increasing the stability of a project.
Related to development, we've introduced a few things to keep us informed on this very complex nature. What we call Android tea time is where team members give a brief demo on what they’ve been working on for past few weeks and walk the team through codes and designs. This brings an immediate advantage, because as a project gets bigger and complex, it’s easy to lose track of what else is going on. This is an opportunity for us to exchange ideas and share knowledge across the team. Another one is the lunch-and-learn. As soon as we face a new issue or discover a new technology, a team member is assigned to do research for a few days and come back to the team with a talk. Lastly, we've organized an information exchange night with the HootSuite mobile development team (and we’re planning to have another one with Mobify); each of us prepares five topics that we can do presentations on, and both sides pick two topics that they’d like to hear and give talks about. It’s not only beneficial to hear the talks, but also helps us learn about how other companies manage mobile products. I’d love to do this again with HootSuite and possibly other Vancouver-based companies.
Minimum Viable Product
When we plan out a road map, we handpick core functionalities of the app and choose the minimum set of features that are needed to create an useful app for users. This lets us focus on key features and work on the most important ones first, speeding up our user feedback process.
The Importance of Design
The app is described as "incredibly smooth, well designed, and intuitive” from a Play Store review. Jeff Taylor said that "Clio’s Android app is something they should be proud of. The app is beautifully designed." There is no doubt that design plays a significant role in product development here. I originally came from a web development background, without any design expertise. It used to be okay to say, “Designers work on front-end, and developers worry about back-end.” But with two years of mobile app development, I’ve come to realize that it’s no longer acceptable. I, as a mobile app developer, need to have as much expertise in mobile designs as a designer. I am not a design expert, but in order to become a better mobile app developer, I need to change that. Design will only increase in significance and it will continue to be a major part of product development in Clio.
What's Possible in Mobile
It took us close to two years to get here, but now, we have a presence in both iOS and Android. This is a significant achievement as a company. We've learned so much. We've learned what each platform can offer, what users want from the mobile apps, and how they interact with the apps. With the experience we've had over the years, we are moving up to the next iteration of mobile app products. We’ve literally just entered this space, and the possibilities ahead of us are big. I’m very excited about the road ahead—it's going to be another fun ride.
ps: we are hiring at Clio! If you are a passionate developer or designer who believes a beautifully designed software can make a difference in the world, come work with us!