iOS and Android market share

The latest version of iOS is on 87% of devices, according to iDownloadBlog, in stark comparison to 15% of Android users being on the latest version of Android. You must consider, however, that Android has more users, where the latest official numbers indicate that iOS has 1 billion active users where Android has at least 1.4 billion active users. So for developers targeting customers, the latest and greatest iOS is on 870 million devices and the latest and greatest version of Android is on 210 million devices. When you also consider that iOS users spend 4X as much on platform, it really becomes difficult to justify starting a business on Android.

Android and iOS development side-by-side

Mobile platforms are polarizing, and it doesn’t help that’s there’s effectively only two. To that effect, I thought it’d be instructional to complete the same simple tutorial on both platforms to get an appreciation of what each does well and what each does differently. This tutorial will read something like “beginning Android for iOS developers.” The Android portion of this tutorial is inspired by “Android Programming: The Big Nerd Ranch Guide” by Bill Phillips, Christ Stewart, Brian Hardy, and Kristin Marsicano (if you want a more rigorous look at how to do this on Android rather than a compare and contrast, it’s a good book). The goal is to make an app which presents the user with a single question and informs them if it’s correct or incorrect.

Let’s start with Android. Some preliminaries: install Android Studio and the SDK installed on your computer and start a project. Now, navigate to your custom activity XML file (app/src/main/res/layout/activity_my.xml) and create a RelativeLayoutTextView, and two Button objects.

Note that the visual editor gives you the option to either input the text into the text views and buttons directly or create a new “value” for it, and either is fine. The new value option is quite interesting, however, as it works by placing the string in an XML file of your choosing and referencing it with a key-value pair. I imagine this is hugely useful when reviewing copy or localizing, but it does add a level of indirection for smaller projects where it’s not needed. String management is a pain-point I experience on iOS, so I definitely appreciate this feature.

You should also be sure to look at the properties of your button objects and give them IDs. The IDs are used to generate a file called R.java that maps this IDs to constants so you can access them at runtime. This is the same file that the strings get entered in to. I find this cumbersome compared to IBActions and IBOutlets on iOS, which allow you to drag and drop actions and references to files as you see fit, without needed to go through a generated file.

Now you should have something that looks roughly like this:

ih

The experience of setting this up in Android Studio is much better than it was in Eclipse. The IDE has a feature to hide a lot of the configuration files that you don’t need to worry about all the time and the visual preview works pretty well. Admittedly, the drag-and-drop visual editor functionality does not work so well, as it’s difficult to get your UI element into the view collection you want it to go in. Just like in Xcode with XML for UI, you have to open up the source file and modify it manually, however I get the impression that as I learn more Android there will be a lot more time spent manually writing XML than I ever spend on iOS, which is almost exclusively to resolve conflicts.

To perform the same path on iOS, download Xcode and start a new project. Go to the storyboard file and drop your UI elements into the square view. I recommend trying out stack views to do this, as they are a new feature with iOS 9 and they’re supposed to solve some of the pains with Auto Layout. Here’s what it ends up looking like:

Screen Shot 2016-02-26 at 6.42.46 AM

Android and iOS’s visual UI editors are in many respects equals. They both are XML editors and they both have quirks. I find the layout engine in iOS, Auto Layout, to be very powerful, but many people complain that it is difficult to use so I may just be experiencing Stockholm Syndrome.

Now that we have our UI finished, let’s write some code. The next step is to hook up our buttons to fire off a UI element which indicates to the user whether or not the answer they chose is correct. On Android, you get a reference to a view object from XML by asking your activity to find the view with an ID you set in the XML file. Like so:

this.mTrueButton = (Button) this.findViewById(R.id.true_button);
this.mFalseButton = (Button) this.findViewById(R.id.false_button);

While I like that generated resource file for the images and strings, I must say, I find this a very convoluted way of getting an association between a serialized view and an activity. If this were iOS and you wanted to get a view in your view controller, you could just directly map over a reference. But this isn’t so bad. Now that we have the buttons, it’s time to give them behaviors by setting their on click listeners:

this.mTrueButton.setOnClickListener(new View.OnClickListener() {
    @Override
    public void onClick(View v) {
        Toast.makeText(QuizActivity.this,
                R.string.correct_toast_text,
                Toast.LENGTH_SHORT).show();
    }
});

this.mFalseButton.setOnClickListener(new View.OnClickListener() {
    @Override
    public void onClick(View v) {
        Toast.makeText(QuizActivity.this,
                R.string.incorrect_toast_text,
                Toast.LENGTH_SHORT).show();
    }
});

Note that the on click listeners are a property on the button which you define the behavior of by creating an anonymous inner class. This is a cool way of getting block-like behavior and syntax out of Java. Also, a “toast” is an Android UI element which shows up briefly towards the bottom of the screen and contains some text.

To perform this same operation on iOS, open up your storyboard and view controller side-by-side by Alt-clicking in Xcode. Then, control-click-and-drag from the UI element you want a reference to from the storyboard into the view controller file, and select that you want an IBAction, which is like an on-click listener. You can make one for each button, or if you want to get clever you can make multiple buttons to the same IBAction and determine what to do at runtime. While iOS has no native notion of toast, I’ve hacked together one using UIAlertController and Grand Central Dispatch for sake of parity.

class ViewController: UIViewController {
    @IBAction func buttonTouchUpInside(sender: AnyObject) {
        guard let sender = sender as? UIButton else { return }
        let title = sender.titleLabel?.text == "True" ? "Correct!" : "Incorrect!"
        let alert = UIAlertController(title: title, message: "", preferredStyle: .Alert)
        self.presentViewController(alert, animated: true) { () -> Void in
            let delayTime = dispatch_time(DISPATCH_TIME_NOW, Int64(1 * Double(NSEC_PER_SEC)))
            dispatch_after(delayTime, dispatch_get_main_queue()) {
                alert.dismissViewControllerAnimated(true, completion: nil)
            }
        }
    }
}

This code conditionally unwraps the sender into a button, and if it is a button, checks to see if it’s title is “True” to build the “Correct!” or “Incorrect!” text to display to the user. To do this, it uses a UIAlertController with that title, presents it, and when presentation is complete it waits 1 send to subsequently dismiss this alert controller.

Swift is truly magnificent. That code block above is not a snippet, that’s the whole view controller. In Android and Java and an Activity, the whole thing becomes quite long and nested fairly quickly. It does seems that if you’re going to use anonymous inner classes and getting views by IDs, however, you have to place it in a non-top-level function somewhere.

This is just a very thin top-to-bottom slice of the development for both Android and iOS. Admittedly, I prefer iOS development on account of its new language Swift and less cumbersome SDK, but this comes at the cost of not supporting older platforms and less ubiquitous third party libraries and community discussion (which Java has plenty of). Although perhaps soon they’ll be the best of both worlds, as it was recently proposed that Swift should get Android support!