uikitの例が、Kotlin Native
プロジェクトの masterブランチに登場しました。 これは、入力フィールドに入力された行を表示する単純なiOSアプリケーションです。はい、コードの100％はKotlinで記述されています。 次のようになります。
今、アプリケーションの移植について考えるべきですか？
はい、ただし次の場合のみ：
0）。 モバイルアプリには共通のコードベースが本当に必要です。
1）。 アプリケーションはプラットフォームにほとんど結びついていません。
2）。 将来的にはObjective-CまたはSwiftで書き直すべきいくつかのKotlinコードを書く時間があります。
まだ移植しない理由
ViewController、AppDelegate、およびこの例のメイン関数でさえ、Kotlinで記述されています。 Objective-Cで記述されたファイルは、Xcodeがエラーを出さず、最終アセンブリに含まれないようにするためにのみ必要です（状況を修正する方法が見つかりませんでした）。 すなわち Javaのような本格的な相互運用は、まだ利用できないようです。 これは、リリースの状況が変わらないことを意味するものではありません（現在、プロジェクトはアルファプレビュー段階にあり、この例に関する
ブログ投稿さえありませんでした）。 しかし、現在利用できるオプションの範囲はかなり限られています。
相互運用
Kotlinでマルチプラットフォームアプリケーションを記述するための慣用的なアプローチは、一般的な部分を別々に、つまり各プラットフォームの部分を別々に記述することです。 さらに、各プラットフォームでは、計画どおり、そのプラットフォーム用に記述されたすべてのライブラリに簡単にアクセスできる必要があります。 Javaの場合、うまく機能します。 iOSの場合、状況は次のとおりです。
@ExportObjCClass class KotlinViewController : UIViewController { constructor(aDecoder: NSCoder) : super(aDecoder) override fun initWithCoder(aDecoder: NSCoder) = initBy(KotlinViewController(aDecoder)) @ObjCOutlet lateinit var label: UILabel @ObjCOutlet lateinit var textField: UITextField @ObjCOutlet lateinit var button: UIButton @ObjCAction fun buttonPressed() { label.text = "Konan says: 'Hello, ${textField.text}!'" } }
それは非常に良いことです。 各外部クラスに対して、ストーリーボードの各グラフィック要素に対して@ExportObjCClass注釈を追加し、各アクションに対して@ObjCOutletおよび@ObjCActionを追加します。 Objective-Cのクラスは、元の名前で利用できます。
Objective-C / SwiftからKotlinを呼び出す必要がある場合
この
記事では、これを行う方法について説明します。 一定数のレイヤーの後、手動で2回タイプ変換しますが、KotlinからSwift、SwiftからKotlinを呼び出すことができます。
オーバーヘッド
理論的には、アプリケーションの重量は約100 kb増加します（
ここから ）。
GCの代わりにARCが使用されるため、Swiftのパフォーマンスに大きな違いはありません。
下位互換性
言語開発チームの参加者の
レポートから判断すると、下位互換性は彼らの主な優先事項の1つです。 判断するのはどれほど良いことか。 個人的には、これはSwiftよりもはるかに優れていると思います。一般的に、言語は優れており、ほとんどの
パズルゲームは大げさに見えます。 しかし、私の意見では、「時限爆弾」になる可能性がありますが、下位互換性で修正することはできません。
インライン
同期コードと非同期コードをほぼ同じに見える
コルーチンを実装するために、言語に導入された新しい一時停止キーワードは1つだけであり、開発者はそれを
誇りに思っています。 ただし、拡張メソッド（
forEach 、map ...）が通常
の （およびプログラム実行中に共通タイプを出力する）のように高速に動作する
ために 、最大 3（
インライン、クロスインライン、noinline ）が導入されました。 それらは明らかにコードを読みやすくしません。 JITは最適化の可能性の一部（
これに関するポッドキャスト ）を失い、Cの経験は、開発者がそのような言語の機能を正しく使用できないことを示しています。 一般に、アノテーションで同じことができない理由はわかりません。 私にとって、インラインはまともな問題の悪い解決策のように見えます。
おわりに
- Kotlinでは、3つの主要なプラットフォームすべて（Android、iOS、Web）向けにすぐに記述できます。
- ほとんどの場合、Objective-CおよびSwiftとの互換性が良好です。 おそらく、これらの言語間の言語よりも優れています。 JetBrainsのコンパイラおよびIDE開発の経験を考えると、これは信じられます。
- Kotlinには、AndroidおよびWeb用の軽量言語ランタイムがあります。 iOSでは、どうやら難しくないでしょう。
- 今すぐ何かを書くことができます。