If you care about users enjoying your service from their mobile devices, then you should ask yourself: is it enough or necessary to make an amazing responsive website to answer their needs? Probably not. So you go ahead and build a great iOS app version of the website. But is that enough?
Well, not exactly, since there are currently more Android than iOS devices out there in the world, so it’s much more sensible to release an Android app even before creating one for iOS. All this summarizes the main reasons why I decided that I needed to learn how to build an Android app. Plus it forced me work from a different perspective, allowing me to grow my knowledge as a developer so much that I decided to apply what I learned back to our iOS development.
And so, the journey begins
I approached learning how Android apps are built by referencing back to my iOS experience. Of course, there was a new language to learn, Java; a new IDE to figure out, like Eclipse and more recently Android Studio; but new patterns, frameworks, and libraries too. It was all hard enough, but I started from the basics and by reviewing its main elements:
The AndroidManifest.xml file is the public description of the app. There you define which part of the app Android can run, from the Activities (for the user) to the Services (for internal operations).
I noticed that the app sign flow is much less flexible. Your keys for signing need to always (and forever) be the same, from the moment you first build your Android app, otherwise Google Play will not recognize your subsequent builds as updates but as different apps. That’s a big difference compared to iOS, which requires that every year you update your development and distribution certificates. Android, on the other hand, only gives you this one occasion.
An Activity is your app screen, where users will interact with your app. Keep in mind that an Activity is like a UIViewController, but with a different lifecycle. Android can destroy any Activity that is not visible to the user at any time, so be prepared to save (and then restore) its correct state.
And last but not least, almost all of the UI is made inside xml files. These are all clean and simple xml files you can edit, indent, and diff if needed when checking what changed between commits.
This is even more powerful when you consider that you can use a theme (a collection of styles you can apply to any element) to style your UI in order to keep colors, fonts, and spacing (plus much more) consistent through your app. This way if you want to change, let’s say, the main color of your app, you can do it all in just one place (within the theme), and that change will automatically apply everywhere else.
3 years have passed
After years of Android development I learned a few, but mighty tips:
Embrace the differences
It’s safer if you just put your experience aside and start learning everything again “from scratch”. Things that look similar to what you’ve worked on before can actually be very different. Avoid slipping back to what you’ve done in the past as much as you can.
Keep the business logic out of UI components (Activity and Fragment)
Yes, Activity and Fragment are high level UI components. Keep your main logic out of them and just execute it from the UI. It helps you avoid state inconsistency and, not least importantly, allows you to write less code. Your business logic is already in its real correct state, so trust that.
Keep your XML layouts as clean as your Java code
After a lot of experimentation, I personally like to be able to design a view in pure XML, writing each element and its attributes. This is not feasible on iOS, where you can only use “Interface Builder” and then drag and drop UI components and arrange them that way. XML layouts give you a readable UI structure, which is also way easier to diff when working in a team.
Design for devices of any size and shape
Because it’s just not possible to test an app on every single screen size available out there, perfecting UI is just plain difficult. So work with following guidelines, not perfect mockups.
Don’t mess with app signing
Take your time and make sure that app signing works in a stable and safe way. Keep your keys safe somewhere (in the same repository, with your source code, but encrypted!) so that if you have to stop working on the app for a while, it will still be easy to understand how it works.
All in all
I learned a lot from working with Android, mostly because changing perspectives made me grow as a developer and as a human being.
If you want to talk more about iOS or Android development, you can find me on Twitter at dral3x. I would love to hear from you what you think is the most challenging thing about learning a new platform!