この記事は Kotlin プロダクト マネージャー、James Ward、デベロッパー リレーションズ エンジニア、Boris Farber による Android Developers Blog の記事 " Kotlin DSL is Now the Default for New Gradle Builds " を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。
Android が Kotlin ファーストになって 4 年が経ち、Kotlin に切り替えることで多くの Android デベロッパーが生産性の向上とアプリの安定化を実現しています。しかし、Gradle には何年も前から Kotlin (build.gradle.kts) のオプションが存在していたにもかかわらず、ビルド定義のデフォルト言語は Groovy (build.gradle) のままでした。
今回、ビルド スクリプトのデフォルト言語が Kotlin に切り替わったことをお知らせします。つまり、Kotlin がすべてのプロジェクトのコードで利用する唯一のデフォルト言語になりました。Jetpack Compose による UI 開発に利用できるのはもちろん、今回よりビルド スクリプトでもデフォルトになります。この改善にあたっては、Gradle と JetBrains のチームと連携して作業を進めてきました。詳しい内容は、関連するお知らせが Gradle ブログ (英語) とJetBrains ブログ (英語) に掲載されています。
この変更は Groovy を使っている既存プロジェクトには影響しません。今後も動作し続け、サポートが終了する予定はありません。ただし、Android Studio Giraffe 以降で新しいプロジェクトやモジュールを作成する場合は、デフォルトで Kotlin DSL が使われます。更新版のプロジェクト テンプレートを使うと、新しい Kotlin DSL のビルド スクリプトを簡単に試してみることができます。既存のビルドを移行したい場合は、Kotlin DSL 移行ガイドをご確認ください。
Kotlin DSL は新規プロジェクトのデフォルトになりますが、既存の Groovy DSL ベースの大規模なプロジェクトについては、Gradle、JetBrains、Google がさらにビルドのパフォーマンスを改善するまで移行を待つようにしてください。この作業は現在も継続中で、進展があり次第、最新情報をお知らせします。具体的には、スクリプトのコンパイル パフォーマンスが Groovy DSL よりも下がっています。ただし、Groovy DSL とは違い、Kotlin DSL スクリプトのコンパイル結果は Gradle のローカルとリモート キャッシュに格納されるので、その後のビルドで再コンパイルの必要はなくなります。
この変更のメリットは、プロジェクトのすべてのコードで 1 つの言語を使えることだけではありません。Gradle ビルドで Kotlin DSL を使うその他のメリットを紹介しましょう。
Kotlin は静的に型付けされるので、Kotlin DSL ビルド スクリプトを編集するときに、正確なコードヒントが瞬時に提供されます。
構文エラーが厳密にチェックされるようになり、プロジェクトの同期時ではなく Kotlin DSL ビルド スクリプトの編集時に表示されます。
Control+Q (macOS では Command+B) を押すことで、型とメソッドのドキュメントを確認できます。さらに詳しい情報を確認したい場合は、Control+クリック (Command+クリック) でソースコードにも移動できます。
1 つのプロジェクトで Groovy DSL ビルド スクリプトと Kotlin DSL ビルド スクリプトを混在させ、モジュールごとに徐々に移行できます。そのため、新規モジュールでは Kotlin DSL を使いつつ、既存モジュールでは Groovy を使い続けることができます。
これに関連して新規プロジェクト テンプレートも変更し、Kotlin DSL ビルド スクリプトで Gradle バージョン カタログ (英語) を使う試験運用版オプションを追加しています。
バージョン カタログを使うと、スケーラブルな形でプロジェクトの依存関係定義を一元管理できます。バージョン カタログの使用は必須ではありませんが、ビルド定義の型安全性が強化されるので、Kotlin DSL と合わせて使うとたいへん便利です。
バージョン カタログへの移行の詳細については、移行ガイド (英語) をご覧ください。
今回導入される Kotlin DSL のデフォルト変更は、Android Studio Giraffe プレビュー版 (英語) で利用できます。ぜひ試してみて、感想をお聞かせください (英語) !
Reviewed by Mari Kawanishi - Developer Marketing Manager, Google Play
この記事は Dan Galpin による Android Developers Blog の記事 " Android Basics and Training Update " を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。
2021 年 10 月、Android Basics in Kotlin (Kotlin による Android の基礎) (英語) の最後のユニットを公開しました。この無料の自習型プログラミング コースで学べば、誰でも Android 開発ができるようになります。このコースでは、プログラミングの経験がない方向けに、Android アプリを開発する方法を説明します。学習を通して、プログラミングの基本や Kotlin プログラミング言語の基礎を習得できます。
私たちは、教育者や学習者からのフィードバックをもとに、コースの教材を見直す作業を続けており、学んだことを応用できるプロジェクトや、さらに高度な教材の足がかりとなる新たなトピックを追加しています。
今回のアップデートにより、現在の Android Basics in Kotlin (Kotlin による Android の基礎) は、Android Kotlin Fundamentals の核となる教材を網羅するようになっています。そのため、後者のコースの提供は終了する予定です。さらに上級の学習者の方にも、本教材に取り組むことをおすすめします。よく知っている内容のセクションはスキップし、直接理解度チェックに挑戦しましょう。重要なコンセプトを見逃す可能性のある中級者や上級者も、成功のために必要なことを本教材から学べます。私たちのチームも、最新のガイダンスをコースに確実に反映する作業に注力できます。あらゆるレベルの学習者に応えるため、コースに加えて、Codelabやコードサンプル、ドキュメントや動画コンテンツの提供も続けます。
私たちは、次のコースとして、Jetpack Compose による Android アプリのプログラミングを説明するコースの準備を進めています。 Android のネイティブ UI 開発用最新ツールキットについて説明できるようになる日が待ち遠しいです。このコースによって、Android の UI 開発のあらゆる側面がシンプルになり、高速になるからです。
現在のコースを受講すると、アプリ開発の基本を学ぶことができます。その経験は、既存の Jetpack Compose の学習パス (英語) を受講する際にも、近日公開の Android Basics with Compose コースを受講するうえでも、絶好のスタート地点となります。Android 開発の世界を探索し続けるうえで、土台となる部分をしっかりと身につけることができます。Android Basics は両方のバージョンが共存する予定で、どちらの UI ツールキットでも Android を学べるようになります。
まだアプリを作ったことはないけれども、その方法を学びたいと思っている皆さん。そして、最新のベスト プラクティスを通じて技術に磨きをかけたい皆さん。ぜひ Android Basics in Kotlin コース (英語) をチェックしてみてください。
この記事は Ting-Yuan Huang による Android Developers Blog の記事 " Accelerated Kotlin build times with Kotlin Symbol Processing 1.0 " を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。
Kotlin で軽量コンパイラ プラグインを作成する新ツール、Kotlin Symbol Processing(KSP)が安定版になりました。KSP は、Kotlin Annotation Processing Tool(KAPT)(英語) と同様の機能を提供しますが、最大 2 倍高速であるうえ、Kotlin 言語の構造に直接アクセスでき、マルチプラットフォーム ターゲットもサポートしています。
ここ数か月間で、KSP は 32 回のリリースを経て、コミュニティから報告された 162 以上のバグを修正しました。導入を見合わせていた方も、ぜひこのタイミングでご確認ください。
Android チームは、いつもデベロッパーの皆さんに「アプリを書くときに一番困っていることは何か」と問いかけています。特によく上がってくる問題が、ビルド速度です。Android のビルド ツールチェーンには長年にわたって着実に改良を重ねてきましたが、今回はその改善に KSP を加えています。KSP は、次世代の Kotlin アノテーション処理を行い、Kotlin デベロッパーのためにビルド速度を劇的に向上させます。また、KAPT とは違い、Kotlin/Native と Kotlin/JS のサポートを提供します。
Kotlin Annotation Processing Tool(KAPT)(英語) は、Java のアノテーション処理インフラストラクチャと連携し、Kotlin でほとんどの Java 言語アノテーション プロセッサがそのまま動作するようにしています。これを行うために、KAPT は Kotlin コードをコンパイルし、Java アノテーション プロセッサに必要な情報を保持した Java スタブに変換しています。しかし、このスタブを作成する処理にはコストがかかります。また、コンパイラは、プログラム内にあるすべてのシンボルを複数回解決しなければならないことになります(1 回はスタブ生成のため、もう 1 回は実際のコンパイルのため)。
KSP は Kotlin コンパイラ プラグインとして動作することで、スタブ生成モデルから脱却します。アノテーション プロセッサは、Java アノテーション処理インフラストラクチャに頼ることなく、Kotlin のソース プログラムやリソースを直接読み取って分析します。そのため、ビルド速度が劇的に短縮される(Room の Kotlin テストアプリでは最大 2 倍高速)だけでなく、Kotlin/Native や Kotlin/JS といった Android 以外の環境や JVM 以外の環境でも KSP を利用できるようになります。
KSP を使ってみるには、GitHub から KSP Playground プロジェクト (ZIP ファイル 3.1MB)をダウンロードします。このプロジェクトでは、アノテーション プロセッサとして KSP を使う方法と、利用者向けのアプリやライブラリとして使う方法の両方を示しています。
test-processor
workload
アプリ デベロッパーの方は、サポートされているライブラリの一覧と、モジュールを KAPT から KSP に移行するためのクイックスタート ガイドをご覧ください。
プロジェクトで Moshi や Room を使っている方は、モジュールのビルドファイルを少し変更するだけで、すぐに KSP を試すことができます。たとえば、Gradle モジュールで KAPT プラグインを KSP プラグインに置き換えて KSP の依存関係を入れ替えるだけで、KSP 版の Room を使うことができます。
apply plugin: 'com.google.devtools.ksp'dependencies { ... implementation "androidx.room:room-runtime:$room_version" kapt "androidx.room:room-compiler:$room_version" ksp "androidx.room:room-compiler:$room_version"}
dependencies {
...
implementation "androidx.room:room-runtime:$room_version"
kapt "androidx.room:room-compiler:$room_version"
ksp "androidx.room:room-compiler:$room_version"
}
詳細は、Room のリリースノートをご覧ください。
KSP が 1.0 リリースを迎えたので、KAPT ベースのライブラリから移行すれば、皆さんの Kotlin プロジェクトでもビルド時間を短縮できます。また、たくさんの Android 固有のライブラリもアップデートしています。パフォーマンスが大幅に改善されており、本日から試すことができます。
Reviewed by Tamao Imura - Developer Marketing Manager, Google Play
今年の Google I/O はいかがでしたか?まだチェックしていない方は忘れずに Google 基調講演、デベロッパー基調講演、What's new in Android の 3 つのセッションをぜひご覧ください(※ 3 つとも日本語字幕対応)。美しいリップル(波紋)効果やストレッチ オーバースクロールを含む Android 12 Beta 1 、7 月に 1.0 の安定版になる Jetpack Compose、Material You の発表、ベータ版になった Android Studio Arctic Fox、Android デベロッパーに最も使われている言語である Kotlin(トップ 1,000 アプリの 80% が使用)や、Jetpack ライブラリがトップ 10,000 アプリのうち 84% 以上で使われている現状などをすべて確認できます。
まだご覧になっていない方は、ぜひご覧ください。また、この記事では皆さんが見逃してしまったかもしれないニュースをご紹介しましょう。今年の I/O のセッションはすべて日本語字幕に対応していますので、ぜひ切り替えてご覧ください。
What’s new in Jetpack セッションとブログ記事(英語)の要点は、CameraX、Hilt、Paging 3、ConstraintLayout、MotionLayout、Security Crypto、そして Fragment ライブラリが安定版に移行したことです。DataStore と Compose は現在ベータ版です。そして、Jetpack に以下の新しいライブラリが加わります。
さらに、WorkManager の新バージョンで現在アルファ版の 2.7 は、Android S SDK がターゲットになっており、プラットフォームの新しいフォアグラウンド制限が追加でサポートされています。詳しくは、Effective background tasks on Android セッションをご覧ください。
また、Navigation ライブラリを使っている方は、最新のアルファ版で複数のバックスタックがサポートされているので、ご確認ください。
Jetpack Compose が 7 月に 1.0 の安定版になるので、誰もが心躍らせていることでしょう。しかし、Compose を採用するときに、望まないのであれば、アプリのアーキテクチャを変更する必要はないことはご存知でしょうか。詳しくは、Using Jetpack libraries in Compose のセッションをご覧ください。Compose は、Navigation、Kotlin フロー、Hilt など、特に人気のあるライブラリに組み込めるようになっています。
さらに、Compose ではマテリアル デザインの実装も提供されます。その機能を活用する方法については、Build beautiful Material Design apps with Jetpack Compose セッションをご覧ください。
2 つの新しい Codelab も公開されています。Compose Navigation と Compose のテストです。Compose について体系的に学習する場合は、こちらのラーニングパスとワークショップをご覧ください。初めての Compose アプリを構築する方法を動画形式で基礎から説明しています。
Android 12 の最初のベータ版には、Android 5.0 でマテリアル デザインが導入されて以降、最大のデザイン変更が含まれています。これには、システムのテーマを使ってウィジェットに適用するダイナミック カラーなど、アプリ ウィジェットの動作の仕組みと外観の大幅な更新が含まれています。詳しくは、Refreshing widgets セッションをご覧ください。
また、システム全体にストレッチ オーバースクロール効果が新しく導入されますが、これは 1 つのスクロール コンテナにしか適用されないので、アプリの動作がどのようになるかを確認しておきましょう。
Android 12 で Bluetooth デバイスをスキャンするアプリは、neverForLocation 属性付きの新しい BLUETOOTH_SCAN パーミッションがあれば、位置情報パーミッションは必要なくなります。これにより、アプリの煩雑さが軽減されるだけでなく、LOCATION パーミッションが必要なアプリの数も減ることになります。
neverForLocation
BLUETOOTH_SCAN
LOCATION
位置情報と言えば、FINE_LOCATION パーミッションをリクエストした場合でも、ユーザーはアプリにおおよその位置しか渡さないように設定できるようになります。
FINE_LOCATION
Beta 2 に導入する予定のたくさんの新しいプライバシー機能についてもお知らせしました。ユーザーに表示されるプライバシー ダッシュボード、新しいマイクとカメラのインジケーターと切り替え機能、クリップボード読み取り通知などです。Android 12 におけるプライバシー関連のすべての変更については、What’s new in Android privacy セッションをご覧ください。
今回のベータ版には、パフォーマンス クラスも導入されています。これは、要求の厳しいユースケースや高品質のコンテンツをサポートできるデバイス向けの一連の機能で、現在は主にメディア機能を対象としています。
Android 12 Beta 1 は、エミュレータ、Pixel 3 以降のデバイス、またはデバイス パートナーが発売しているデバイスの一部で試すことができます。
たくさんの新機能が搭載された Android Studio Arctic Fox が Beta チャンネルで公開されています。Compose のサポート、Compose 開発を加速させるすばらしいツール、Layout Inspector の Compose サポート、組み込みのユーザー補助スキャナなどの機能が搭載されています。それだけでなく、折りたたみ式デバイスのエミュレータ、Android TV リモコン、Wear OS のペア設定ウィザードなど、サポート対象のデバイスも増えています。また、生産性を飛躍的に向上させるため、Background Tasks Inspector や Kotlin コルーチン デバッガ、Kotlin Symbol Processing のサポートも Android Studio に追加されました。
これらすべて、さらにその他の機能も、What's new in Android Development tools セッションでご紹介しています。
ConstraintLayout と MotionLayout の改善についてのさらに詳しい情報や、Android Studio で利用できる Compose ツールについては、What's new in design tools セッションをご覧ください。
Android 開発コミュニティで、Kotlin が採用される数が増えています。State of Kotlin on Android セッションの中で特にお伝えしておきたい新機能が、Kotlin Symbol Processing と、UI レイヤーからフローを収集する新しいライフサイクル API です。
Kotlin Symbol Processing(KSP)は、高速のビルドと、Kotlin エコシステムで最高級のシンボル処理を目指しています。KAPT による Java スタブ生成と、それに伴う長いビルド時間は不要になります。KSP は Kotlin コンパイラに組み込まれており、すべての Kotlin シンボルへのアクセスを提供します。また、KSP はベータ版に到達し、API サーフェスが確定しました。現在 KAPT を使っているプラグイン作成者の皆さんは、ぜひ KSP への移行を始めてください。私たちの Jetpack Room ライブラリもベータ版として KSP をサポートした結果、KAPT に比べて処理が 2 倍高速になりました。KSP についての話題は、先日の ADB ポッドキャストでも取り上げました。詳しく知りたい方は、ぜひお聴きください。
lifecycle-runtime-ktx ライブラリの最新版には、ライフサイクルに対応した repeatOnLifecycle API が含まれています。この API は、ライフサイクルがある状態に到達した場合やその状態を下回った場合に、コードブロックをキャンセルしたり再開したりします。この動作は、ビューがバックグラウンドにある場合に実行を停止してアップストリームのフローをアクティブに保つ launchWhenStarted API とは異なります。新しい API を使うと、特定のシナリオでリソースを無駄に消費しなくなるので、アプリの効率を高めることができます。
lifecycle-runtime-ktx
repeatOnLifecycle API
launchWhenStarted
この API によって、Android アプリのすべてのレイヤーで Flow を使うための完全なストーリーができあがりました。詳しくは、Migrating from LiveData to Kotlin’s Flow のブログ記事をご覧ください。
タブレット、Chrome OS デバイス、折りたたみ式デバイスなどの大画面デバイスをターゲットにしやすくするためのたくさんの機能をお知らせしました。たとえば、アップデートされた折りたたみ式対応の SlidingPaneLayout を使うと、一覧/詳細ビューを簡単に実装できます。また、横向き大画面用の新しい垂直ナビゲーション レール コンポーネントや、Button、TextField、Sheet のような極端に引き延ばされることが多いマテリアル コンポーネントの最大幅の値を導入し、新しいガイダンスも提供しています。詳しくは、こちらのセッションをご覧ください。
SlidingPaneLayout
Wear の次期バージョンが登場します。そこで、プレビュー エミュレータ システム イメージ、Android Studio から簡単に Wear エミュレータと他のデバイスをペア設定できるペア設定アシスタント、バーチャル心拍数センサーなどの新しいツールを準備しています。Ongoing Activities API とタイルによって、ユーザーがアプリとインタラクションを行う方法がさらに増えます。Samsung との共同作業で作成した新しいヘルスサービス プラットフォームは、現在アルファ版として組み込むことができます。また、カーブしたテキスト、ウォッチフェイス、ウォッチフェイスの追加機能、リモート インタラクションなど、Wear 向けの開発を容易にするその他の新しい Jetpack API も準備しています。詳しくは、Now is the time: What's new with Wear セッションで解説しています。
Android TV では、Cast Connect でストリームの転送と拡張が可能になり、Android 11 を実行する新しいエミュレータが利用できるようになりました。また、ADT-3 デバイスでは Android 12 Beta 1 を利用できます。8,000 万台を超えるアクティブな TV デバイスで稼働する Android の詳細については、What's new in Android TV and Google TV セッションをご覧ください。
Android に、アップデート可能な完全統合型の ML 推論スタックが搭載されることをお知らせしました。つまり、TensorFlow Lite for Android(TFLite)と Neural Networks API(NNAPI)が Google Play 開発者サービスを使って提供されるようになります。そのため、アプリの APK サイズを削減でき、新しい APK を公開しなくても、最新の高パフォーマンスなバージョンを活用できます。TFLite と NNAPI、そして関連するチップセット向けのドライバは、プラットフォームのバージョンとは独立してアップデートされるので、Android エコシステム全体でドライバと API の一貫性が向上します。また、TFLite 2.3 に互換性リストが追加され、どの部分を GPU やアクセラレータで実行するとモデルを高速化できるかがわかるようになっています。そのリストやモデルが提供するメタデータを使って、CPU、GPU、他のアクセラレータ バックエンドのどれで実行するかを判断する Automatic Acceleration についてもお知らせしました。Android のオンデバイス ML の新機能については、What's new in Android Machine Learning セッションをご覧ください。
これまで、CI サーバーで合格するテストがローカルの Android Studio では失敗する、あるいはその逆の事象を見たことがある方もいるかもしれません。このようなことが起きると、テストの信頼性が失われ、生産性に明らかな影響が出る可能性があります。その原因の 1 つは、Android Studio と Android Gradle プラグインが異なるバージョンの Android インスツルメント テストランナーを実装していることです。Android Studio Arctic Fox では、Android Studio のすべてのテストが Android Gradle プラグインで実行されるので、動作の一貫性が保たれます。
プロジェクト Nitrogen がどうなっているのか、気になっている方も多いでしょう。Nitrogen はもう存在しません。代わりに、統合テスト プラットフォーム(UTP)が登場しています。これは拡張可能なテスト実行環境で、Android Studio と Android Gradle プラグインから大規模な Android テストを実行します。
UTP によって実現できる機能の 1 つが、Gradle が管理する仮想デバイスです。これにより、Gradle DSL を使ってデバイスを定義できるようになります。もう 1 つの機能は、複数のデバイスで並列にテストを実行することにより、テスト実行の拡張性を向上させる機能です。さらに、テストが失敗したときのエミュレータのスナップショットを取得し、後ほどその状態を復元して何がうまくいかなかったのかを調査できるようにする機能もあります。
テストの詳細については、What's new in Android testing tools セッションをご覧ください。
I/O ではゲーム デベロッパー向けの内容はそれほど多くありませんでしたが、その大きな理由は、7 月 12-13 日に Google for Games Developer Summit の開催を予定していることです。登録は無料です。I/O では語られなかったゲーム開発に関するセッションをお届けする予定です。
長年にわたって、ポリシー、ポリシーの変更、ポリシー違反への対応について多くの質問が寄せられてきました。そのご要望にお答えして、Google Play Console に新しいポリシーとプログラムのセクションで、ポリシーとその適用情報が 1 か所で確認できるようになりました。
また、Google Play に新しい SDK コンソールが導入され、SDK プロバイダが非準拠や古い SDK バージョンなどの問題を報告できるようになります。AppBundle で公開する場合、Android Gradle プラグイン 4.0 以降では、アプリのどの SDK に依存関係があるかを自動的に報告できます。これにより、Play で SDK のアップデートが推奨される場合に通知などを行えるようになります。今年中には、アプリに適切な SDK を選択する際に役立つ新しいウェブサイトが Play に登場する予定です。
Play Billing 4.0 ライブラリのリリースにより、複数の数量の購入や、複数のプロダクトを 1 つのサブスクリプションの一部としてまとめるマルチライン サブスクリプションなどの新機能を利用できるようになります。既存の課金対応アプリは、今年の 11 月 1 日までに、少なくとも以前の Play Billing 3.0 ライブラリにアップデートする必要があります。新規アプリは、8 月 2 日までに Play Billing 3.0 以降に移行する必要があります。
ADB エピソード 163 では、Android グラフィック チームの Nat Duca と Sumir Kataria とADB チームで、シェーダー、GPU、Vulkan、OpenGL、ANGLE、ドライバ、ぼかし、ピクセルなどのトピックについてのトークをお届けします。もちろん、Chet のお気に入りの「色」についての話も登場します。
エピソード 164 は、Jetpack Compose について取り上げる新しい連載ミニシリーズ「AD/BC」の初回です。このシリーズでは、Android の未来の UI ツールキットについて、さまざまなトピックを掘り下げます。今回は、Nick と Chet が Adam Powell と Leland Richardson に、Compose のコンパイラやランタイム、データフローについて、そして Compose がデータの状態の変化に応じて Composable を呼び出すタイミングを判断するという素敵な機能について話を聞きました。
今回は以上です。今年の Google I/O はお楽しみいただけましたでしょうか。Jetpack、Android 12 とプライバシー、ツール、Kotlin、大画面、Wear OS、Android TV、オンデバイス機械学習、テスト、ゲーム開発、Google Play といったさまざまな最新情報が満載でした。グラフィックと Compose のポッドキャストもお聴きください。次回も Android デベロッパーの世界の最新アップデートをお届けします。お楽しみに。
この記事は Modern Android Development チーム による Android Developers Blog の記事 "Android @ Google I/O: 3 things to know in Modern Android Development" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。
※日本語字幕に対応しています。ぜひ切り替えてご覧ください。
ここ数か月間で、いくつかの Jetpack ライブラリが安定版やベータ版に到達したり、アルファ版でリリースされています。主なものをご紹介します。
新機能についての詳細は、I/Oの他のセッション What's new in Jetpack、Using Jetpack libraries in Compose をご覧ください。また、Macrobenchmark の詳細については、 Measuring Jank and Startup with Macrobenchmark をご覧ください。すべての動画が日本語字幕に対応しています。
※日本語字幕に対応しています。
Android Studio Arctic Fox が提供するさまざまなインスペクターを使うと、アプリのデバッグが簡単になります。バックグラウンド作業では、Background Task Inspector を使うと WorkManager のワーカーの状態を把握できます。UI 用の Layout Inspector は、Android ビューと Compose の両方に対応しています。データベースのデバッグには、Database Inspector を利用できます。
実際のインスペクターを見てみたい方は、 What’s new in Android development tools セッションをご覧ください。
私たちは、ツールから API まで、Android における Kotlin をあらゆるレベルで改善し続け、さまざまな学習方法を提供しています。現在アルファ版の Kotlin Symbol Processing(KSP)は、KAPT より最大 2 倍高速に実行できる簡潔なコンパイラ プラグイン API です。私たちは、JetBrains と連携して IDE のパフォーマンスの問題に対処しています。その結果、自動インポート候補の表示が最大 20 倍高速になりました。また、DataBinding に StateFlow のサポートを追加し、UI で DataBinding を使わずに Flow を監視する新しい API を追加しました。すべての Kotlin の改善点は、 State of Kotlin on Android セッションでご紹介しています。
Modern Android Development(最先端の Android 開発)に関連する、今年のすべての Google I/O セッションは、こちらのプレイリストからご覧ください。
Reviewed by Hidenori Fujii - Google Play Developer Marketing APAC
この記事は Karen Ng、Jacob Lehrbaum による Android Developers Blog の記事 "What's new for Android developers at Google I/O" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。
Android デベロッパーの皆さんは、世界中の人々を喜ばせるエクスペリエンスを作り出そうと日々努力を重ねています。人々がこれまでになくアプリを必要としている今、期待も大きくなり、デベロッパーとしての仕事の難易度も高まっています。私たちは Google I/O で、デベロッパーの皆さんをサポートするためにリリースした新機能をいくつか発表しました。過去最大級のデザイン変更を行った Android 12 や、高品質の優れたアプリ開発をサポートする Jetpack、Jetpack Compose、Android Studio、Kotlin などです。また、ウェアラブルデバイスや大画面対応が進むデバイスを通して、ユーザーによるアプリの使用シーンを広げるお手伝いをしています。こちらの Developer Keynote でもカバーしていますが、この記事でいくつかをハイライトしてご紹介します。
Android 12 は最初のベータ版のロールアウトがはじまったばかりですが、素晴らしい機能が満載です。ユーザーの安全のための機能である、Bluetooth や推定位置情報の利用許可、優先ジョブやスタートアップ アニメーションなどといったパフォーマンスの改善、よりインタラクティブなウィジェットやストレッチ オーバー スクロールなどの楽しいエクスペリエンスまで、このリリースで Android は過去最大級のデザイン アップデートをしています。
Android 12 Beta 1 の内容の詳細についてはこちらをご覧ください。内容をご確認いただき、年内公開のコンシューマ リリースに向けて、アプリの準備を始めてください。今すぐベータ版をダウンロードして、あなたのアプリでお試しください。
ここ数年間、私たちは Android 開発エクスペリエンスを進化することに取り組んできました。デベロッパーの皆さんのフィードバックに耳を傾け、フィードバックにオープンであり続けました。それが、Android の特徴だからです。しかしながら、自分たちが正しいと信じることに関しては、妥協しないよう心がけてきました。このことは、Android Studio(デベロッパーに合わせることができる高性能 IDE) 、Kotlin(より少ないコードでより多くのことを実現できるプログラミング言語)、Jetpack ライブラリ(後方互換性でモバイルに関連する最も難しい問題を解決するライブラリ)を通して、おわかりいただけるでしょう。
このオファリングの次のステップは Jetpack Compose、あらゆる Android デバイス向けの優れたアプリを簡単に構築できる最新 UI ツールキットです。私たちは、ここ Google I/O で 2 年前に Compose を発表し、それ以来新しいバージョンを公開しながら強化を重ね、フィードバックに耳を傾け、反映させてきました。今年はじめに公開した Compose Beta 版 では、世界中のデベロッパーの皆さんが、すばらしく革新的なエクスペリエンスを提供するアプリを通常の半分ほどの時間で作り出すことも実現されています(株式会社メルカリのケーススタディ)。また、Compose を使ったコンテストである #AndroidDevChallenge へのデベロッパーの皆さんからの熱い反響に、私たちはとても感動しました!
次回の Material You のアップデート(詳細はこちら)では、新しい マテリアル コンポーネントを追加し、大画面に対応する開発をさらにサポートする予定です。短期間で楽に素晴らしい UI を作成できるようになります。Compose のテストは最後の追い込み中です。1.0 Stable は 7 月にリリース予定です。ご準備ください。
公式の強力な Android IDE の最新リリース、Android Studio Arctic Fox (2020.3.1) Beta が、2021 年 5 月 19 日(現地時間 5 月 18 日)に公開されました。より楽に、より短期間で良質なアプリを開発できるようデベロッパーをサポートする IDE です。このツールスイートを提供しアップデートすることで、私たちは 3 つの主要テーマを強化してきました。そのテーマとは、UI 設計期間の短縮、新しいデバイスへのアプリ拡張、デベロッパーの生産性向上です。この最新リリースと Compose を合わせて使うことで、最新の UI を作成することができます。複数のデバイスでのテスト結果をご覧ください。そして App Inspector で、デバッグ データベースとバックグラウンド タスクを最適化してください。また、Accessibility Scanner (ユーザー補助検証ツール)を用いるとアプリがより使いやすく、Memory Profiler を用いるとアプリがより高性能になります。開発期間短縮のため、Android Gradle プラグイン 7.0、新しい DSL、さまざまな API を用意しました。Android Studio アップデートの詳細についてはこちらをご覧ください。
最近の調査によると、Kotlin はいまや、プロの Android デベロッパーに最も使われている第 1 言語です。実際、Google Play Store の 120 万以上のアプリで Kotlin が使用されています。これには、トップ 1000 アプリの 80% が含まれます。Google でも、Kotlin は愛されています。Drive、Home、Maps、Play など 70 以上の Google アプリで Kotlin が使用されています。そして Kotlin の注釈処理のために新しく作られた、まったく新しいネイティブソリューション、Kotlin Symbol Processing が本日リリースされました。Kotlin のコードを直接解析するための、強力だがシンプルな API です。Room のようなライブラリで最大 2 倍の速度を誇ります。
Android Jetpack で開発されたライブラリ スィートを利用すると、ボイラープレート コードが減り、本来のコードに集中することができます。現在、トップ 10,000 アプリの 84% 以上で Jetpack ライブラリが使用されています。そして 5 月 19 日(現地時間 5 月 18 日)、Jetpack 向けの新リリースがいくつか公開されました。アプリをリリースする前にアプリの起動に影響を与える大きなインタラクションやジャンクを把握するための Jetpack Macrobenchmark(Alpha)、Jetpack DataStore(Beta)を介してデータをより効率良く維持するための新しい Kotlin Coroutines API などです。Android Jetpack のアップデートの詳細についてはこちらをご覧ください。
最新の Android 開発環境を構築する上で、私たちが心掛けているもっとも大事なことは、これらのツールを提供することで 皆さんがより容易に Android の次の時代を切り開いていけるようにするということです。そしてそれは、電話と各種デバイス(テレビ、自動車、時計、タブレット)が接続し、連携することで生まれる新たな世界を実現することに他なりません。
今日 5 月 19 日(現地時間 5 月 18 日)から私たちは、ウェアラブルにむけて大きな一歩を踏み出します。まず、Samsung と合同で Wear と Tizen の長所を組み合わせた統合プラットフォームを構築すると発表しました。次に、刷新した Google アプリによる新しいコンシューマ エクスペリエンスをベストプラクティスとして共有しました。3 つめとして、Fitbit の世界クラスの健康フィットネス サービスをプラットフォームに取り入れることにしました。これは、Android デベロッパーにとっては、手が届く範囲が広がること、そしてモバイルアプリを素晴らしいものとする既存のスキル、ツール、API のすべてを使えることを意味します。結果として、世界中の人に使われる単一のウェアラブルプラットフォームが構築されるのです。
Wear 向けの新しい Jetpack API は、小型スクリーン用に調整し、バッテリーの寿命を伸ばすために設計しました。Jetpack Tiles API を使えば、Wear エコシステムの中のあらゆるデバイス向けカスタムタイルを作成できます。他にも Wear での開発を支援する新しい機能がたくさんあります。Samsung と共同してつくられた健康フィットネス向けの新しい API セットを使用すると、センサーやメトリクス計算のデータ コレクション(心拍数、カロリー、毎日の移動距離など)が、1 つの信頼できるデータソースから取得された、無駄のない、一貫性を持った、正確なデータになります。これらすべてが新しいツールにまとめられて、Android Studio Arctic Fox Beta でリリースされています。アプリをテストするための簡易なペアリングや、エミュレータでの仮想の心拍数センサーまで揃っています。アプリが配信されたら、ユーザーは、大きくアップデートされアプリの見つけやすさも向上した Google Play で、 より容易に Wear アプリの世界を楽しむことができます。Wear アップデートの詳細については、こちらをご覧ください。
タブレット、折りたたみ式デバイス、Chrome OS ノートパソコンなど、スマホのコンテンツをより大きな画面で体験するユーザーが増えています。人々は、家族や友人とのつながりを保ったり、学校に行ったり、リモートワークしたりする目的で、大型画面デバイスにますます依存するようになっています。実際に使用されている大型画面の Android デバイスは 2 億 5000 万台を超えています。Chrome OS は昨年、PC 市場の成長率の 5 倍、前年比で +92% 成長しました。その結果、Chrome OS は最速の成長を遂げて、2 番目に人気のデスクトップ OS になりました。この機会を掴むべく、大型画面でのエクスペリエンスをより簡単に最適化するための API と各種ツールを用意しました。たとえば、SlidingPaneLayout 1.2.0 と新しい垂直ナビゲーション レール コンポーネントを使うと大きくなった空間に合わせてコンテンツのサイズが自動調整されます。コンポーネントの幅を最大化することで UI が間延びしないようにします。また、プラットフォーム、Chrome OS、および Jetpack windowmanager がアップデートされたため、デフォルトでもアプリが問題なく動作します。詳細についてはこちらをご覧ください。
以上のことは、高品質の Android アプリを構築しやすくする、新しい方法のほんの一部です。5 月 19 日(現地時間 5 月 18 日)以降、私たちは Android と Google Play に関するテクニカル セッションを 20 以上公開し、バックグラウンド タスク、プライバシー、Android における機会学習、Android 12 に備えるトップ 12 のヒントなど、さまざまなトピックを扱います。自動車、テレビ、ウェアラブルの構築を担当する方のためのセッションもあります。こうしたセッションなどのすべての情報は、I/O の Web サイトにあります。今年の Google I/O では、セッションやニュースだけでなく、Google 関係者や他のデベロッパーとバーチャルにつながることができる楽しい仕掛けがたくさんあります。I/O Adventure の Android ドームをチェックしてください。新しいブログ投稿、ビデオ、コードラボなどをご覧いただけます。Jetpack Compose スキルを試したり、ドーム内部の自動車を巡るバーチャルツアーにもご参加ください!(注:会期外でアクセスできないプログラムがありますのでご了承ください)
Reviewed by Yuichi Araki - Developer Relations Team and Tamao Imura - Developer Marketing Manager, Google Play
この記事は Rohit による Android Developers Blog の記事 "Using DataStore With Kotlin Serialization" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。
過去公開したブログ記事では、Protos や Preferences で DataStore を使う方法について解説してきました。どちらのバージョンの DataStore も内部的に Protos を使ってデータをシリアル化します。Kotlin のシリアル化を使えば、DataStore とカスタムのデータクラスを併用することもできます。この方法を使うと、データにスキーマを提供しつつ、ボイラープレート コードを減らすことができます。Protobuf ライブラリを学習したり、利用したりする必要はありません。Kotlin のシリアル化を使うには、次の作業が必要です。
Kotlin のデータクラスは Kotlin のシリアル化とシームレスに連携できるので、DataStore との相性は抜群です。データクラスでは equals と hashCode が自動生成され、DataStore はこれを利用します。データのデバッグや更新に便利な toString 関数と copy 関数も生成されます。
/* Copyright 2021 Google LLC. SPDX-License-Identifier: Apache-2.0 */data class UserPreferences( val showCompleted: Boolean, val sortOrder: SortOrder)
SPDX-License-Identifier: Apache-2.0 */
data class UserPreferences(
val showCompleted: Boolean,
val sortOrder: SortOrder
)
DataStore は可変型には対応していないので、クラスを確実に不変にすることがとても重要です。DataStore で可変型を使うと、バグや競合状態を捕捉するのが難しくなります。データクラスは、必ずしも不変である必要はありません。
var は可変なので、代わりに val を利用します。
/* Copyright 2021 Google LLC. SPDX-License-Identifier: Apache-2.0 */ data class MyData(- var num: Int+ val num: Int)- myObj.num = 5 // Fails to compile when num is val+ val newObj = myObj.copy(num = 5)
data class MyData(
- var num: Int
+ val num: Int
- myObj.num = 5 // Fails to compile when num is val
+ val newObj = myObj.copy(num = 5)
配列は可変なので、公開しないようにします。
/* Copyright 2021 Google LLC. SPDX-License-Identifier: Apache-2.0 */ data class MyData(- var num: IntArray)- myObj.num = 5 // This would mutate your object
- var num: IntArray
- myObj.num = 5 // This would mutate your object
データクラスのメンバーとして読み取り専用の List を使う場合でも、それが可変であることは変わりません。そうするのではなく、不変/永続コレクションを使うことを検討してください。
/* Copyright 2021 Google LLC. SPDX-License-Identifier: Apache-2.0 */ data class MyData(- val nums: List<Int>+ val nums: PersistentList<Int>)- val myInts = mutableListOf(1, 2, 3, 4)- val myObj = MyData(myInts)- myInts.add(5) // Fails to compile with PersistentList, but mutates with List+ val newData = myObj.copy(+ nums = myObj.nums.mutate { it += 5 } // Mutate returns a new PersistentList+ )
- val nums: List<Int>
+ val nums: PersistentList<Int>
- val myInts = mutableListOf(1, 2, 3, 4)
- val myObj = MyData(myInts)
- myInts.add(5) // Fails to compile with PersistentList, but mutates with List
+ val newData = myObj.copy(
+ nums = myObj.nums.mutate { it += 5 } // Mutate returns a new PersistentList
+ )
データクラスのメンバーに可変型を使うと、データクラスが可変になります。そうするのではなく、すべてのメンバーを確実に不変型にしてください。
/* Copyright 2021 Google LLC. SPDX-License-Identifier: Apache-2.0 */ data class MyData(- val mutableType: MutableType)- val myType = MutableType()- val myObj = MyData(myType)- myType.mutate()
- val mutableType: MutableType
- val myType = MutableType()
- val myObj = MyData(myType)
- myType.mutate()
Kotlin のシリアル化は、JSON やプロトコル バッファなどの複数のフォーマットをサポートしています。ここでは JSON を使います。ごく一般的で、使いやすく、クリアテキストで保存できるのでデバッグも簡単です。Protobuf も優れた候補です。小さく高速で protobuf-lite と互換性があるためです。
Kotlin のシリアル化を使って JSON でデータクラスの読み取りや書き込みを行うには、データクラスに @Serializable アノテーションを追加し、Json.decodeFromString<YourType>(string) と Json.encodeToString(data) を使用する必要があります。次に示すのは、UserPreferences による例です。
/* Copyright 2021 Google LLC. SPDX-License-Identifier: Apache-2.0 */@Serializabledata class UserPreferences( val showCompleted: Boolean = false, val sortOrder: SortOrder = SortOrder.None)object UserPreferencesSerializer : Serializer<UserPreferences> { override val defaultValue = UserPreferences() override suspend fun readFrom(input: InputStream): UserPreferences { try { return Json.decodeFromString( UserPreferences.serializer(), input.readBytes().decodeToString()) } catch (serialization: SerializationException) { throw CorruptionException("Unable to read UserPrefs", serialization) } } override suspend fun writeTo(t: UserPreferences, output: OutputStream) { output.write(Json.encodeToString(UserPreferences.serializer(), t).encodeToByteArray()) }}
@Serializable
val showCompleted: Boolean = false,
val sortOrder: SortOrder = SortOrder.None
object UserPreferencesSerializer : Serializer<UserPreferences> {
override val defaultValue = UserPreferences()
override suspend fun readFrom(input: InputStream): UserPreferences {
try {
return Json.decodeFromString(
UserPreferences.serializer(), input.readBytes().decodeToString())
} catch (serialization: SerializationException) {
throw CorruptionException("Unable to read UserPrefs", serialization)
override suspend fun writeTo(t: UserPreferences, output: OutputStream) {
output.write(Json.encodeToString(UserPreferences.serializer(), t).encodeToByteArray())
⚠️ DataStore で Parcelable を使用するのは Android のバージョンによってデータ形式が変わる可能性があるため安全ではありません。
DataStore を作成する際に、作成したシリアライザを DataStore に渡します。
/* Copyright 2021 Google LLC. SPDX-License-Identifier: Apache-2.0 */val Context.dataStore by dataStore("my_file.json", serializer = UserPreferencesSerializer)
val Context.dataStore by dataStore("my_file.json", serializer = UserPreferencesSerializer)
データの読み取りは、Protos を使う場合と同様です。
/* Copyright 2021 Google LLC. SPDX-License-Identifier: Apache-2.0 */suspend fun getShowCompleted(): Boolean { context.dataStore.data.first().showCompleted}
suspend fun getShowCompleted(): Boolean {
context.dataStore.data.first().showCompleted
データの更新には、生成された .copy() 関数を利用します。
/* Copyright 2021 Google LLC. SPDX-License-Identifier: Apache-2.0 */suspend fun setShowCompleted(newShowCompleted: Boolean) { // This will leave the sortOrder value untouched: context.dataStore.updateData { it.copy(newShowCompleted = showCompleted) }}
suspend fun setShowCompleted(newShowCompleted: Boolean) {
// This will leave the sortOrder value untouched:
context.dataStore.updateData { it.copy(newShowCompleted = showCompleted) }
DataStore、Kotlin のシリアル化、データクラスを併用すると、ボイラープレートを減らしてコードをシンプルにすることができます。ただし、可変性によるバグが紛れ込まないように注意しなければなりません。必要な作業は、データクラスを定義してシリアライザを実装することだけです。ぜひ実際に試してみてください。
DataStore についてさらに知りたい方は、ドキュメントをご覧ください。また、Proto DataStore や Preferences DataStore の Codelab もご確認ください。
Reviewed by Yuichi Araki - Developer Relations Team and Hidenori Fujii - Google Play Developer Marketing APAC
この記事は Ting-Yuan Huang、David Winer による Android Developers Blog の記事 "Announcing Kotlin Symbol Processing (KSP) Alpha" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。
2021 年 2 月 10 日(日本時間 2 月 11 日)、Kotlin Symbol Processing(KSP)のアルファ版をリリースしました。このまったく新しいツールは、Kotlin で軽量コンパイラ プラグインを作成するためのものです。KSP は KAPT に似た機能を提供しますが、最大 2 倍高速に動作し、Kotlin コンパイラ機能に直接アクセスできます。さらに、マルチプラットフォームの互換性を考慮して開発されています。
KSP は、Kotlin 1.4.30 以降のリリースと互換性があります。オープンソースのコードとドキュメントは、KSP GitHub リポジトリでご確認ください。
Kotlin デベロッパーから最も多く寄せられるリクエストは、ビルド速度の高速化です。多くのデベロッパーは、毎日何十回もアプリのデプロイを繰り返しています。そのため、遅いビルドが終わるのをじっと待たなければならないのは、大きな時間の無駄になる可能性があります。Kotlin コードのコンパイルで特に難しい点は、Kotlin にネイティブのアノテーション処理システムがないことです。Android では Room などにアノテーション プロセッサが多用されていますが、これは Java のアノテーション処理との互換性に依存しており、Kotlin Annotation Processing Tool(KAPT)を通して行われます。しかし KAPT では、中間 Java スタブを生成し、それを Java アノテーション処理システムで処理しなければならないので、高速に実行できるとは限りません。
KSP を設計するにあたって、Kotlin のアノテーション処理を一から構築するとしたら、それはどのようなものになるかについて検討しました。KSP は、Kotlin コードを直接解析する強力でシンプルな API を提供します。そのため、KAPT のスタブ生成によって生じていたビルド速度の遅さを大幅に改善できます。実際に、Room ライブラリを使った初期のベンチマークでは、KSP は KAPT に比べてほぼ 2 倍高速であることが実証できています。
実際に動作する KSP がどのようなものかを確認するには、GitHub から KSP Playground プロジェクトをダウンロードしてください。以下の内容が含まれています。
ビルダーを実装するすべてのロジックは test-processor 内にあります。コンシューマー(workload)側で KAPT と KSP を使用する際の唯一の違いは、次のようにビルドファイルに 2 行分の差異があることだけです。
これが KSP の目指すところです。ほとんどの Android アプリのデベロッパーは、内部処理について心配する必要はありません。この 1 行を変更しさえすれば、KSP をサポートするライブラリは通常のアノテーション プロセッサのように見えます。違うのは、最大 2 倍高速になることだけです。ただし、KAPT と KSP を同じモジュールで利用すると、内部的にビルドが遅くなる可能性が高くなります。そのため、アルファ版の期間中は、KSP と KAPT は別々のモジュールで利用したほうがよいでしょう。
KSP に対応するアノテーション プロセッサが増えるにつれて、ほとんどのモジュールは KAPT の完全互換に近い形で KSP を利用できるようになるはずです。現在は、こちらの表でどのアノテーション プロセッサが KSP をサポートしているかを確認できます。KSP をサポートするライブラリや KSP のサポートを実装するライブラリがこの表にない場合は、提案と合わせてプルリクエストをお送りください。
現在アノテーション処理を利用しているライブラリ作成者の方は、ライブラリを KSP に対応させる方法がクイックスタートや README ガイドに掲載されていますので、ご覧ください。
KSP がアルファ版になったので、ライブラリ作成者にとっては、詳しい内容を確認して KSP Issue Tracker から API に関するフィードバックを送り始める絶好のタイミングです。リリースに関する最新情報は、Kotlin Slack の #ksp チャンネルに定期的に投稿しています。昨年 6 月のデベロッパー プレビュー以降、100 以上のバグや問題に対応してきました。その中には、Kotlin ライブラリ デベロッパーのすばらしいコミュニティの皆さんから報告いただいたものもたくさん含まれています。
Java は Oracle および/またはその関連会社の登録商標です。
2019 年 6 月、同社の開発チームは Android アプリの主要な開発言語が Kotlin に移行しつつあると判断し、Kotlin の導入を検討し始めました。Kotlin が採用された決め手は、Kotlin メインの Jetpack ライブラリを活用できること、コード量を減らしてメンテナンスの負担を軽減できること、構文の表現性が高く理解しやすいことなどでした。
同社の開発チームには Kotlin を使った開発経験があるエンジニアや、また、Java に精通しているエンジニアがいるため、Kotlin でのコーディングに難しさを感じることはありませんでした。Kotlin は Java との相互運用性が 100% なので、既存のコードベースを維持しながら、雨雲レーダーやニュース検索といった新機能を Kotlin で記述することができました。この雨雲レーダーでは、コルーチンを使用して画像のダウンロードとキャッシュを管理し、コルーチン ディスパッチャでタスクの管理を抽象化することで、raw スレッドの管理で陥りやすい罠を回避しています。
開発チームは、一部の Java コードをリファクタリングし、Kotlin の null 安全性機能も活用しています。Kotlin の構文では、可変性、null 可能性、初期化を特定できるため、早い段階でエラーを捕捉できます。これにより、コード変更の検証にかかる時間を 10% 短縮することができました。Kotlin の簡潔で効率的な構文を使用することで、コードベースの読みやすさが向上してメンテナンスが容易になり、実装から公開までの全体的な生産性が向上し、コード行数の 20% 削減に成功しました。
SmartNews アプリのコードはすでに全体で 45 % ほどが Kotlin に移行しています。新機能はすべて Kotlin で記述することにしているほか、既存のコードのリファクタリングを進めてさらにメンテナンス性を高めることにしています。
Kotlin を実装し、ボイラープレート コードを削減していくと、開発チームのモチベーションが向上してきました。開発メンバーがアイデアをより効率的に表現できるようになり、各自が読みやすいコード記述を心がけるように変化しました。同社でエンジニアリング マネージャーを務める大橋英雄氏によると、Kotlin はエンジニアの募集や採用にも効果的とのことです。
「応募者から最も多い質問のひとつが、"Kotlin は使っていますか?どれくらい活用していますか?" というものです。多くのエンジニアが Kotlin への移行に関心を寄せており、弊社としてもこの動きを支援したいと考えています。」
スマートニュース株式会社 Android エンジニアリングマネージャー 大橋英雄氏
SmartNews アプリへの Kotlin の導入は、アプリ開発だけに限らず、エンジニアのモチベーション向上や採用への良い反響を得ることができました。Android Developers の事例も併せてご覧ください。
Posted by Tamao Imura - Developer Marketing Manager, Platforms and Ecosystems
この記事は Florina Muntenescu による Android Developers Blog の記事 "MAD Skills Kotlin and Jetpack: wrap-up" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。
今回は MAD Skills シリーズの 1 つ、Kotlin と Jetpack についての動画と記事をまとめました。Android コードの表現力と簡潔さ、安全性を向上させ、Kotlin で非同期コードを実行しやすくするさまざまな方法を取り上げています。
それぞれのエピソードから、Kotlin と Jetpack についての最新情報をご確認ください。いくつかの具体的な API を取り上げ、API の使い方だけでなく、API が内部的にどのように動作しているか解説しています。また、すべてのエピソードには対応するブログ投稿があり、そのほとんどにサンプルか Codelab へのリンクが含まれているので、実際に試してみたり、コンテンツに関する理解を深めたりできます。また、Jetpack や Kotlin のエンジニアが登場するリアルタイム Q&A も実施しました。
このエピソードでは、Jetpack KTX 拡張機能を使って、Android と Jetpack のコーディングを簡単、快適、そして Kotlin らしくする方法を取り上げました。現在のところ、20 以上のライブラリに KTX 版があり、その中から特に重要なものを紹介します。core-ktx は、Android プラットフォームに由来する API を Kotlin らしく書けるようにする機能を提供しています。また、LiveData や ViewModel などの API と組み合わせてユーザー エクスペリエンスの向上を図れるいくつかの Jetpack KTX ライブラリも紹介します。
動画またはブログ記事(英語)をご覧ください。
エピソード 2 では、コルーチンと Flow を使って API をシンプルにする方法と、suspendCancellableCoroutine API と callbackFlow API を使って独自のアダプタを作る方法について説明します。このトピックを実際に試してみたい方は、Kotlin 拡張機能ライブラリの作成 Codelab をご覧ください。
動画を視聴するか、ブログ記事(英語)でご確認ください。
このエピソードでは、実際に Room を使ってみます。その上で、Kotlin を使って Room のテーブルやデータベースを作る方法、挿入などの 1 回限りの suspend 操作を実装する方法、Flow を使った監視可能クエリーについて簡単に確認します。コルーチンと Flow を使うと、Room はすべてのデータベース操作をバックグラウンド スレッドに移してくれます。Room のクエリーの実装方法やテスト方法については、動画またはブログ記事(英語)をご覧ください。実際に試してみたい方は、ビューで Room を使う Codelab をご覧ください。
エピソード 4 では、WorkManager を使って作業を簡単にする方法について説明します。この機能を使うと、非同期タスクのスケジュールを設定して、アプリが閉じられた場合や、デバイスが再起動した場合にも実行されることが期待されるタスクを、即時実行または遅延実行できます。このエピソードでは、WorkManager の基本について説明し、CoroutineWorker などの Kotlin API についても解説しています。
こちらの動画またはこちらのブログ記事(英語)をご覧ください。また、ぜひ WorkManager Codelab で実際に体験してみてください。
エピソード 5 では、Android の Google Developer Expert の Magda Miu さんが Kotlin の基本 API と CameraX を使った経験についてお話ししています。
最後のエピソードでは、リアルタイム Q&A を実施しました。司会の Chet Haase のほか、ゲストとして Architecture Components テックリードの Yigit Boyar、Kotlin プロダクト マネージャーの David Winer、そしてデベロッパー リレーションズ エンジニアの Manuel Vivo と私が参加し、YouTube、Twitter などから寄せられた質問に回答しています。
この記事は Florina Muntenescu による Android Developers - Medium の記事 "More productivity with Kotlin" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。
Kotlin は簡潔なプログラミング言語として知られています。そしてそれは、高い生産性を意味します。そして実際に、Kotlin を使っている Android デベロッパーの 67% が、生産性が向上したと述べています。このブログ投稿では、Kotlin を使ってパートナーのエンジニアたちが生産性を向上させた方法をいくつか共有し、そのために役立つ Kotlin の機能も紹介します。
レビューやメンテナンスの担当者は、読むコードが少なくなるので、コードが行っていることを理解しやすくなります。そのため、レビューやメンテナンスが楽になります。
その一例として、Flipkart のチームを紹介しましょう。
「弊社の社内調査によると、デベロッパーの 50% が、Kotlin でモジュールを書くと [機能を完成させるまでの] 見積りが小さくなると回答しました」(Flipkart)
Kotlin の機能のほとんどは、簡潔さと高い可読性を持つため、高い生産性につながります。特によく使われる機能について見てみましょう。
Java プログラミング言語では、コンストラクタのパラメータが省略可能な場合、一般的に次の 2 つの方法のどちらかを利用します。
Kotlin ではデフォルト引数を利用できるので、どちらも必要ありません。デフォルト引数を使うと、ボイラープレートを追加することなく、関数のオーバーロードを実装できます。
Cash App チームが Kotlin を使い始めたとき、多くのビルダーを削減し、書く必要があるコードの量を減らすことができました。場合によっては、コードのサイズが 25% 少なくなりました。
たとえば、以下の一例は、 Task オブジェクトの実装で、タスクの名前のみが必須パラメータになっています。ビルダーを使った場合と、デフォルト引数を使った場合でそれぞれどうなるかを示しています。
/* Copyright 2020 Google LLC. SPDX-License-Identifier: Apache-2.0 */- public class Task {- private final String name;- private final Date deadline;- private final TaskPriority priority;- private final boolean completed;-- private Task(String name, Date deadline, TaskPriority priority, boolean completed) {- this.name = name;- this.deadline = deadline;- this.priority = priority;- this.completed = completed;- }-- public static class Builder {- private final String name;- private Date deadline;- private TaskPriority priority;- private boolean completed;-- public Builder(String name) {- this.name = name;- }-- public Builder setDeadline(Date deadline) {- this.deadline = deadline;- return this;- }-- public Builder setPriority(TaskPriority priority) {- this.priority = priority;- return this;- }-- public Builder setCompleted(boolean completed) {- this.completed = completed;- return this;- }-- public Task build() {- return new Task(name, deadline, priority, completed);- }- }-}+ data class Task(+ val name: String,+ val deadline: Date = DEFAULT_DEADLINE,+ val priority: TaskPriority = TaskPriority.LOW,+ val completed: Boolean = false+)
/* Copyright 2020 Google LLC.
- public class Task {
- private final String name;
- private final Date deadline;
- private final TaskPriority priority;
- private final boolean completed;
-
- private Task(String name, Date deadline, TaskPriority priority, boolean completed) {
- this.name = name;
- this.deadline = deadline;
- this.priority = priority;
- this.completed = completed;
- }
- public static class Builder {
- private Date deadline;
- private TaskPriority priority;
- private boolean completed;
- public Builder(String name) {
- public Builder setDeadline(Date deadline) {
- return this;
- public Builder setPriority(TaskPriority priority) {
- public Builder setCompleted(boolean completed) {
- public Task build() {
- return new Task(name, deadline, priority, completed);
-}
+ data class Task(
+ val name: String,
+ val deadline: Date = DEFAULT_DEADLINE,
+ val priority: TaskPriority = TaskPriority.LOW,
+ val completed: Boolean = false
+)
デフォルト引数の詳細については、連載シリーズ Kotlin Vocablary のブログ記事「Kotlin のデフォルト引数」をご覧ください。
おそらく、シングルトン パターンはソフトウェア開発で特によく使われるパターンの 1 つでしょう。オブジェクトのインスタンスを 1 つだけ作成し、他のオブジェクトから共有してアクセスできるようにしたい場合に役立ちます。
シングルトンを作るには、インスタンスが 1 つだけ存在するようにオブジェクトの作成方法を制御し、コードがスレッドセーフであることを保証する必要があります。Kotlin では、object キーワードだけでこれを実現できます。
/* Copyright 2020 Google LLC. SPDX-License-Identifier: Apache-2.0 */ - public class Singleton{- private static volatile Singleton INSTANCE;- private Singleton(){}- public static Singleton getInstance(){- if (INSTANCE == null) { // Single Checked- synchronized (Singleton.class) {- if (INSTANCE == null) { // Double checked- INSTANCE = new Singleton();- }- }- }- return INSTANCE;- }- private int count = 0;- public int count(){ return count++; }- }+ object Singleton {+ private var count = 0+ fun count(): Int {+ return count+++ }+ }
- public class Singleton{
- private static volatile Singleton INSTANCE;
- private Singleton(){}
- public static Singleton getInstance(){
- if (INSTANCE == null) { // Single Checked
- synchronized (Singleton.class) {
- if (INSTANCE == null) { // Double checked
- INSTANCE = new Singleton();
- return INSTANCE;
- private int count = 0;
- public int count(){ return count++; }
+ object Singleton {
+ private var count = 0
+ fun count(): Int {
+ return count++
+ }+ }
Kotlin 言語の簡潔さとシンプルさは、演算子オーバーロード、分割代入、文字列テンプレートなどの機能から明らかです。そのため、コードはとても読みやすくなります。
たとえば、本を集めたライブラリがあるとしましょう。ライブラリから本を取り出し、そのタイトルだけを出力する場合、コードは次のようになります。
/* Copyright 2020 Google LLC. SPDX-License-Identifier: Apache-2.0 */fun borrow(){ library -= book val (title, author) = book println("Borrowed $title")}
fun borrow(){
library -= book
val (title, author) = book
println("Borrowed $title")
使われている Kotlin の機能は次のとおりです。
Kotlin を使うと、コードは読みやすく、書きやすくなります。シングルトンや委譲などのパターンが言語に組み込まれており、たくさんのコードを書く必要がないため、バグが紛れ込む確率が低くなり、メンテナンスの負荷も軽減されます。また、文字列テンプレート、ラムダ式、エクステンション関数、演算子オーバーロードなどの機能で、コードをさらに簡潔かつシンプルにできます。書くコードが少なくなれば、読むコードやメンテナンスするコードも少なくなり、エラーが減って生産性が上がります。
詳しくは、Kotlin と Android Kotlin でより優れたアプリを作成するをお読みください。また、各社のケーススタディをご覧ください。デベロッパーにとっての Kotlin のメリットが確認できます。世界で特に好まれている開発言語の 1 つである Kotlin を使ってみたい方は、入門ページをご覧ください。
この記事は David Winer による Android Developers Blog の記事 "The future of Kotlin Android Extensions" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。
Android Kotlin Extensions Gradle プラグイン(Android KTX と混同しないでください)は、2017 年にリリースされ、Kotlin による Android 開発に次の 2 つの便利な新機能をもたらしました。
findViewById
kotlinx.android.synthetic
@Parcelize
しかしその後、Android ビルド ツールチェーンと密接に統合された公式サポート ライブラリ View Binding for Android がリリースされ、Kotlin synthetics と同等の機能が提供されるようになりました。Parcelize は現在も使用が推奨されていますが、Kotlin synthetics の使用についてはたとえば以下のようにさまざまな欠点が明らかになりました。
Android Kotlin Extensions プラグインは、もともと JetBrains が開発したものです。そして私たちは、JetBrains とともに、synthetics のメンテナンスを続けることの賛否について議論してきました。その中では、可能な限り API を長期にわたってサポートできるよう努力すべきという視点もありましたが、その一方でユーザーにとって使いやすいアプリを作れるよう、デベロッパーの皆さんにベスト プラクティスを提供してコードベースを健全化することの重要性も指摘されました。
そして結論として、私たちのチームは共同で、推奨オプションである View Binding のサポートを続けることを優先し、来年 1 年をかけて synthetics のサポートを終了することを決めました。
kotlin-parcelize
android-kotlin-extensions
サポートの終了期間は、2020 年 11 月 23 日(日本時間 11 月 24 日)にリリースされた Kotlin 1.4.20 から始まります。android-kotlin-extensions は少なくとも 1 年間は残されますが、2021 年 9 月またはそれ以降の Kotlin リリースでは削除されます。kotlin-parcelize プラグインのメンテナンスは長期的に続ける予定です。Parcelize で発生する問題についてのご連絡は、今後も Android Studio Issue Tracker にお寄せください。
Reviewed by Takeshi Hagikura - Developer Relations Team and Hidenori Fujii - Google Play Developer Marketing APAC
ユーザーは皆さんのアプリにシームレスな体験を期待しています。アプリがクラッシュすれば、低評価のレビューやアンインストールが増え、ブランドにダメージを与えてしまうでしょう。その一方で、コミュニティの皆さんとの対話の中で、Kotlin を採用する主な理由の 1 つはコードの高い安全性であるということをよく耳にします。実際に何社かのパートナーは、Kotlin を使ってコードの安定性を改善しています。この投稿では、その方法をいくつか紹介するとともに、Google Play ストアの統計結果にも注目し、Kotlin とクラッシュ数との間に相関関係があるかどうかを確認してみたいと思います。
アプリの品質が影響するのは、ユーザー エクスペリエンスだけではありません。クラッシュ多いと、他のいくつかの要素にも悪影響が生じます。
Kotlin で構築したアプリはクラッシュする可能性が 20% 低い
Google Play のトップ 1,000 アプリを調査してみたところ、Kotlin を使っているアプリは、それ以外のアプリよりもユーザー 1 人あたりのクラッシュ発生率が 20% 低いことがわかりました。
その具体例として、コードの 74% が Kotlin である Swiggy のエンジニアリング チームは、新機能の開発を Kotlin に移行して以来、クラッシュを 50% 減らしました。こういった結果を Kotlin はどのように実現しているのか見ていきましょう。
Google Play でのクラッシュの原因ナンバーワンは NullPointerException です。Google Home チームは、2018 年よりすべての新機能を Kotlin で書いています。その結果、1 年前と比べて null ポインタによるクラッシュが 33% 減少しました。
Google Home が NullPointerException を 33% 削減
NullPointerException を避けるには、メソッドを呼び出したりメンバーにアクセスしたりする前に、扱っているオブジェクトの参照が null でないことを確認しなければなりません。Kotlin では、null 可能性が型システムの一部として組み込まれています。たとえば、変数は最初から null 可能か null 不可能かを宣言する必要があります。null 可能性を型システムの一部として組み込むことで、コードベースについての自分の記憶や知識、またコンパイル時警告(フィールドやパラメータに @Nullable アノテーションを付けた場合)に頼る必要はなくなります。null 可能性を強制することで、単なる警告ではなく、コンパイル時にエラーが発生します。null 可能性を扱う方法については、こちらのページをご覧ください。
NullPointerException
@Nullable
私たちデベロッパーは、気づかないうちにアプリにたくさんの問題を紛れ込ませています。そのほとんどはあまりに軽微で、調査するのは難しいかもしれません。そのような問題のうち、Kotlin を使うことで回避できるものをいくつか紹介しましょう。
hashCode()
2 つのオブジェクトが等しい場合、それらのハッシュコードも同じである必要があります。しかし、どちらかのメソッドを実装し忘れたり、クラスに新しいプロパティを追加したときに更新し忘れてしまったりすることがよくあります。データを保持するためだけのクラスを扱う場合は、Kotlin のデータクラスを使うようにしましょう。データクラスを使うと、コンパイラが hashCode() と equals() を生成してくれるので、クラスのプロパティを変更すると自動的に更新されます。
equals()
2 つのオブジェクトは構造が等しい(中身が同じ)のでしょうか。それとも、参照が等しい(ポインタが同じ)のでしょうか。Java プログラミング言語では、プリミティブには常に == を使います。そのため、実際には構造が等しいかどうかを確認(equals() を呼び出してチェック)したいのに、オブジェクトにも ==(参照が等しい)を使ってしまうというのがよくある誤りです。まず、Kotlin にはプリミティブ型はなく、Int や String などのクラスを使います。つまり、すべてがオブジェクトなので、オブジェクトとプリミティブ型の区別を気にする必要はありません。次に、Kotlin では == は構造が等しい、=== は参照が等しいと定義されています。したがって、誤って参照が等しいかどうかを確認してしまうことはありません。
==
Int
String
===
enum を扱う場合、通常はすべての可能なケースを記述しなければなりません。そのため、switch や if else チェーンを使うことになります。enum を修正して新しい値を追加する場合、enum を使っている各コード スニペットを手動でチェックし、新しいケースに対応しているかどうかを確認する必要があります。しかし、これはエラーにつながりがちです。Kotlin では、when を式として使うと、この確認をコンパイラに任せることができます。すべての可能な分岐に対応していない場合、コンパイラ エラーが発生します。
switch
if else
ユーザーやブランドにとって、アプリの安定性は重要です。Kotlin を使い始めてクラッシュ率を減らし、ユーザーの満足度を高めてアプリの高評価を守り、ユーザーの維持や獲得につなげましょう。
詳しくは、Kotlin でより優れたアプリを作成するためにできることをお読みください。また、ケーススタディをご覧いただき、Kotlin のメリットをご確認ください。世界でデベロッパーに広く使われている言語の 1 つである Kotlin を使ってみたい方は、入門ページをご覧ください。