From iOS to Android – Part I
Exploring Android concepts as an iOS developer
22nd March 2018Getting started
Up until recently, I had mostly focussed on iOS development, despite owning an Android phone for the last three years. It took a reasonable amount of time for me to become comfortable with the language and frameworks used during iOS development, but once I was there it seemed like a good time to learn some new skills and broaden my horizons. The time was finally upon me to temporarily leave iOS & Swift behind and delve into the daunting world of Android.
Why Kotlin & general syntax
The first of many important choices to make was which language to learn. The realistic choices available to me were Java (a language that’s overly verbose and out of date in my opinion) or Kotlin (a fairly new language with modern features and concise syntax). A lot of my favourite features from Swift were not available in Java, however Kotlin offered a set of features I was already familiar with, alongside a selection of intriguing new concepts that appealed to me. The fact that Android had recently announced Kotlin as an official language was the icing on the cake, so I made the decision to learn and use Kotlin.
One of the concepts I found most useful in Swift was optionals, an explicit way of stating whether it’s possible for a particular variable to be null. Kotlin also has optionals, helping to avoid the famous NullPointerExceptions from Java. Optional syntax is similar between Swift and Kotlin, both using ‘?’ after the type of the variable to refer to a standard optional. Swift uses ‘!’ to force unwrap an optional value, while Kotlin uses ‘!!’. There is a small difference in syntax when it comes to unwrapping an optional with a default value. Swift uses the nil-coalescing operator ‘??’, while Kotlin uses the Elvis operator ‘?:’, however both are used in the same way so it wasn’t difficult adjusting to Kotlin.
Anonymous functions
Another concept in common between Kotlin and Swift is anonymous functions, for passing blocks of functionality around your code. In Kotlin they’re called Lambdas while in Swift they’re called closures, although they are essentially the same thing. Lambdas have many uses, such as passing a callback to an asynchronous function or a reusable block to a high-order function.
Syntactically, anonymous functions are similar in both languages, with the type being defined as
(ParamType) -> ReturnType. The anonymous functions themselves are both defined using curly brackets with only a minor difference in parameter types. Swift uses‘in’like so:{ x, y in print(x + y) }while Kotlin uses an arrow:{ x, y -> print(x + y) }. Swift allows you to skip naming the parameters and refer to them as$0, $1,etc… Kotlin allows you to skip naming the parameters only if you are inside a lambda with a single parameter, in which case you can refer to it as‘it’, however multiple parameters require explicit naming.-
Subclasses
Java suffers from the lack of an ability to add functionality to an existing class without creating unnecessary subclasses.
Both Kotlin and Swift provide a way around this problem by allowing extension of existing types and classes. This can be a neat way to wrap reusable functionality inside functions that can be called directly on the relevant classes, rather than relying on utility classes that complicate syntax and pollute the global namespace.
Swift allows you to conform to new protocols in an extension which can be very useful, however this feature isn’t available in Kotlin due to the limitations of the JVM. Swift places extension functions inside a specific extension block using the form
‘extension MyClass: OptionalProtocolName { }while Kotlin requires the name of the class you are extending before every function name, for example‘fun MyClass.newFunction() { }’.-
Custom delegates & other features
Several Swift language features such as lazy properties and property observers haven been combined into delegated properties in Kotlin. This allows common kinds of properties to be implemented using built in delegates taking responsibility for getting/setting properties, and it also allows custom delegates for special types of properties you may need. Behind the scenes, delegated properties generate a private field containing an instance of the given delegate object, then call getValue(…) and setValue(…) methods on that object from automatically generated property getter and setter methods.
Overall there are a lot of similar concepts between Swift and Kotlin, hence my initial interest in learning Kotlin instead of using Java. Some of the syntax varies slightly in places, but never in a way that’s hard to adjust to. Obviously there are a lot of great parts of both Swift and Kotlin that I haven’t had a chance to mention in this article, and I’m sure there are still things in both languages that I’m yet to discover, however these are some of the parts I’ve found most interesting so far.