Author: Huang Linqing
Many developers may not know Compose Multiplatform and KMM, so this sharing will introduce Compose Multiplatform and KMM through the following points, let us experience the charm of Kotlin cross-platform.
- The relationship between Compose Multiplatform and KMM
- Practice of Compose Multiplatform and KMM
- How should developers choose
What needs to be explained here is that this sharing will only be shared from the perspective of use. As a popularization of cross-platform technology, it will not involve the underlying principles of cross-platform, such as why it can be cross-platform. Why not talk about these? The reason is very complicated. Simply put, I don't know how to do it.
The relationship between Compose Multiplatform and KMM
To understand the relationship between Compose Multiplatform and KMM, we only need to understand what Compose Multiplatform and KMM are.
What is KMM
The full name of KMM is Kotlin Multiplatform Mobile, which corresponds to KMP—Kotlin Multiplatform Project, which is actually a collection of Kotlin mobile cross-platform and Kotlin cross-platform projects. KMM is more like a marketing term. We don’t need to worry about the word Mobile. What you need to know is that the KMM we are talking about below refers to Kotlin cross-platform and not limited to mobile terminals.
KMM can simplify the development of multi-platform applications. Through KMM, developers can share common code of business logic between iOS, Android, Desktop and Web applications, and can also write platform-specific code when necessary. Therefore, KMM is only responsible for the business logic part under cross-platform.
For example, the data layer and network domain layer in this picture can use KMM to complete public business logic.
When KMM was launched in the early days, Compose Multiplatform had not been released at that time, so everyone felt that KMM was tasteless, because 90% of developers believed that the main work of the mobile terminal was writing UI, and what kind of cross platform could not be called cross platform? platform?
However, this view is actually incorrect. It is still very beneficial to use KMM for many business logics such as log systems and buried points.
Later, the emergence of Compose Multiplatform made up for the shortcomings of KMM. So what is Compose Multiplatform?
What is Compose Multiplatform
Jetpack Compose is a declarative UI framework officially launched by Android. Compose Multiplatform is a Compose cross-platform framework maintained by JetBrains. It focuses on UI cross-platform and also supports iOS, Android, Web, Desktop, etc.
With Compose cross-platform, it makes up for the shortcomings of KMM.
I always feel that there is an embarrassing question that Compose Multiplatform and KMM are not the same thing. They are indeed not the same thing. After all, the version updates and maintainers are different. But after all, Kotlin's underlying support for Native and JS is the basis of Compose Multiplatform. So I hope that one day they can be merged, and both version updates and plug-in support can be unified. So I prefer to call them Kotlin full platform directly.
Well, in fact, you now know the relationship between KMM and Compose Multiplatform. Next, let's look at how Compose Multiplatform and KMM are implemented.
Practice of Compose Multiplatform and KMM
Since Compose Multiplatform and KMM have a reused UI and a reused business logic, let's see how to practice it separately.
Practice KMM
KMM is used to implement the business logic part. Here we only take Android and iOS as examples. Here I want to reiterate again that Compose Multiplatform and KMM can be used independently, that is to say, when using KMM, you can write the native UI of Android and iOS respectively, and when using Compose Multiplatform cross-platform, you can also realize the business of other terminals respectively. logic.
create project
In Android Studio, we can use the Kotlin Multiplatform Mobile plugin to quickly create projects that support KMM.
After installing the plug-in, open Android Studio and we can directly create a project that supports KMM.
When creating, we will fill in the information of the module
After the project is created, the generated project directory structure looks like this.
androidApp and iOSApp are the corresponding code libraries of Android and iOS, and the shared module is the part that stores the common business logic of Android and iOS.
The KMM plugin only creates Android and iOS source sets for us. If you want to create other platforms, you can create folders yourself and specify the target platform.
After creating the project, let's see how to deal with public business logic.
common business logic
We can directly put the logic that both ends can share in the commonMain folder. The dependencies of the open source library are written in the commonMain directory.
Add the network request library Ktor and the serialization dependency here, because it is Kotlin cross-platform, Ktor is a network request library launched by Kotlin, so it is definitely the best choice to use Ktor.
This piece of code is the basic usage of Ktor, the network request framework. We will not explain too much. Here we define a getData method to get the "Daily Question" in the "Wandroid" of "Hongyang" boss. data".
Then we each write Android or iOS UI code to receive data. Here we directly display the return display in the text, and the final implemented program looks like this.
We will implement this UI later in Compose Multiplatform. In this way, we have realized an example of a simple data request for dual platforms.
Community support for KMM
At present, many official libraries already support cross-platform, such as the network request framework Ktor we just used, dependency injection Koin, and serialization components.
In addition, the most friendly news for Android development is that Jetpack has also started to support cross-platform since October last year, but currently there are only three cross-platform components supported by Jetpack: Annotations, Collections, and DataStore.
Of course, some well-known apps also open source some components, such as Cash App open source Paging paging library.
Like the Paging design under AndroidX, the paging-common module provides the storage layer and the view model layer; the paging-runtim module provides the UI layer.
The most important thing is that the API in paging-common is exactly the same as the API under AndroidX. It just migrates the package from androidx.paging to app.cash.paging, so we use this part directly according to the Paging in AndroidX. Can.
But in actual projects, relying on community support alone may not be able to satisfy all businesses. Of course, some open source contributors have open sourced some components, but in order to ensure stability, we generally need to implement our own business logic independently, so how do we ensure that we use the same set of APIs?
expect与actual
We rely on the expect and actual keywords in Kotlin. Expect is the way we expect to achieve, and actual is the way to achieve it, which is a bit similar to interface and implementation class. For example, we now want to implement business logic: turn on the system Bluetooth.
First we need to define this interface using expect in commonMain
Then we realize the method of turning on Bluetooth in the androidMain and iOSMain directories under the shares module.
In this way, we ensure that the same API is used to call on multiple platforms, and the caller does not need to pay attention to the specific implementation. So here, we know about KMM. From the above understanding, we can see that KMM can be used in actual projects at present, but we can wait. Kotlin's RoadMap says that the official version will be released this year. We can look forward to it together. Next, let's practice Compose Multiplatform together.
Practice Compose Multiplatform
Compose Multiplatform focuses on UI reuse. As we mentioned earlier, there is an embarrassing problem that the versions and plug-ins of KMM and Compose Multiplatform are not unified. We can quickly create a KMM project in Android Studio with the help of the KMM plug-in, but currently if we want to quickly create a Compose Multiplatform project, we can only use the new version of IDEA.
create project
Download the latest version of IDEA and create a Compose Multiplatform project, but what is even more embarrassing is that IDEA cannot create projects for the iOS platform because iOS is still in the alpha stage.
So if we want to use the Kotlin full platform, there are two ways:
- Use IDEA to create a project and add KMM dependency configuration
- Use Android Studio to create a project and add Compose Multiplatform configuration
- Use the official template project
Here, based on the KMM project I just created, I add the configuration of Compose Multiplatform on the basis of KMM.
After the project is configured, we just query the function of the daily question to realize it. Of course, we must have stepped on a lot of pitfalls during the configuration. I have recorded all of these in my blog.
Realize double-ended network data display
The code in iOSApp.swift looks like this.
Main_iosKt.MainViewController is obtained by creating the main.ios.kt file in the iOSMain directory of the shared module. The code is as follows:
Therefore, we can write the Compose method for parsing network data and implementing it in the commain directory of the shared module, and then call it under Application.
Everyone can understand this code, and it is completely consistent with Jetpack Compose. The data is displayed through the Message method. Here, only the author and the title are displayed. The code is as follows:
Then we can run Android and iOS programs in this way. It should be noted here that we can run iOS programs directly with the KMM plug-in, but there is a prerequisite that Xcode is still installed. The effects of Android and iOS are shown in the figure below.
We can see that the page effect is completely consistent, and as far as this function in the page is concerned, 100% reuse of business logic and UI has been achieved. How about it is Thai cool!
Desktop and Web
We used Android and iOS as examples above. In fact, Desktop and Web are the same. In comparison, I think Desktop is relatively mature, and the UI can also fully reuse Jetpack Compose. I realized the effects of Desktop and Web respectively on this example.
Here is a little more about the Web. In the early days, Compose for Web was implemented using Compose HTML. Compose HTML is a Kotlin/JS-oriented library that provides Composable components for creating web user interfaces with HTML and CSS. So The fragmentation problem is very serious. It cannot be said that it cannot be reused with Jetpack Compose, but it has nothing to do with it.
For example, the data in our implementation diagram shows that Compose HTML is written like this. At that time, it was quite a collapse to see this. Fortunately, Kotlin launched Kotlin/Wasm in version 1.8.20. The latest Compose for Web is based on Kotlin/Wasm and is currently in the experimental stage. The page can be completely reused with Jetpack Compose, so please pay attention to the writing method of Compose HTML and stop learning.
The official website provides some templates for Compose Multiplatform, as well as templates for Kotlin/Wasm, but there is no template for Compose Wasm for Web. Therefore, I open source a template on github, and everyone who is interested can use it.
Like the component issue just mentioned, with the maturity of Compose Multiplatform technology, sooner or later the official will launch a new plug-in to support both KMM and Compose Multiplatform.
Interoperability with native UI
When using Jetpack Compose to develop Android, in some scenarios we may need to use Jetpack Compose and XML nested, then this kind of scenario will definitely exist in cross-platform, in iOS, you can use UIKitView in the shared user interface Embed complex platform-specific widgets such as maps, web views, media players, cameras, and more.
In short, these are certainly not factors that hinder the cross-platform development of Compose Multiplatform.
How should developers choose
At present, the main force of cross-platform competition with Compose should be Flutter. Many people always like to compare them. Now the comparison is definitely that Compose Multiplatform is definitely not as good as Flutter, but this comparison is a bit bullying Compose Multiplatform. After all, Compose Multiplatform is still very young.
Of course this is a very open topic, I just express my personal opinion. Flutter will always have language barriers, but KMM and Compose Multiplatform are almost a giveaway for Android developers. Of course, there are two groups of people who may hinder their use of KMM and Compose Multiplatform.
- Haven't used Jetpack Compose
For those who have never used Jetpack Compose, I can fully understand that it may take some time to support some components, such as maps and WebViews. After all, it is no problem to use XML now. There are still some people who have never experienced Kotlin.
- Haven't used Kotlin
Excluding those who are engaged in Farmework or the lower level, in fact, I have no way to understand it or even feel a little speechless. The reasons many people told me are that Java can also be used, the boss does not allow it to be used, and the company's projects are outdated. In fact, these are all excuses now.
Already using Kotlin, I suggest learning Jetpack Compose, firstly, this is a trend, and secondly, it will expand your cross-platform skills. If you want to still be engaged in Android development in the next few years, I see no reason to say no.
If you have a small partner who is not very good at Jetpack Compose, you can refer to "Jetpack Compose Family Bucket Notes" :https://qr18.cn/A0gajp