This article describes my experience writing a Kotlin compiler plugin. My primary goal was to create a Kotlin compiler plugin for iOS (Kotlin/Native) similar to Android’s kotlin-parcelize. The outcome is the new kotlin-parcelize-darwin plugin.
Even though the main focus of this article is iOS, let’s take a step back and revisit exactly what
Parcelable and the
kotlin-parcelize compiler plugin are, in Android.
The Parcelable interface allows us to serialise an implementing class to the Parcel so it can be represented as a byte array. It also allows us to deserialise the class from the
Parcel so that all the data…
In my last article “Decompose — experiments with Kotlin Multiplatform lifecycle-aware components and navigation”, I mentioned two cases when we can’t share code using Kotlin Multiplatform. The first one was navigation and the second one was UI. In that article we managed to share the navigation logic using the Decompose library. But UI was still platform specific.
Good news! Recently JetBrains released its multiplatform implementation of Jetpack Compose, and it is now possible to have a shared UI. Basically, the multiplatform Compose can now be used on both Android and JVM. And the latter works on Linux, macOS and Windows.
Kotlin Multiplatform is a technology that enables code sharing between different platforms. It is completely up to developers how much of the code they want to share. But there are cases for which we just can’t write shared code, even if we would like to.
One of the cases is UI. Currently it is not possible to make UI code common. And actually this particular case is totally fine — Kotlin Multiplatform’s intention is to share business logic, not UI.
In this blog post I would like to express my disappointment in the AndroidX FragmentFactory. I will briefly describe what the FragmentFactory is, and why I think it is defective.
I already tried to bring Google’s attention to this problem by opening an issue a year ago. But after quite a long discussion the issue was closed without any reasonable solution to the problem.
The purpose of this blog post is to bring attention of the community.
Historically, fragments are usually created by the FragmentManager automatically. Just like activities are automatically created by the system. Every fragment is expected to…
This is the concluding article in a series of three articles on MVI architectural pattern in Kotlin Multiplatform. In the previous two articles (part 1 and part 2) we reminded ourselves what MVI is, created the Kittens module for loading images of kittens, and integrated it into iOS and Android applications.
In this part, we are going to cover the Kittens module with unit and integration tests. We will learn about the current limitations of testing in Kotlin Multiplatform, how to overcome them and even make them work to our advantage.
The updated sample project is available in our GitHub:
This is the second in a series of three articles on MVI architectural pattern in Kotlin Multiplatform. In the article part 1 we reminded ourselves what MVI is and learned how to use it to write shared code using MVI. We defined simple abstractions like Store and View as well as some helper classes and used them to create a shared module. This module’s job is to load lists of image URLs from the network and to wire the business logic with UI. The UI is represented as an interface and is to be implemented natively in every platform. …
About a year ago I became interested in some new technology: Kotlin Multiplatform. Since then I have been actively experimenting in this area and promoting this technology within our company. One outcome, for example, is our Reaktive library — Reactive extensions for Kotlin Multiplatform.
At Bumble — the parent company operating Badoo and Bumble apps — for Android development, we use the MVI architectural pattern (read more about our architecture Zsolt Kocsi’s article: “MVI beyond state reducers”). Thanks to different projects that…
Reactive programming is really popular today not least because it has loads of plus points: the absence of what is called ‘callback hell’; a built-in mechanism for processing errors; and a functional programming style that reduces the likelihood of bugs occurring. It makes it much easier to write multi-threaded code as well as easier to manage (combine, split and transform) data streams.
But what is there for Kotlin? Logically, it would be RxKotlin. And this library does in…