Image for post
Image for post

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.

Since both navigation and UI can now be shared, we can create almost cross-platform applications. Why almost? Because some parts may still require platform-specific API. …


Image for post
Image for post

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.

Another case is navigation. We can implement all the business logic in common and add platform specific UI. But navigation between screens has to be also implemented separately in each platform. E.g. in Android we can use Badoo/RIBs framework or AndroidX Fragments. …


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.

History

Historically, fragments are usually created by the FragmentManager automatically. Just like activities are automatically created by the system. Every fragment is expected to have a constructor without arguments. Once a fragment is added to the FragmentManager, the latter takes care of recreating the fragment after configuration changes and/or process death. …


Image for post
Image for post

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:

Prologue

There is no doubt that testing is important. Of course, testing adds friction to the development of the functionality itself. …


Image for post
Image for post

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. …


Image for post
Image for post

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.

The story continues here:
MVI in Kotlin Multiplatform — Part 2
MVI in Kotlin Multiplatform — Part 3

At Badoo and Bumble, 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 I have been working on I have become a big fan of this approach. Of course, I could not miss my opportunity to try MVI in Kotlin Multiplatform. …


Image for post
Image for post

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.

Lots of programming languages have their own reactive library: RxJava for JVM, RxJS for JavaScript, RxSwift for iOS, Rx.NET and so on.

But what is there for Kotlin? Logically, it would be RxKotlin. And this library does in fact exist. However, it is little more than a set of extensions for RxJava2, i.e. …

About

Arkadii Ivanov

Android Engineer @ Badoo

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store