How to Start Android Development with an iOS Background

Development iOS Android

If all you've ever done in the past is iOS development, looking to build an app on Android might make you feel like you're entering the Wild West. Things seem more fragmented, more dangerous, more complex, more green. In 2016 though, Android isn't necessarily more difficult than iOS. The majority of your domain knowledge and expertise of building mobile apps on one platform can be applied to the other with ease. You may even find yourself enjoying some of Android's development components more than iOS. Here's a Savvy Apps guide to the top considerations for developers making the move from iOS to Android, including a list of how the main iOS components are laid out in Android.

Android Development: More Similar to iOS Than You Think

You know Objective-C and/or Swift. You're feeling pretty good about your iOS programming skills, but now you're worried about starting at square one again with Android. You're not sure you want to go through the tedious process of learning a whole new language. The good news is you probably already know more than you think.

Android is written in Java, an Object Oriented Programming (OOP) language just like Objective-C and Swift. After working with OOP in iOS, you've already wrapped your mind around the buzzword concepts of objects, encapsulation, polymorphism, and inheritance whether or not you can recite the definitions of these words. You know all about self, subclasses/superclasses, overriding methods, and delegates in iOS. You'll still use all of these concepts in Android, only now with Java. You'll use Java keywords like this, extends, @override, and implements to do all of these same things. You'll be using the same design patterns, like singletons and factory methods. You'll still be primarily creating and working with objects, just the Java Object instead of NSObject.

Wikipedia has a helpful, descriptive list of Java keywords. Once you have an idea of their textbook definitions, you can figure out their practical usage through context by browsing Android sample code from Google.

Comparing iOS and Android Syntax and Semantics

The most daunting part of moving from iOS to Android is figuring out what Android components to use to replace their iOS counterparts. Thankfully, this mostly comes down to syntax and semantics. With the excellent official documentation and guides from the Android team, finding the answer to “In Android, how do I...?” is easy. Almost everything in iOS and Android has parallel features, either supported in-house or via third party frameworks. Some of those parallels are listed below.

Nomenclature

  • iOS: Class prefixes as in “SAViewController”(Objective-C), Modules (Swift)
  • Android: Namespacing and package management; no prefixes needed, however, private instance variables should start with "m" as is "mFoo"

Getters/Setters

  • iOS: Properties auto @synthesized (Objective-C), Native Properties (Swift)
  • Android: Need to generate getFoo and setFoo methods

Null/Nil

  • iOS: Messages passed to nil objects are no-ops (Objective-C), Optionals (Swift)
  • Android: Need to Null check objects, otherwise methods on Null will crash

Assets

  • iOS: .xcassets asset catalogs for multi-resolution screen support
  • Android: res folder includes images, XML layout files and XML value files, organized by file structure for multiple device categories

UI Layout Files

  • iOS: Commonly a single .storyboard file, but could be broken into many .nib and .storyboard files
  • Android: Every unique UI will have a separate XML layout file

Project Configuration File

View Class Component

Lists

Text Display

  • iOS: UILabel - not directly editable text; UITextField - editable/entry for small text amount; UITextView - display large amount of text, with option to allow user interaction
  • Android: TextView - EditText is a subclass that allows for editing displayed text

Loosely Coupled Callbacks

Asynchronous Logic

Dependency Manager

Project Hierarchy

  • iOS: Workspace with many projects. Targets to bundle code and resources together
  • Android: A single Project (in Android Studio) with many Modules that bundle code and resources together; a module can be broken further into flavors

Primitives

  • iOS: int, float, double, char
  • Android: int, float, char (Integer is an object)

Screen Size Units

  • iOS: Pixels and points; points are preferred.
  • Android: Pixels, density-independent pixels (dp), scale-independent pixels (sp); dp and sp are preferred

Resuming a Killed App

  • iOS: Starts from scratch and relaunches the app, unless using State Restoration practices
  • Android: Maintains a stack of activities and allows state restoration through "saveState" and "loadState" methods

Orientation Changes

  • iOS: Auto Layout default support, with custom implementation through OS rotation methods firing, maintains state
  • Android: Several options available including destroying/rebuilding Activities for the new orientation, using new layouts based on qualifiers

Using Xcode vs. Android Studio

Xcode: the IDE we love and hate in equal measure. While Xcode has a lot going for it and has made tremendous improvements over the last few years, you'll probably discover some features in Android Studio that you wish you had in Xcode. At Savvy, we particularly like the speed and performance of autocomplete and searching in Android Studio compared to Xcode.

Android Studio will also help reduce writing boilerplate code for subclasses with pre-population of overriding methods, Import statements, new method generation, and is smarter with offering fixes for compiler errors. Otherwise, for the most part, Xcode and Android Studio will provide the same amount of support in developing your app.

There are, of course, plenty of small differences between the two IDEs. UI code is presented and written differently. As mentioned earlier, Xcode uses storyboards and nibs whereas Android Studios uses individual XML files. Debugging on the Android emulator can be painfully slow at times when compared to the snappy iOS simulator.

Dealing with Different Screen Sizes

For years, iOS developers only had to deal with one screen size, good old 320 x 480 px. iOS developers laughed at the Android developers trying to build their apps for many similar yet annoyingly different screen sizes. When the iPhone 5 came out, iOS developers were still stuck on minimizing the variety of screen sizes, while Android had been iterating and improving their tools for not only multiple screen sizes but also multiple screen densities. This brings us to present day where iOS is largely in the same boat as Android, with many different sizes and densities to worry about, but without the tools and experience Android developers have been dealing with this whole time.

The resulting difference between dealing with iOS Auto Layout and Size Classes vs Android XML attributes and the layout file structure leaves us feeling very impressed with Android. Once you learn the magic of Android XML Constants like match_parent and wrap_content, you will feel embarrassed at how long it took you to create those complex Auto Layout constraints in your iOS project.

Again, learning the syntax will be the largest hurdle to overcome, but with a few minutes reading documentation, you'll be able to design Android UI layouts on par with your iOS app. Remember your .xcassets folder in Xcode? Android has something similar, but using an actual file structure instead of file metadata. This is usually easier to explain and understand, especially when communicating with designers on what assets go where.

Addressing Android SDK Fragmentation and API Support

One of the biggest fears is Android fragmentation in the wild. You certainly should discuss and analyze how low you want to set your minimum SDK. While this is the same question posed to iOS developers, it's usually just answered quicker with a more confident answer. Android OS versions go back a long way, with more older versions still in use. You want to reach as many potential users as you can, but you don't want your hands to be tied down by old SDKs, same as in iOS.

Android Studio helps as much as it can in making the API support decision. It gives you data up front on how popular each of the previous SDKs are and what features are introduced or deprecated in each. You can get these stats when you go to create your Android Project in Android Studio and select “Help Me Choose.”

Testing with Developer Console

You've persevered in building your new Android app that looks and feels definitively like Android yet still captures the brand and cool features you've flushed out in iOS. Now you need to get it the hands of some beta testers. Though there isn't TestFlight support for Android anymore, there still are plenty of options including Google Play's own beta testing through the Developer Console. Android does not have as many hoops to jump through to get this setup either (yay Xcode provisioning profile fun!).

Another note to mention, you probably won't have to wait as long to hear back from Google after submitting your app to the Google Play Store as you did from Apple (and you'll probably see fewer rejections too). Nothing is more frustrating than submitting to the App Store, waiting a week, and then hearing your app was rejected for not including the proper description tag in the app details.

Concluding Note

We are not suggesting it's trivial to build your app on Android. We are confident though that if you can build iOS apps, there is nothing stopping you from also building Android apps. If you've been hesitant to dip your feet in, go download Android Studio and read a great starter tutorial like Ray Wenderlich's Android Tutorial. You’ll then find out for yourself how Android development compares. Working in a rapidly evolving industry like app development, you'll never be sorry for having learned something new.

Matthew Tea is an iOS developer with a passion for quality, tested code. He's a team player with a strong desire to learn new and upcoming technologies.

You made it this far so...