著者: 黄林青

多くの開発者は Compose Multiplatform と KMM を知らない可能性があるため、この共有では次の点で Compose Multiplatform と KMM を紹介し、Kotlin クロスプラットフォームの魅力を体験してみましょう。

Compose Multiplatform と KMM の関係
Compose MultiplatformとKMMの実践
開発者はどのように選択すべきか

ここで説明する必要があるのは、この共有は使用の観点からのみ共有されるものであり、クロスプラットフォーム技術の普及としては、なぜクロスプラットフォームであるのかといった、クロスプラットフォームの基礎となる原理には関与しないということです。。これらについて話してみてはいかがでしょうか? 理由は非常に複雑で、簡単に言うとやり方が分からないのです。

Compose Multiplatform と KMM の関係

Compose Multiplatform と KMM の関係を理解するには、Compose Multiplatform と KMM が何であるかを理解することだけが必要です。

KMMとは

KMM の正式名は Kotlin Multiplatform Mobile で、KMP (Kotlin Multiplatform Project) に対応します。これは、実際には Kotlin モバイルクロスプラットフォームプロジェクトと Kotlin クロスプラットフォームプロジェクトのコレクションです。KMM はマーケティング用語に近いです。モバイルという言葉について心配する必要はありません。知っておく必要があるのは、以下で説明する KMM は Kotlin クロスプラットフォームを指しており、モバイル端末に限定されないということです。

KMM を使用すると、マルチプラットフォームアプリケーションの開発を簡素化できます。KMM を通じて、開発者は iOS、Android、デスクトップ、Web アプリケーション間でビジネスロジックの共通コードを共有でき、必要に応じてプラットフォーム固有のコードを作成することもできます。したがって、KMM はクロスプラットフォームでのビジネスロジック部分のみを担当します。

たとえば、この図のデータ層とネットワークドメイン層は、KMM を使用してパブリックビジネスロジックを完成できます。

KMM が立ち上げられた初期の頃は、Compose Multiplatform がまだリリースされていなかったため、開発者の 90% がモバイル端末の主な仕事は UI を書くことだと信じていたため、当時は Compose Multiplatform がリリースされていなかったため、誰もが KMM は味気ないと感じていました。プラットフォームはクロスプラットフォームとは言えませんか?プラットフォーム?

しかし、この見方は実際には誤りであり、ログシステムや埋め込みポイントなどの多くのビジネスロジックに KMM を使用することは依然として非常に有益です。

その後、Compose Multiplatform の登場により、KMM の欠点が補われました。では、Compose マルチプラットフォームとは何でしょうか?

Compose マルチプラットフォームとは

Jetpack Compose は、Android によって正式に開始された宣言型 UI フレームワークです。Compose Multiplatform は、JetBrains によって維持されている Compose クロスプラットフォームフレームワークです。UI クロスプラットフォームに焦点を当てており、iOS、Android、Web、デスクトップなどもサポートしています。

Compose クロスプラットフォームを使用すると、KMM の欠点が補われます。

Compose Multiplatform と KMM は同じものではないのではないかという恥ずかしい疑問が常にあると感じていますが、確かに同じものではありません。結局のところ、バージョンの更新とメンテナーは異なります。しかし結局のところ、Kotlin の Native と JS の根本的なサポートが Compose Multiplatform の基礎となっています。したがって、いつかそれらが統合され、バージョン更新とプラグインのサポートが統合されることを願っています。したがって、私はこれらを Kotlin フルプラットフォームと直接呼ぶことを好みます。

実際、KMM と Compose Multiplatform の関係はもうわかりました。次に、Compose Multiplatform と KMM がどのように実装されるかを見てみましょう。

Compose MultiplatformとKMMの実践

Compose Multiplatform と KMM には再利用された UI と再利用されたビジネスロジックがあるため、それを個別に実践する方法を見てみましょう。

KMMの練習

KMM はビジネスロジック部分の実装に使用されますが、ここでは Android と iOS のみを例に挙げます。ここで、Compose Multiplatform と KMM は独立して使用できることをもう一度繰り返しておきます。つまり、KMM を使用すると、Android と iOS のネイティブ UI をそれぞれ作成でき、Compose Multiplatform をクロスプラットフォームで使用すると、次のことも実現できます。他の端末の業務をそれぞれロジックで処理します。

プロジェクトを作成する

Android Studio では、Kotlin Multiplatform Mobile プラグインを使用して、KMM をサポートするプロジェクトを迅速に作成できます。

プラグインをインストールした後、Android Studio を開くと、KMM をサポートするプロジェクトを直接作成できます。

作成時にモジュールの情報を記入していきます

プロジェクトが作成されると、生成されたプロジェクトのディレクトリ構造は次のようになります。

androidAppとiOSAppはAndroidとiOSの対応するコードライブラリで、共有モジュールはAndroidとiOSの共通のビジネスロジックを格納する部分です。

KMM プラグインは Android と iOS のソースセットのみを作成します。他のプラットフォームを作成したい場合は、自分でフォルダーを作成し、ターゲットプラットフォームを指定できます。

プロジェクトを作成した後、パブリックビジネスロジックを処理する方法を見てみましょう。

一般的なビジネスロジック

両端が共有できるロジックを commonMain フォルダーに直接置くことができます。オープンソースライブラリの依存関係は commonMain ディレクトリに書き込まれます。

ここにネットワークリクエストライブラリ Ktor とシリアル化の依存関係を追加します。Kotlin クロスプラットフォームであるため、Ktor は Kotlin によって起動されるネットワークリクエストライブラリであるため、Ktor を使用することが間違いなく最良の選択です。

このコードは、ネットワークリクエストフレームワークである Ktor の基本的な使い方です。説明は省略します。ここでは、「Hongyang」ボスの「Wandroid」にある「Daily Question」を取得する getData メソッドを定義します。data」

次に、データを受信するために Android または iOS の UI コードをそれぞれ記述します。ここではリターン表示をテキスト内に直接表示しており、最終的に実装されたプログラムはこんな感じです。

この UI は、後で Compose Multiplatform に実装します。このようにして、デュアルプラットフォーム向けの単純なデータリクエストの例を実現しました。

KMM のコミュニティサポート

現在、先ほど使用したネットワークリクエストフレームワーク Ktor、依存関係注入 Koin、シリアル化コンポーネントなど、多くの公式ライブラリがすでにクロスプラットフォームをサポートしています。

さらに、Android 開発にとって最も嬉しいニュースは、Jetpack も昨年 10 月からクロスプラットフォームのサポートを開始していることですが、現在 Jetpack でサポートされているクロスプラットフォームコンポーネントは Annotations、Collections、DataStore の 3 つだけです。

もちろん、一部の有名なアプリでは、Cash App オープンソースの Paging ページングライブラリなど、一部のコンポーネントもオープンソース化しています。

AndroidX でのページング設計と同様に、paging-common モジュールはストレージ層とビューモデル層を提供し、paging-runtim モジュールは UI 層を提供します。

最も重要なことは、paging-common の API は AndroidX の API とまったく同じであり、パッケージが androidx.paging から app.cash.paging に移行されるだけであるため、AndroidX の Paging に従ってこの部分を直接使用することです。 . できます。

しかし、実際のプロジェクトでは、コミュニティのサポートだけに依存するだけではすべての企業を満足させることができない可能性があります。もちろん、一部のオープンソース貢献者は一部のコンポーネントをオープンソース化していますが、安定性を確保するには、通常、独自のビジネスロジックを個別に実装する必要があるため、同じ API セットを確実に使用するにはどうすればよいでしょうか?

期待と実際

Kotlin の Expect キーワードとactual キーワードに依存しています。Expect は達成を期待する方法であり、actual はそれを達成する方法であり、インターフェースと実装クラスに少し似ています。たとえば、システムの Bluetooth をオンにするというビジネスロジックを実装したいとします。

まず、commonMain の Expect を使用してこのインターフェイスを定義する必要があります

次に、shares モジュールの下の androidMain ディレクトリと iOSMain ディレクトリで Bluetooth をオンにする方法を実現します。

このようにして、複数のプラットフォームでの呼び出しに同じ API が使用されるようになり、呼び出し元は特定の実装に注意を払う必要がなくなります。ここで、KMM について説明しました。上記の理解から、KMM は現時点では実際のプロジェクトで使用できることがわかりますが、待つことはできます。Kotlin のロードマップには、正式バージョンが今年リリースされる予定であると記載されています。期待できます。それを一緒に。次に、Compose Multiplatform を一緒に練習しましょう。

マルチプラットフォームの作成を練習する

Compose Multiplatform は UI の再利用に重点を置いていますが、前述したように、KMM と Compose Multiplatform のバージョンとプラグインが統一されていないという厄介な問題があります。KMM プラグインを使用すると、Android Studio で KMM プロジェクトを迅速に作成できますが、現時点では、Compose Multiplatform プロジェクトを迅速に作成したい場合は、新しいバージョンの IDEA のみを使用できます。