In this article we look into Android from an iOS development point of view.
Recently I’ve started an experiment: I bought an Android Phone – the Nexus 5X. Why have I done that? Well, as I said before, on the one hand specialisation is very important, but on the other hand it’s also very important to think outside the box form time to time. So even if you want to specialise in a specific platform – like iOS for example – it has great benefits to look into other platforms that are on the one hand similar but on the other hand are also quite different. And that’s definitely the case with Android.
Android is a very successful operating system. In fact in the last two years more Android devices have been sold than Windows, iOS and Mac OS devices combined.
Android is based on Linux and it’s open source. That has both advantages and disadvantages. On the one hand every company has the possibility to customise Android, but on the other hand there’s also a very high fragmentation. For an iOS app it’s most of the times sufficient to support the last two iOS versions, but an Android App have to support much older Android versions. And there are also much more devices the app could be executed on. In my opinion, the major difficulty in developing Android apps is the support of so many devices and operating system versions.
Like on iOS, Android apps are running in its own sandbox. The apps are even running in their own virtual machines, so that this is basically a very secure concept. However, an app can request a lot of permissions, like using the camera, accessing the contacts or sending short messages. Permissions used to be given all together at install time and it wasn’t possible for the user to allow just some permissions. This has changed with the introduction of Android Marshmallow. Now it works as on iOS: Permissions are requested at runtime when they are needed. It’s also possible now to re a single permission request and the app has to react to this appropriately.
Android apps are not as extensive reviewed as iOS apps. Although that means that an app can be published quicker and easier than on iOS, this is a big disadvantage for the whole platform. In the Android Play Store there are much more low quality apps than on the Apple App Store. And, there are also a lot of apps that could to bad things. For example, there are a lot of flashlight apps in the Play Store that request many permission they shouldn’t need like accessing the contacts.
The first stable version of Android Studio was released in December 2014 and since then it has become the primary Android IDE. It’s based on IntelliJ and I’m quiet honest in this regard: Android Studio is in many aspects just better than Xcode. For example, it has much better refactoring tools and a better code completion. There are also many iOS developers who use AppCode, which is also based on IntelliJ.
You can download Android Studio here. You also need the Java development kit. Then, it’s very straightforward to create am Android Emulators and to deploy the app on a real device. And you don’t have to care about provisioning profiles and certificates. Don’t get me wrong: There are good reasons that there are provisioning profiles and certificates on the iOS platform. But it’s also very complicated so that it’s easier to start developing for Android.
Java is the primary programming language for developing Android apps. It’s also possible to use C and C++, but this is just intended for using the native development kit, which is just reasonable for certain situations.
Besides that, Java has much more in common with Swift than with Objective-C. Java is a very modern and a very good programming language, even though Swift is of course better. 😉
Activities and Fragments
Although they are a little bit overused most of the times, view controllers are one of the most important components in iOS development. On Android, there are two corresponding components: Activities and Fragments. Activities are like view controllers that control a full screen view. Fragments on the other hand are like Activities, but they are also allowed to control views that are not full screen. So if you have a master and a detail view you can use fragments to display them fullscreen on the phone, and side by side on the tablet. A fragment always belongs to an Activity and an Activity can have several Fragments.
Layouts are defined in XML files. This is a huge difference to the iOS way. iOS layouts used to be very easy to define due to the very few screen sizes in the iOS eco system. This has changed though. Now there are three phone sizes and two tablet sizes. Auto layout and size classes work very good if you have understood them completely. But it’s also a very complicated system. I think that’s the main reason for the introduction of stack views. Stack views are basically the same concept as the so-called linear layouts in Android. There are even more layouts in Android and I think this concept is much easier to understand. As I’ve said before, I can imagine that Apple will invent a complete new layout system that is much more like the Android way.
The Android way is far away from being perfect though. But when it comes to supporting a lot of different screen sizes, it is better than the iOS approach in my opinion.
When it comes to multitasking and background processes, iOS is very restricted. And there’s a very good reason for that: Resources are very limited on a phone so that it could be bad if a process is running on the background all the time. But on the other hand the iOS way also has its downsides because some tasks are difficult to achieve on iOS.
Android is less restrictive and it has a component that can run in the background: a so-called service. It even runs if the app is not in the foreground so that you have the possibility to perform some long running tasks in the background. This concept is a little bit unfamiliar for iOS developers, but as I said before, both concepts have their pros and cons.
[thrive_text_block color=”blue” headline=”Conclusion”]Android has become a very good operating system so that it has a lot of benefits for iOS developers to look into Android development as well. Some concept are similar to iOS, but other concepts are very different. It can be a welcome change to look into that other world. [/thrive_text_block]
Title image: NesaCera / shutterstock.com