T-shaping is a perfect way of improving your skills as a professional developer. With T-shaping, you become a more valuable specialist. In essence, understanding different technologies inspires you in solving your regular tasks. Your t-shaped skills reduce bus-factor in cross-functional teams, and finally, you understand your сolleagues better because you speak the same language.
In this article, I will show you how to effectively T-shape your mobile skills and do both iOS and Android applications. Why effectively? Because we will not only write code for two platforms but also will reuse a big part of code by using Kotlin Mobile Multiplatform. We will write two apps with beautiful native UI and common business logic layer and spend only 4 hours. Let's go!
😅Hint: Start to download Android studio right now! Multithreading rocks!
I assume you have heard something about Kotlin while playing kicker in your office. So before we start, we have to get a quick look at the core of our future technical stack — Kotlin Multiplatform (KMP).
KMP is a feature of Kotlin which shares code between an app's various platforms. Kotlin compiles sources to different targets which allows it to be compiled as different outputs for each platform. In our project, we will use Kotlin/Native output binaries for iOS and Kotlin/JVM output JAR for Android.
One of the most important features is expect/actual mechanism. It allows you to use platform-specific (actual) types and functions, but write generic algorithms which will use declarations of these functions (expect). With this mechanism, you easily use the template method pattern, which could be very useful when writing a cross-platform business logic code.
<aside> ⌛ Spent time: 15 min. Total: 15 min
</aside>
The practice is the best way to learn, so instead of digging into hundreds of articles, let's try KMP in action!
The best way to do it is to complete official interactive hands-on. As a result, you will have:
Not bad for less when 1 hour of work!
<aside> ⌛ Spent time: 30 min. Total: 45 min
</aside>
The percent of code you reuse depends on the architecture of your App. I'm a real fun of using Data-Driven architecture in iOS, where we separate view controller from any dependencies and provide only needed data to represent any possible UI state. The presenter is responsible for preparing state and doesn't depend on any platform UI libs. With architecture like that, you can reuse not only data and domain layers but also a part of the presentation layer!
In our first cross-platform app with simple presentation logic, we will reuse only data and domain layers. We need a service which will store information about available types of gifs and will be able to return list of gifs by making API calls to Giphy.com, parse data and combining result.
<aside> ⌛ Spent time: 15 min. Total: 1 hour
</aside>