この記事は Wayne Lu による Android Developers Blog の記事 " Answering your top questions on Android Game Development Kit " を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。
2021 年 7 月に Android Game Development Kit（AGDK） (英語) をリリースしてから、デベロッパーの皆さんよりお寄せいただいた主な質問をまとめました。その内容は、AGDK のライブラリやツールから、Android のメモリ最適化、グラフィックスの実装に関することまで、さまざまです。
まず、新進気鋭のゲーム デベロッパーから寄せられた、AGDK の一連のライブラリやツールの使い方に関する質問です。セットアップに応じて、以下の事項を推奨しています。
ご自身の環境に合致したゲームエンジンとワークフローに沿って、ゲーム内で利用する CPU、メモリ、ネットワーク、バッテリーなどの状況を詳細に調査する Android Studio Profiler、グラフィックスに特化してプロファイリングを行う Android GPU Inspector(英語)、フレームレートや読み込み時間を端末毎に最適化する Android Performance Tuner (英語) などの各種ツールを確認しましょう。
続いて、Android 12 での開発に関する質問も寄せられています。Android 12 でゲームを実行するにあたって、特別なことは何も必要ありません。しかし、プレイヤーがゲーム体験をカスタマイズできるように、Game Mode API と Interventions (英語) を導入していきましょう。
2 つ目は、Android と Windows のゲーム開発におけるメモリアクセスの動作の違いについての質問です。以下に、いくつかのヒントをまとめます。
3 つ目は、Android でのグラフィックスの実装に関する質問です。選択肢には、OpenGL ES と Vulkan グラフィックス API があります。
AGDK に関する主な質問は、Q&A 動画でも確認できます。また、Android ゲーム開発の最新リソースには、g.co/android/AGDK (英語) からアクセスできます。
Reviewed by Maru Maruyama - Developer Relations Engineer
この記事は Android Team による Android Developers Blog の記事 " Android Dev Summit returns on October 27-28, 2021! " を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。
Android Dev Summit が帰ってきます！数週間後となる10 月 27-28 日（日本時間 10 月 28 日 - 29 日）のイベントでは Android 開発の最新情報をご紹介します。今年のテーマは、Excellent apps, across devices（優れたアプリを、複数のデバイス間で）です。開発ツールや API、タブレットやウェアラブルを含む数十億台のデバイス間で使用できる優れたアプリの開発や、生産性向上を支援する技術についてお話しする予定です。
Android Dev Summit は、「The Android Show」からキックオフします。イベントは、10 月 27 日午前 10 時（太平洋標準時）、日本時間の 28 日午前 2 時に開始します。技術関連の基調講演では、Android 開発者向けの最新ニュースやアップデートをご紹介します。また、Android 開発の技術的な トピックに関しての 30 以上のセッションをご用意しました。さらに、Android 開発チームが結集し、皆さんからの熱意ある質問にライブで答える #AskAndroid も開催します。今年の Android Dev Summit は、世界中の Android デベロッパーとデジタルでつながる機会ですので、ぜひご参加ください。さらに詳しく知りたい方は、こちらのニュースレターに登録して最新情報をお受け取りください。
Reviewed by Tamao Imura - Developer Marketing Manager, Google Play
この記事は Peter Visontay, Bessie Jiang による Android Developers Blog の記事 " Making permissions auto-reset available to billions more devices " を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。寄稿者: Inara Ramji, Rodrigo Farell, James Kelly, Henry Chin
ほとんどのユーザーは、スマートフォンで多くの時間を過ごしています。仕事をする、ゲームをする、友人とつながるなど、アプリは人々にとってデジタルライフの主要な出入り口です。多くの場合、アプリが動作するためには、何らかの許可が必要になります。しかし、特定のデバイスに何十個ものアプリが存在することを考えれば、ユーザーが以前に何を許可したかを覚えておくのは至難の業です。長期間使うことがなかったアプリであればなおさらです。
Android 11 では、アプリの権限を自動リセットする機能を導入しました。この機能は、アプリが数か月にわたって使われなかった場合にランタイム権限を自動的にリセットするので、ユーザーのプライバシー保護に役立ちます。ランタイム権限とは、アプリが許可をリクエストした際に、プロンプトがユーザーに表示されるものです。2021 年 12 月より、この機能を数十億台のデバイスに展開します。この機能は、Google Play 開発者サービス (英語) を搭載し、かつ Android 6.0（API レベル 23）以降を実行しているデバイスで自動的に有効化されます。
この機能は、デフォルトで Android 11（API レベル 30）以降をターゲットとするアプリで有効になりますが、API レベル 23 から 29 をターゲットとするアプリでは、ユーザーが手動で許可の自動リセットを有効化できます。
では、デベロッパーの皆さまにはどのような影響があるのか説明します。
一部のアプリや権限は、自動的にリセットの対象外となります。たとえば、企業が利用中のデバイス管理者のアプリや、エンタープライズ ポリシーで固定された権限などです。
必要に応じて、デベロッパーはユーザーにリクエストを行い、システムがアプリの権限をリセットしないようにすることができます。これは、主にバックグラウンドで動作し、インタラクションを必要としないアプリで便利です。主なユースケースは、こちらに記載されています。
現在の動作
新しい動作
Android 11（API レベル 30）以降のデバイスで、権限が自動的にリセットされます。
以下のデバイスで、権限が自動的にリセットされます。
Google Play 開発者サービスを搭載し、Android 6.0（API レベル 23）から Android 10（API レベル 29）までのバージョン（両端値を含む）を実行しているデバイス
Android 11（API レベル 30）以降を実行しているすべてのデバイス
Android 11 以降をターゲットとするアプリで、デフォルトで権限がリセットされます。Android 6.0（API レベル 23）以降をターゲットとするアプリでは、ユーザーが手動で自動リセットを有効化できます。
現在の動作からの変更はありません。
アプリは、ユーザーに自動リセットの無効化をリクエストできます。
アクション
Android 11 API
（Android 11 以降のデバイスでのみ動作）
新しいクロスプラットフォーム API
（Android 11 以降のデバイスを含む Android 6.0 以降のデバイスで動作）
デバイスで権限の自動リセットが有効化されているかどうかのチェック
Build.VERSION.SDK_INT >= Build.VERSION_CODES.R を確認
androidx.core.content.PackageManagerCompat.getUnusedAppRestrictionsStatus() を呼び出す
アプリで自動リセットが無効化されているかどうかのチェック
PackageManager.
isAutoRevokeWhitelisted() を呼び出す
androidx.core.content.
PackageManagerCompat.
getUnusedAppRestrictionsStatus() を呼び出す
アプリで自動リセットの無効化をユーザーにリクエスト
次のアクションのインテントを送信:
Intent.ACTION_AUTO_REVOKE_PERMISSIONS
次で作成したインテントを送信: androidx.core.content.
IntentCompat.
createManageUnusedAppRestrictionsIntent()
val future: ListenableFuture<Int> = PackageManagerCompat.getUnusedAppRestrictionsStatus(context)future.addListener( { onResult(future.get()) }, ContextCompat.getMainExecutor(context)) fun onResult(appRestrictionsStatus: Int) { when (appRestrictionsStatus) { // Status could not be fetched. Check logs for details. ERROR -> { } // Restrictions do not apply to your app on this device. FEATURE_NOT_AVAILABLE -> { } // Restrictions have been disabled by the user for your app. DISABLED -> { } // If the user doesn't start your app for months, its permissions // will be revoked and/or it will be hibernated. // See the API_* constants for details. API_30_BACKPORT, API_30, API_31 -> handleRestrictions(appRestrictionsStatus) }} fun handleRestrictions(appRestrictionsStatus: Int) { // If your app works primarily in the background, you can ask the user // to disable these restrictions. Check if you have already asked the // user to disable these restrictions. If not, you can show a message to // the user explaining why permission auto-reset and Hibernation should be // disabled. Tell them that they will now be redirected to a page where // they can disable these features. Intent intent = IntentCompat.createManageUnusedAppRestrictionsIntent (context, packageName) // Must use startActivityForResult(), not startActivity(), even if // you don't use the result code returned in onActivityResult(). startActivityForResult(intent, REQUEST_CODE)}
getUnusedAppRestrictionsStatus()
この記事は Manuel Vivo による Android Developers - Medium の記事 " Introduction to Hilt in the MAD Skills series " を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。
MAD Skills 記事シリーズの Hilt についての記事です。この記事では、依存関係インジェクション（DI）が皆さんのアプリや Hilt にとって重要である理由について説明します。Hilt は、Android で DI を行うための Jetpack の推奨ソリューションです。
動画で視聴したい方は、こちらをご覧ください。
Android アプリで依存関係インジェクションの原理に従うことで、優れたアプリ アーキテクチャの土台を築くことができます。その結果、コードの再利用性が高まり、リファクタリングやテストが簡単になります。DI のメリットの詳細は、こちらをご覧ください。
プロジェクトでクラスのインスタンスを作成する場合、そのクラスが必要とする依存関係や推移的依存関係を満たしていくことで、依存関係グラフを手動で実現できます。
しかし、毎回これを手動で行うと、ボイラープレート コードが必要になり、エラーも起こりやすくなる可能性があります。たとえば、オープンソースの Google I/O アプリ iosched で利用している ViewModel をご覧ください。依存関係と推移的依存関係を含めると、FeedViewModel を作成するために必要なコードがどのくらいの量になるか想像できますか？
FeedViewModel
class FeedViewModel( private val loadCurrentMomentUseCase: LoadCurrentMomentUseCase, loadAnnouncementsUseCase: LoadAnnouncementsUseCase, private val loadStarredAndReservedSessionsUseCase: LoadStarredAndReservedSessionsUseCase, getTimeZoneUseCase: GetTimeZoneUseCase, getConferenceStateUseCase: GetConferenceStateUseCase, private val timeProvider: TimeProvider, private val analyticsHelper: AnalyticsHelper, private val signInViewModelDelegate: SignInViewModelDelegate, themedActivityDelegate: ThemedActivityDelegate, private val snackbarMessageManager: SnackbarMessageManager) : ViewModel(), FeedEventListener, ThemedActivityDelegate by themedActivityDelegate, SignInViewModelDelegate by signInViewModelDelegate { /* ... */}
class FeedViewModel(
private val loadCurrentMomentUseCase: LoadCurrentMomentUseCase,
loadAnnouncementsUseCase: LoadAnnouncementsUseCase,
private val loadStarredAndReservedSessionsUseCase: LoadStarredAndReservedSessionsUseCase,
getTimeZoneUseCase: GetTimeZoneUseCase,
getConferenceStateUseCase: GetConferenceStateUseCase,
private val timeProvider: TimeProvider,
private val analyticsHelper: AnalyticsHelper,
private val signInViewModelDelegate: SignInViewModelDelegate,
themedActivityDelegate: ThemedActivityDelegate,
private val snackbarMessageManager: SnackbarMessageManager
) : ViewModel(),
FeedEventListener,
ThemedActivityDelegate by themedActivityDelegate,
SignInViewModelDelegate by signInViewModelDelegate {
/* ... */
}
これは難解で繰り返しが多いので、容易に間違った依存関係を取得してしまうこともあると思います。依存関係インジェクション ライブラリを使えば、依存関係を手動で提供することなく、DI のメリットを活用できます。必要なコードはライブラリがすべて生成してくれます。その際に活躍するのが Hilt です。
Hilt は Google が開発した依存関係インジェクション ライブラリです。Hilt を使えば手動で書かなければならないボイラープレートをすべて生成してくれるので、アプリで DI のベスト プラクティスを最大限に活用できます。
Hilt はアノテーションを使ってコンパイル時にコードを生成するので、実行はとても高速です。その際に利用するのが、JVM の DI ライブラリである Dagger です。Hilt は、Dagger をベースに作られています。
Hilt は Android アプリの Jetpack 推奨 DI ソリューションであり、ツールや他の Jetpack ライブラリのサポートも含まれています。
Hilt を使うアプリには、@HiltAndroidApp アノテーションを付けた Application クラスを含める必要があります。このアノテーションにより、コンパイル時に Hilt のコード生成が実行されます。また、Hilt がアクティビティに依存関係を注入するには、そのアクティビティに @AndroidEntryPoint アノテーションを付けておく必要があります。
@HiltAndroidApp
@AndroidEntryPoint
@HiltAndroidAppclass MusicApp : Application() @AndroidEntryPointclass PlayActivity : AppCompatActivity() { /* ... */ }
class MusicApp : Application()
class PlayActivity : AppCompatActivity() { /* ... */ }
依存関係を注入するには、Hilt から注入したい変数に @Inject アノテーションを付けます。Hilt が注入したすべての変数は、super.onCreate が呼び出されたときに利用できるようになります。
@Inject
super.onCreate
@AndroidEntryPointclass PlayActivity : AppCompatActivity() { @Inject lateinit var player: MusicPlayer override fun onCreate(savedInstanceState: Bundle) { super.onCreate(bundle) player.play("YHLQMDLG") }}
class PlayActivity : AppCompatActivity() {
@Inject lateinit var player: MusicPlayer
override fun onCreate(savedInstanceState: Bundle) {
super.onCreate(bundle)
player.play("YHLQMDLG")
この例では、PlayActivity に MusicPlayer を注入しています。しかし、Hilt は MusicPlayer 型のインスタンスを提供する方法をどのようにして認識しているのでしょうか。実は、この段階ではまだ認識していません。 Hilt にその方法を伝えるためにアノテーションを使います。
PlayActivity
MusicPlayer
クラスのコンストラクタに @Inject アノテーションを付けることで、Hilt にそのクラスのインスタンスの作成方法を伝えることができます。
class MusicPlayer @Inject constructor() { fun play(id: String) { ... }}
class MusicPlayer @Inject constructor() {
fun play(id: String) { ... }
アクティビティへの依存関係の注入に必要なのは、これだけです。とても簡単でしたね。最初の例は簡単で、MusicPlayer は他の型に依存していません。しかし、他の依存関係がパラメータとして渡されると、Hilt はそれを管理し、MusicPlayer のインスタンスを提供する際にその依存関係を満たさなければなりません。
実は、ここで示した例はとても簡単で、単純すぎるものです。しかし、これを手動で行う場合、どうするかを考えてみてください。
手動で DI を行う場合、必要な型を提供し、提供するインスタンスのライフサイクルを管理する 依存関係コンテナ クラスを作ることが考えられます。つまり、まさに Hilt が内部で行っていることです。
アクティビティに @AndroidEntryPoint アノテーションを付けると、PlayActivity と関連付けられた依存関係コンテナが自動的に作成され、管理されます。手動で行うこの実装を PlayActivityContainer と呼ぶことにしましょう。MusicPlayer に @Inject アノテーションを付けることで、MusicPlayer 型のインスタンスの提供方法をコンテナに伝えます。
PlayActivityContainer
// PlayActivity annotated with @AndroidEntryPointclass PlayActivityContainer { // MusicPlayer annotated with @Inject fun provideMusicPlayer() = MusicPlayer() }
// PlayActivity annotated with @AndroidEntryPoint
class PlayActivityContainer {
// MusicPlayer annotated with @Inject
fun provideMusicPlayer() = MusicPlayer()
そしてアクティビティでは、コンテナのインスタンスを作成し、それを使ってアクティビティの依存関係を設定します。これも Hilt ではアクティビティに @AndroidEntryPoint アノテーションを付けることで処理してくれます。
class PlayActivity : AppCompatActivity() { private lateinit var player: MusicPlayer // Created by Hilt when annotating the activity with @AndroidEntryPoint private lateinit var container: PlayActivityContainer override fun onCreate(savedInstanceState: Bundle) { // @AndroidEntryPoint also creates and populates fields for you container = PlayActivityContainer() player = container.provideMusicPlayer() super.onCreate(bundle) player.play("YHLQMDLG") }}
private lateinit var player: MusicPlayer
// Created by Hilt when annotating the activity with @AndroidEntryPoint
private lateinit var container: PlayActivityContainer
// @AndroidEntryPoint also creates and populates fields for you
container = PlayActivityContainer()
player = container.provideMusicPlayer()
ここまで説明してきたのは、クラスのコンストラクタに @Inject アノテーションを付けると、そのクラスのインスタンスの提供方法を Hilt に伝えられることです。また、@AndroidEntryPoint が付いたクラスの変数にこのアノテーションを付けると、Hilt はその型のインスタンスをそのクラスに注入します。
@AndroidEntryPoint は、アクティビティだけでなく、ほとんどの Android フレームワーク クラスに追加できます。このアノテーションは、そのクラスの依存関係コンテナのインスタンスを作成し、@Inject アノテーションが付いたすべての変数を設定します。
Application クラスに付けられた @HiltAndroidApp アノテーションは、Hilt のコード生成をトリガーにするだけでなく、Application クラスに関連付けられた依存関係コンテナも作成します。
Application
Hilt の基本について理解できたので、もう少し複雑な例を見てみましょう。次の例では、MusicPlayer のコンストラクタが依存関係 MusicDatabase を受け取ります。
MusicDatabase
class MusicPlayer @Inject constructor( private val db: MusicDatabase) { fun play(id: String) { ... }}
private val db: MusicDatabase
) {
ここでは、MusicDatabase のインスタンスを提供する方法を Hilt に伝えなければなりません。型がインターフェースである場合や、例えばライブラリから提供されているために自分がクラスを所有していない場合は、コンストラクタに @Inject アノテーションを付けることはできません。
アプリで、永続化ライブラリとして Room を使っているとしましょう。再度、PlayActivityContainer を手動で実装する場合について考えてみます。MusicDatabase を提供するとき、Room を使うと MusicDatabase は抽象クラスになります。そのため、依存関係を提供するコードを実行します。次に、MusicPlayer のインスタンスを提供するときに、MusicDatabase の依存関係を提供する（または満たす）メソッドを呼び出す必要があります。
class PlayActivityContainer(val context: Context) { fun provideMusicDatabase(): MusicDatabase { return Room.databaseBuilder( context, MusicDatabase::class.java, "music.db" ).build() } fun provideMusicPlayer() = MusicPlayer( provideMusicDatabase() )}
class PlayActivityContainer(val context: Context) {
fun provideMusicDatabase(): MusicDatabase {
return Room.databaseBuilder(
context, MusicDatabase::class.java, "music.db"
).build()
fun provideMusicPlayer() = MusicPlayer(
provideMusicDatabase()
)
Hilt では、推移的依存関係について心配する必要はありません。Hlit はすべての推移的依存関係を自動的に取得しますが、MusicDatabase 型のインスタンスの提供方法を伝えておかなければなりません。これを行うために、Hilt のモジュールを使います。
Hilt のモジュールとは、@Module アノテーションが付いたクラスです。このクラスでは、ある型のインスタンスの提供方法を Hilt に伝える関数を作成できます。Hilt が認識するこの情報は、Hilt の専門用語で バインディング とも呼ばれます。
@Module
@Module@InstallIn(SingletonComponent::class)object DataModule { @Provides fun provideMusicDB(@ApplicationContext context: Context): MusicDatabase { return Room.databaseBuilder( context, MusicDatabase::class.java, "music.db" ).build() }}
@InstallIn(SingletonComponent::class)
object DataModule {
@Provides
fun provideMusicDB(@ApplicationContext context: Context): MusicDatabase {
@Provides アノテーションが付いた関数で、MusicDatabase 型のインスタンスの提供方法を Hilt に伝えています。関数本体には、Hilt が実行するコードのブロックが含まれており、先ほどの手動実装のコードとまったく同じものです。
戻り値の型が MusicDatabase となっているので、Hilt はこの関数が提供する型を認識できます。また、関数のパラメータから、対応する型の依存関係も認識できます。この例では、既に Hilt が利用できる ApplicationContext がパラメータになっています。このコードから、Hilt は MusicDatabase 型のインスタンスの提供方法を認識します。別の表現を使うなら、MusicDatabase の バインディング を取得したことになります。
ApplicationContext
Hilt のモジュールには、@InstallIn アノテーションも付いています。これは、この情報がどの依存関係コンテナやコンポーネントで利用できるかを示します。では、コンポーネントとは何でしょうか。この点について詳しく説明しましょう。
@InstallIn
Hilt が生成する コンポーネント クラスは、先ほど手動でプログラミングしたコンテナのように、型のインスタンスを提供する役割を担います。Hilt はコンパイル時にアプリケーションの依存関係グラフをたどり、すべての推移的依存関係の型を提供するコードを生成します。
Hilt が生成する コンポーネント クラスは、型のインスタンスを提供する役割を担う
Hilt は、ほとんどの Android フレームワーク クラスに対して、コンポーネント、つまり依存関係コンテナを生成します。各コンポーネントの情報（バインディング）は、コンポーネント階層を伝播します。
Hilt のコンポーネント階層
MusicDatabase バインディングが Application クラスに対応する SingletonComponent で利用できる場合、その他のコンポーネントでも利用できます。
SingletonComponent
これらのコンポーネントは、コンパイル時に Hilt によって自動生成されます。コンポーネントが作成、管理され、対応する Android フレームワーク クラスに関連付けられるのは、これらのクラスに @AndroidEntryPoint アノテーションを付けたときです。
モジュールの @InstallIn アノテーションは、そういったバインディングが利用できる場所や、利用できる他のバインディングを管理するうえで便利です。
再び、手動で作成した PlayActivityContainer コードについて考えてみます。気づいた方もいらっしゃるかもしれませんが、MusicDatabase の依存関係が必要になるたびに、別のインスタンスが作成されています。
アプリ全体で MusicDatabase の同じインスタンスを再利用したい場合もあるので、この動作は理想的ではありません。そこで、関数を使うのではなく、変数に格納すれば同じインスタンスを共有できます。
class PlayActivityContainer { val musicDatabase: MusicDatabase = Room.databaseBuilder( context, MusicDatabase::class.java, "music.db" ).build() fun provideMusicPlayer() = MusicPlayer(musicDatabase)}
val musicDatabase: MusicDatabase =
Room.databaseBuilder(
fun provideMusicPlayer() = MusicPlayer(musicDatabase)
つまり、MusicDatabase 型のスコープがこのコンテナに適用されるようにすることで、依存関係として常に同じインスタンスが提供されるようにしています。これを Hilt で行うには、どうすればよいでしょうか。もうおわかりと思いますが、ここでも別のアノテーションを使います。
@Provides メソッドに @Singleton アノテーションを付けると、そのコンポーネントでは常にこの型の同じインスタンスを共有するように Hilt に伝えることができます。
@Singleton
@Module@InstallIn(SingletonComponent::class)object DataModule { @Singleton @Provides fun provideMusicDB(@ApplicationContext context: Context): MusicDatabase { return Room.databaseBuilder( context, MusicDatabase::class.java, "music.db" ).build() }}
@Singleton はスコープ アノテーションです。それぞれの Hilt コンポーネントには、1 つのスコープ アノテーションが対応付けられています。
それぞれの Hilt コンポーネントのスコープ アノテーション
ある型のスコープを ActivityComponent にしたい場合、ActivityScoped アノテーションを使います。スコープ アノテーションはモジュールで利用できますが、コンストラクタに @Inject アノテーションが付いているクラスでも利用できます。
ActivityComponent
ActivityScoped
バインディングには次の 2 つのタイプがあります。
Hilt は、ViewModel、Navigation、Compose、WorkManager といった人気のある Jetpack ライブラリと統合されています。
ViewModel 以外と統合する場合は、別のライブラリをプロジェクトに追加する必要があります。詳細は、ドキュメントをご覧ください。このブログ投稿の冒頭で紹介した iosched の FeedViewModel コードを覚えているでしょうか。Hilt を使うと、どのようになるか見てみましょう。
@HiltViewModelclass FeedViewModel @Inject constructor( private val loadCurrentMomentUseCase: LoadCurrentMomentUseCase, loadAnnouncementsUseCase: LoadAnnouncementsUseCase, private val loadStarredAndReservedSessionsUseCase: LoadStarredAndReservedSessionsUseCase, getTimeZoneUseCase: GetTimeZoneUseCase, getConferenceStateUseCase: GetConferenceStateUseCase, private val timeProvider: TimeProvider, private val analyticsHelper: AnalyticsHelper, private val signInViewModelDelegate: SignInViewModelDelegate, themedActivityDelegate: ThemedActivityDelegate, private val snackbarMessageManager: SnackbarMessageManager) : ViewModel(), FeedEventListener, ThemedActivityDelegate by themedActivityDelegate, SignInViewModelDelegate by signInViewModelDelegate { /* ... */}
@HiltViewModel
class FeedViewModel @Inject constructor(
この ViewModel のインスタンスを提供する方法を Hilt に伝えるために、コンストラクタに @Inject アノテーションが付いています。その点を除けば、クラスに @HiltViewModel アノテーションを付けるだけです。
これでだけです！ViewModel のプロバイダを手動で作成する必要はありません。Hilt がそれを行ってくれます。
Hilt は、よく使われている別の依存関係インジェクション ライブラリ Dagger がベースになっています。今後のエピソードには、Dagger が頻繁に登場する予定です。現在 Dagger をご利用の場合、Dagger と Hilt は連携して動作できます。移行 API の詳細は、ガイド（英語）をご覧ください。
Hilt についてさらに詳しく知りたい方は、特によく使われるアノテーションやその効果、使用方法を説明したクイック リファレンス（英語）をご覧ください。Hilt のドキュメントのほかに、ハンズオン形式で学習できる Codelab も公開しています。
今回のエピソードは以上ですが、この話はこれで終わりではありません。MAD Skills シリーズはさらに続くので、Android Developers の Medium 記事 (英語) をフォローして、投稿されたときに確認できるようにしておきましょう。
この記事は Jonathan Koren による Android Developers - Medium の記事 " Trackr comes to the Big Screen " を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。
Trackr は、タスク管理のサンプルアプリです。Trackr の主な用途は、ユーザー補助をサポートする観点で一般的な UI パターンを確認できるようにすることですが、最先端の Android 開発におけるベスト プラクティスの実例にもなっています。先日、このアプリを大画面対応にしました。その際にマテリアル デザインやレスポンシブ パターンを適用することで、大画面デバイスで洗練された直感的なユーザー エクスペリエンスをどのように実現したのかをご紹介します。
変更前 : タスク一覧画面の下部にあるアプリバーのメニューから、アーカイブと設定にアクセスできました。大画面では、タッチのターゲットとなるメニュー コントロールが小さく、不便な場所にありました。また、下のアプリバーが伸びすぎていました。
左: スマートフォンのナビゲーション。右: タブレットのナビゲーション
変更後 : 画面が広い場合は、ナビゲーション レール (英語) を表示します。さらに、ナビゲーション レールにフローティング アクション ボタン（新規タスク画面を開きます）を表示し、下のアプリバーは完全になくしました。
大画面のナビゲーション レール
この変更は大画面デバイスを念頭に行いましたが、スマートフォンの横表示でも有効で、タスク一覧を表示する縦のスペースを広く使えるようになります。
横向きのスマートフォンのナビゲーション レール
変更前 : タスク一覧画面とアーカイブ画面が横幅いっぱいに広がり、項目をタップすると、一覧が項目の詳細に置き換わっていました。大画面では、UI 要素が引き伸ばされるか、片側に寄ってしまい、画面のバランスが悪く感じられました。
スマートフォンでは自然に見えるが、大画面では最適な形でスペースを利用できていない
変更後 : タスク一覧画面とアーカイブ画面の両方で、SlidingPaneLayout (英語) を使って一覧/詳細 UI を表示します。これを行う方法は、Google I/O アプリに対して行った変更に関する以前の記事 (英語) で解説していますので、技術的な詳しい説明に興味がある方は、ぜひご覧ください。
タスク詳細画面にもフローティング アクション ボタン（タスク編集画面を開きます）がありますが、ナビゲーション レールがある場合に 2 つのフローティング アクション ボタンが表示されることになるので、理想的ではありません。そこで、2 つ目のフローティング アクション ボタンは非表示にし、右上のツールバーに編集ボタンを追加します。
2 ペイン化で画面スペースを活用
変更前 : タスクを編集すると、タスク編集 UI がタスク詳細の代わりに表示され、画面全体を覆っていました。タスク詳細と同じく、画面のバランスが悪く感じられます。新規タスク UI でも同じ問題が発生していました（実は、新規タスクとタスク編集は、ナビゲーション グラフで同じ遷移先になっています）。
左: スマートフォンのタスク編集。右: タブレットのタスク編集
変更後 : 大画面では、DialogFragment を使って他のコンテンツの上にタスク編集 UI を表示します。
ユーザーが現在の目的に集中できるようにするフローティング UI
最初は、タスク詳細の代わりにこの UI を詳細ペインに表示することを考えました。その方が単純でしたが、次の理由により、このアプローチでは納得できないとすぐに感じました。
新規タスク UI は、タスク編集と同じパターンを利用
ここでの学びは、何も考えずにシンプルにデザインしてしまうと、実装してみると機能的におかしい可能性があるということです。そうなったときは、一歩下がってユーザー エクスペリエンスに注目し、ユーザー エクスペリエンスを向上させるデザイン パターンを探しましょう。
タブレットや折りたたみ式デバイスの人気は上昇しています。そのため、レスポンシブな UI を作ることの重要性がこれまでになく高まっています。ナビゲーション レールを追加したり、SlidingPaneLayout を使ったりすると、Trackr アプリの見栄えがよくなるだけでなく、ユーザビリティが劇的に向上し、スマートフォンにはないエクスペリエンスを実現できることをお見せしました。さらに、単に画面のスペースだけではなく、ユーザビリティに注目し、ユーザーのニーズを最大限に満たすことができるようなデザインの再考が必要になる場合があることもお伝えしました。
新たに改善された Trackr が気に入ってもらえることを期待しています。コードは github.com/android/trackr から確認できます。
この記事は Dave Burke による Android Developers Blog の記事 " Android 12 Beta 5 update, official release is next! " を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。
まもなく Android 12 が公式リリースを迎えます。現在、新バージョンの Android で最終調整を行っているところですが、皆さんのテストや開発に役立てていただくため、ベータ版の最終アップデートをお届けします。公式リリースに間に合うように、互換性のあるアプリやゲームへのアップデート準備をお願いいたします。
Beta 5 は 2021 年 9 月 8 日（日本時間 9 月 9 日) より、5G 対応の Pixel 5a を含む Pixel デバイスで利用できます。こちらから登録 (英語) すると、OTA（無線）アップデートを受け取ることができます。以前登録している方は、自動的に今回のアップデートを受け取ります。シャープなど、いくつかの主要メーカーの一部のデバイスでも Android 12 Beta 5 を試すことができます。使用を開始する方法についての詳細は、Android 12 デベロッパー サイトにアクセスしてください。
以下では、リリースが近づいてきた Android 12 公式版に関する情報をお伝えします。
2021 年 9 月 8 日（日本時間 9 月 9 日) のアップデートには、Pixel などのデバイスと Android Emulator 向けの Android 12 のリリース候補ビルドが含まれています。Beta 4 でプラットフォームの安定版に到達しているので、SDK や NDK API、アプリに面するシステムの動作、非 SDK インターフェースの制限など、アプリに面する部分はすべて完了しています。Beta 5 には、これらの機能と最新の修正および最適化が含まれており、テストを終えるために必要なものがすべてそろっています。
次に予定されているのは、Android 12 の公式リリースです。そのため、すべてのアプリやゲームのデベロッパーの皆さんに、最終リリース前に最終の互換性テストを終え、互換性アップデートを公開することをお願いします。SDK、ライブラリ、ツール、ゲームエンジン デベロッパーの皆さんは、できる限り早く互換性アップデートをリリースすることが重要です。下流のアプリやゲームのデベロッパーは、皆さんのアップデートを受け取るまで作業できないかもしれません。
アプリの互換性をテストするには、Android 12 Beta 5 が動作するデバイスにインストールし、アプリのフローを確認して機能や UI の問題を探します。Android 12 でのすべてのアプリが対象となる動作の変更点を確認し、影響を受ける可能性がある領域を集中的にテストしてください。特にテストしておくべき変更点は、以下のとおりです。
アプリのライブラリや SDK の互換性テストも忘れずに行ってください。SDK の問題を見つけた場合は、最新バージョンの SDK にアップデートするか、デベロッパーに連絡してサポートを受けるようお願いします。
現在のアプリの互換性のあるバージョンを公開したら、アプリの targetSdkVersion をアップデートするプロセスを開始できます。Android 12 をターゲットとするアプリの動作の変更点を確認し、互換性フレームワークを使って問題をすばやく検知します。
Android 12 には、優れたユーザー エクスペリエンスを構築する際に役立つたくさんの新機能が含まれています。Google I/O での Android 12 関連のセッションに関するまとめとリンクについては、Android 12 Beta 2 の投稿をご覧ください。すべての新しい機能と API の詳しい説明は、Android 12 デベロッパー サイトをご覧ください。
Android 12 の開発やテストには、ぜひ Android Studio Arctic Fox もお試しください。Android 12 の変更点によって影響を受ける可能性があるコードを特定しやすいように、lint チェックも追加しています。たとえば、スプラッシュ画面のカスタム宣言、高精度の位置情報の使用がリクエストされた際の大まかな位置情報の権限、メディア フォーマット、高センサー サンプリング レートの権限などです。ダウンロード (英語) と設定を行うと、最新版の Android Studio を試すことができます。
今回の Beta 5 のリリースには、Android 12 の機能を試し、アプリをテストしてフィードバックを提供するために必要なすべてのものが含まれています。サポート対象となっている Pixel デバイスを登録するだけで、OTA（無線）でアップデートを入手できます。また、Android 12 に対応したアプリの開発を行うために、Android 12 SDK をセットアップしてください。
シャープなど、いくつかの主要メーカーのデバイスでも、Beta 5 を試すことができます。さらに幅広くテストしたい場合は、Android GSI イメージで Beta 5 をお試しください。デバイスをお持ちでない場合は、Android Emulator でテストできます。今回のアップデートは Android TV でも利用できる (英語) ので、最新の TV 機能を確認したり、新しくなった Google TV エクスペリエンスでアプリをテストしたりできます。
もうすぐ予定されているAndroid 12 公式版リリースにご期待ください！それまでの間は、引き続きフィードバックをお寄せください。プラットフォームの問題、アプリの互換性の問題、サードパーティ SDK の問題の送信には、各ホットリストを使うことができます。
Android 12 リリースを形作ることに貢献してくださっているデベロッパー コミュニティの皆さんに深い感謝を捧げます。皆さんから寄せられたたくさんのバグレポートや、皆さんが共有してくれた知見は、API の調整や機能の改善、重大なバグの修正、そしてユーザーやデベロッパーにとってよりよいプラットフォームの実現に役立っています。ありがとうございます。
Android 12 に対応した皆さんのアプリを楽しみにしています。
この記事は 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 固有のライブラリもアップデートしています。パフォーマンスが大幅に改善されており、本日から試すことができます。
この記事は Tom Grinsted, Scott Lin, and Tat Yang Koh による Android Developers Blog の記事 " Making Ratings and Reviews better for users and developers " を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。
評価とレビューは重要です。皆さんが提供しているアプリやゲーム、その他さまざまなサービスについて、ユーザーが体験したことを報告してもらえるため、貴重な定量的、定性的フィードバックです。そしてそれは、ユーザーが Google Play で何をダウンロードするかを決める際の指標の 1 つにもなります。
Google Play ストアを利用しているユーザーとデベロッパーの皆さまから、評価とレビューの有用性をさらに向上させることができるという声をいただいています。特に、ある地域からの評価が全体に不当な影響を与える場合です。たとえば、1 つの国にのみ悪影響を及ぼすバグが全体の評価に影響してしまう場合や、タブレットでの体験が向上しているにもかかわらず、スマートフォンのユーザー数が多いため見落とされている場合などです。そこで、評価をパーソナライズして個々のユーザーに想定される体験を表せるように、またデベロッパーが簡単に評価を確認して利用できるように、今後数四半期にわたる改善プログラムを進めています。
多くのデベロッパーが、潜在的なユーザーが目にする評価を注視していることを私たちも理解しているので、今後の変更について皆さんに十分な案内を行うようにします。また、Google Play Console の機能強化も行い、特にフォーム ファクタ間の違いという点でも、評価やレビューを理解しやすくしました。
デベロッパーの皆さんが、ユーザーへのサポートをさまざまな種類のデバイスに拡大することは、ユーザー インターフェースにとって特に重要で影響の大きい変更です。タブレットに最適なレイアウトを追加したり、Chrome OS でマウスやキーボードのサポートを強化したりすると、ユーザー エクスペリエンスの質が段階的に変化し、それが評価やレビューに影響する可能性があります。
Google Play Console の評価の概要と内訳のページに、デバイスの種類による評価分析を新しく追加
さまざまなデバイス間でのチャンスを見つけやすくするため、また機能改善による変化を観測するため、デバイスの種類のディメンションを評価のページに新設しました。さらに、レビューにもデバイスの種類によるフィルタを追加し、タブレットのユーザーによる評価や、Chrome OS のユーザーによるレビューのコメントを簡単に確認できるようにしました。
多くのデベロッパーの方々から、これまで選択できたものよりも細かいデータにアクセスしたいという声が寄せられました。そこで、セグメンテーションのオプションを細かくし、さらに使いやすくしました。現在は、プロットしたい期間（直近 28 日からアプリの全期間まで）や評価データの集計方法（日ごと、週ごと、28 日ごと）を個別に選択できるようになっています。これにより、長期にわたる細かいデータを確認できるようになっています。
任意の時間範囲と集計期間を個別に選択し、必要な評価データを検索
加えて、平均データと評価の分布を CSV でダウンロードできるようにしました。これを新しいデータ選択オプションと組み合わせれば、多くのデータを簡単に照会してダウンロードし、オフラインで分析できます。たとえば、日ごとの評価の分布の履歴データをすべてダウンロードし、スプレッドシートでカスタマー サービスの連絡回数と関連付けることもできます。
概要ページから、評価の内訳を含む全データに直接アクセスしてダウンロードすることが可能
以上の変更点は、現時点ですべて Google Play Console に反映されています。評価の概要やレビューにアクセスすると、実際に確認できます。*
評価は、ユーザーがどのアプリをダウンロードするかを決める上で役立ちます。また、Google Play ストアでのおすすめや配置を決める上でも利用されます。しかし、アプリを通したエクスペリエンスはユーザーの地域やデバイスの種類によって異なる可能性があり、評価の総計が常に全体像を表すとは限りません。そこで、2021 年 11 月より、個々のユーザーに表示される評価を、ユーザーが登録した国や地域に応じた評価に変更する予定です。さらに今年中には、ユーザーが使用しているデバイスも考慮されます。
つまり、11 月以降、スマートフォンのユーザーには、自分が居住している国や地域に合わせた評価が表示されます。一例を上げると、日本のユーザーには、他の日本のユーザーが送信した情報から生成されたアプリの評価が表示されます。
来年初頭には、さらに評価をアップデートし、タブレット、折りたたみ式デバイス、Chrome OS、Wear、Auto など、ユーザーが Google Play を表示しているデバイスの種類が反映されます。これにより、ユーザーが使っているデバイスで想定されるエクスペリエンスについての情報が提供されるようになります。そのため、早い段階でフォーム ファクタの評価を確認することをお勧めします。特に、成長が著しいタブレットに注目し、ユーザー エクスペリエンスを最適化する投資を行うべきかを確認しましょう。
ユーザーに表示される評価が大きく変わる場合、デベロッパーの皆さんはそれを理解して先手を打ちたいと思うはずです。そのため、Google Play ストアで行われるすべての変更について、少なくとも 10 週間前に皆さんのアプリで想定される変更を自動分析し、主要なマーケット（ストアの掲載情報にアクセスしたユーザーが 5% を超えるマーケット）でいずれかの種類のデバイスの星が 0.2 個以上変化するデベロッパーに対して連絡いたします。これにより、アプリに大きな変更を加えたい場合でも、十分な時間を確保できればと考えています。
以上の Google Play 上の変更は、2021 年 11 月よりロールアウトし、国や地域に合わせた評価が表示されるようになります。これから年末までの期間中は、Google Play Console の受信トレイでの、評価に関するメッセージに注目してください。現在、既に国やデバイスの種類ごとで評価を確認できるようになっていることも忘れないようにしましょう。*
* リンクにアクセスするには、Google Play Console アカウントが必要です。
Reviewed by Naoki Oyama - Developer Support Lead, Google Play, APAC and Tamao Imura - Developer Marketing Manager, Google Play
2021 年 9 月 4 日 (土) に 4 回目を迎えた Indie Games Festival の、トップ 3、トップ 10、特別賞を決定するファイナル イベントが、オンラインで開催されました。
本記事ではスペースの都合上 、トップ 3 と特別賞のみご紹介しますが、トップ 20 各作品への審査員全員のコメントは、後日開発者の皆さんへ個別にイベント事務局からご連絡いたします。受賞された皆さま、改めておめでとうございます！
※（五十音順、敬称略）
安藤 武博
株式会社シシララ 代表取締役 ゲームDJ
成沢 理恵
monoAI technology株式会社、モリカトロン株式会社、ちゅらっぷす株式会社、株式会社ArAtA、RingZero株式会社、Amusement Asset Associates株式会社 / 取締役
株式会社モバイルファクトリー / 社外取締役
Zen Chao
Asobu / Founder
Makers Fund / Japan Lead
簗瀬 洋平
ユニティ・テクノロジーズ・ジャパン株式会社 クリエイター・アドボケイト（学術）
森 通治【集英社ゲームクリエイターズCAMP賞審査員】
株式会社集英社 新規事業開発部 ゲーム事業・映像事業開発課 ゲームクリエイターズCAMP プロデューサー
大島 孝幸【TOHO Games 賞審査員】
東宝株式会社 映像本部 映像事業部 部長
UUUM所属クリエイター SKJ Village【UUUM 賞審査員】
五十嵐 郁
Google Play Partnerships ゲーム部門 パートナー デベロップメント マネージャー
キム チョンサ
Google Play Partnerships ゲーム部門 日本統括部長
『サバイバーズ・ギルト』 への審査員からのコメント : 𥱋瀨 洋平
ゲーム開発は人の命に関わらないので気楽に最高の技術を注ぎ込めるのが良いところと思っていましたが、この作品でそれだけではない、むしろゲームというエンターテイメントには人の命を救うポテンシャルがあるのだと感じさせられました。
『時空運送』 への審査員からのコメント : 安藤 武博
令和の倉庫番！！操作のひとつひとつが小気味よくきもちがよく、1ターンずつ素早くアンドゥできるところもテンポ感を増していました。じっくり向き合いたいゲームです！
『ねずみバスターズ！』 への審査員からのコメント : 成沢 理恵
もし採点に「愛」という項目があったら、100点満点だと思います。セリフの言い回し、ありそうな日常風景と人物像、どこか癒されるグラフィック、すごく楽しませていただきました。
※（敬称略）
Odencat 株式会社
審査員からのコメント : 五十嵐 郁
この賞のポイントは世界で成功することを目標としているタイトルを後押しすることなので、作品として世界に通用するポテンシャルや、海外ユーザーを意識したゲーム作りの姿勢などが決め手となりました。
HAKOT
学生賞の審査の基準はトップ 20 と同じくゲームの楽しさやデザイン品質等を見ていますが、その意味でとてもクオリティが高く、非常に細かいところまでこだわっていてリアリティがありとても楽しめる作品でした。
審査員からのコメント : 大島 孝幸
総合的なクオリティが非常に高く、タワーディフェンス＋トランプゲームの組み合わせの発想も秀逸でした。ゲームサイクルも綺麗に繋がっており、操作感も良かったです。プレイヤーに与える報酬と試練のバランスも良く、チュートリアルも良く出来ているので、幅広いユーザーを獲得できる作品だと感じました。キャラクターやインターフェースのデザインも統一感があり、可愛いらしく魅力的な世界観を演出していて、ゲーム性も適度に複雑でやり込めるので、ユーザーの継続性も良いのではと感じました。
審査員からのコメント : 森 通治
シンプルなビジュアルで進むアドベンチャーで、まずストーリーが面白く、動きがまとまっているので、安心感を持って集中して進めてしまう。１時間で遊んでもらいたいという潔さもとても良いと思います。このチームの才能をどうマネタイズにしていくのかなど、一緒に考えていきたいです。
審査員からのコメント : SKJ Village
人狼と将棋を組み合わせる独創性・実際にアプリで戦っていく中でわかった中毒性、広がっていく未来があるゲームでした。ゲームがおもしろく、課金要素、大会など今後の展望が見えました。
『DroidKaigi』は、Android 技術情報の共有とコミュニケーションを目的に開催する、エンジニアが主役の Android カンファレンスです。Android 技術情報の共有とコミュニケーションを目的に、2021 年10 月 19 日(火)、20 日(水)、21 日(木)の 3 日間開催します。
『DroidKaigi 前夜祭』 では、2021 年に発表した Android/Google Play 関連の製品のお話や、I/O 以降に発表された製品・技術関連の最新情報などについてお話をします。参加人数に制限を設けておりませんので、お誘い合わせの上ご参加ください。
日時: 10 月 18 日 19 時〜 20 時 30 分
参加登録はこちら
MC：
日高 正博 一般社団法人DroidKaigi 代表理事・株式会社メルペイ エキスパートチーム・技術書典 主宰
スピーカー:
荒木 佑一 Android Developer Programs Engineer (Google)
萩倉 健支 Android Developer Programs Engineer (Google)
Saryong Kang Developer Advocate (Google)
DroidKaigi 本イベントへも併せてご登録・ご参加ください！
日時: 2021 年 10 月 19 日(火)、20 日(水)、21 日(木)の 3 日間
Written by Tamao Imura - Developer Marketing Manager, Platforms and Ecosystems
この記事は Jeremy Walker による Android Developers Blog の記事 " Sharing Tiles with your smartwatch users: " を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。
タイル (英語) は、ウォッチフェイスのホーム画面をスワイプするだけで情報やアクションにすばやくアクセスする機能を提供いたします。これにより、スマートウォッチ ユーザーはどんな情報やアクションを表示するかを細かく制御できます。Wear OS を実行するスマートウォッチで、タイルが特に便利で役立つ機能の 1 つとなっていることも不思議ではないでしょう。
2021 年 8 月 11 日（日本時間 8 月 12 日）に、スマートウォッチ ユーザーとタイルを共有できることを発表いたしました。Jetpack Tiles API の最新のアルファ リリースをダウンロードすると、カスタムタイルを作成できます。作成したタイルを含むアプリを Google Play にアップロードすると、ユーザーはタイルをダウンロードして使い始めることができます。新しい体験を試せるようになったことをユーザーにもお知らせしましょう。Google Play Console で、Google Play ストアのプレビュー 用アセットにタイルのスクリーンショットをアップロードすることもできます。
Calm や 睡眠サイクル などのアプリは、既にカスタムタイルの作成を始めています。
「API はわかりやすく、ドキュメントもとても明確でした。そのため、わずか数時間で、実データを使って最初のタイルを動作させることができました。気軽に使ってみることができる最新の API だと感じています」 - 睡眠サイクル のTechnical Lead、Viktor Åkerskog
ディベロッパーの皆さんからのアルファ版ライブラリへのフィードバックには大変感謝しています。皆さんから頂いた多くのリクエストやパフォーマンスの改善を今回の API に含めました。追加のフィードバックはこちら (英語)からお送りください。今後のリリースに向けて、API の改善の優先順位を決めるうえで役立ちますので、ご協力をお願いいたします。
まだ API を試していない方はこちらのガイドをチェックしてください。チュートリアルを体験してみたい方はタイルの Codelab をお試しください。
それでは、コーディングをお楽しみください。
Reviewed by Saryong Kang - Partner Developer Advocate, Developer Relations Team
