Fragmentの使い方が誤っていないかをチェックする FragmentStrictMode について簡単に紹介します。

Fragment 1.4.0-alpha02で導入されています。
（今回は1.4.0-alpha03で検証しています。

android.os.StrictMode のFragment版という感じになります。

誤りを検出してLog出力する

簡単な例として、 <fragment> タグを使用してる場合にログ出力する実装です。

FragmentStrictMode.Policy を作って、それを setDefaultPolicy でセットしている感じになります。
実装はApplicationクラスで設定しておくと良いともいます。

Policyについてはいくつかありますが、どういったのがあるかは後ほど紹介ます。

もし、レイアウトxmlで <fragment> を使ってる箇所がある場合は、以下のようなログが出力されるようになります。

Fragment 1.4.0-alpha01 よりMultiple back stacksの対応が導入されました。この対応で新しいAPIが追加されてるので、使い方と振る舞いについて見ていきます。

おそらく、基本的に直接これらのAPIを使うことはなく Navigation Component を通して使うことが多いと思います。

注意

まだリリース直後のalpha01で試しているため、今後変更がある可能性が高いです。

新しいAPI

saveBackStack と restoreBackStack のAPIが新たに追加されていて、これらを使ってMultiple back stacksを実現していきます。

saveBackStack

こちらのAPIは addToBackStack で指定した名前を使用します。挙動としては popBackStack と同じような動作になりますが、あとから復元できるようにBack stackを保存します。

restoreBackStack

saveBackStack で保存したBack stackをあとから復元してFragmentを再表示します。

ドキュメントではBack stackを保存という記述になっていますが、個人的にはdetach/attachに近いのかなって思っています。

使用方法

使用例をいくつか見ながら説明していきます。

例1

まずは単純に2つのFragment使用します。

で、そのあとに、 saveBackStack で Back stackを保存します。

supportFragmentManager.saveBackStack("backstack1")

この結果を図にすると以下のようになります。

状態管理する方法は色々ありますが、UiStateという状態を一つのclassでまとめて管理する方法を紹介します。
（UiStateの他にはUiModel, ViewStateなど色んな呼び方を見かけます）

UiStateでも大きく2つやり方があるかなと思っています。
sealed class を使ったやり方と data class を使ったやり方です。

sealed class を使った管理

sealed class を使って画面が取り得る状態を定義して、必要なデータは各継承クラスのプロパティに持たせる方法です。

以下のコメントに書いてる通り、各状態を sealed class を継承した data class や object で表現しています。

ViewModelではこれを StateFlow や LiveData を使って状態ごとに更新していきます。

Activity/Fragment ではこの変更を受け取れるように実装していきます。

このやり方はAndroid Developerのドキュメントでもやっていたりします。

https://developer.android.com/kotlin/flow/stateflow-and-sharedflow

問題点

ぼく個人としてはこのやり方はいくつか問題点があり、あまりやりたくはない方法になります。

上の例で示したとおり、画面全体の状態を表しているので、ちょっと複雑な画面などすぐに破綻します。
例えば、画面にお気に入りボタンがあったりした場合などは、 sealed class の継承するものがどんどん増えていきます。

画面の更新についても、画面全体の状態と表すのでUIを更新する際に冗長になり、またミスが増え要因になるように思えます。
以下に例を示しますが、画面全体の状態ごとにすべてのUIの状態を設定する必要があります。

また、DataBindingをシンプルに使用することができません。

data class を使った状態管理

次に単純な data class を使って管理する方法です。

sealed class のように画面全体の表現するのではなく、UIを表現するのに必要なものをプロパティとして定義するイメージです。

ViewModelは以下のように StateFlow や LiveData を使いつつ copy メソッドで変更したいプロパティのみを更新していきます。

Kotlin 1.2.30からあった inline class がこれまではExperimental/Betaでしたが、1.5でStableになり value class に変更になります。inline class もまだ使えますが警告が表示されます。

この value class についてまとめておきます。

構文

@JvmInline
value class UserId(val id: Int)

構文としては data class に似ています。 value class というのを使って宣言します。

value class には以下の制約があります。

• 単一のプロパティしか持てない
• mutableなプロパティを持てない ( var を使ったプロパティが宣言できない)
• 参照の比較はできない ( === を使っ …

既存のViewシステムのSpanと同様にJetpack Composeでもテキストの一部を装飾することができるので、実装方法を紹介します。

AnnotatedString というのを使って実現します。

簡単な実装

これを実行すると以下のような表示になります。

実装をみれば勘の良い方はすぐ理解できると思います。

buildAnnotatedString 関数のブロックで色々を設定していくことになります。実際には AnnotatedString.Builder を扱いやすくしたものになります。

withStyle を使ってスタイルを指定して、そのブロック内で装飾したい文字列を append で追加していきます。

withStyleを使わずに appendをした場合は、 Text Composable関数で指定したスタイルが適用されます。

スタイルには SpanStyle と ParagraphStyle が使えます。違いとしては文字単位に適用するか、段落単位で適用するかになります。

テキストの一部をクリック可能にする

テキストの装飾とあわせて、テキストの一部をクリックに対応したい場合があります。例えば、テキスト中にリンクがある場合などですね。

実装は以下のようになります。

実行結果は以下のようになり、Androidの箇所をクリックするとブラウザが開きます。

Jetpack Composeにおいて状態が変化したときにUIに反映するRecompositionという仕組みがあります。Recompositionでは変更された状態のみComposable関数を実行しますが、その判断にはソースコードの呼び出し箇所によって識別されます。

Listのようにループを使って実行する場合には、その順番とインスタンスからRecomposition対象なのかを判断します。そのためListの変更が起きた場合に不要なRecompositionがことがあります。

Listの変更によるRecompositionがどのように実行されるか、それを効率よく行う方法を見ていきます。

実装例

例として以下のようなコードで試してきます。

Todoというdata classのListを一覧表示する例です。

使用されてるListは以下のような感じでStateとして扱えるようにして、TodoListというComposable関数に渡している状態です。

Listの末尾にデータを追加

こんな感じでListの末尾にデータが追加された場合についてです。

Androidのバージョンアップとともに、フルスクリーン画面を実現する方法が変更されてきたので、まとめておきます。
さらに次のAndroid 12でも一部変更が入りそうな気配です。

これまでの対応方法

Android 4.0 以下

テーマ (Theme.Holo.NoActionBar.Fullscreen)もしくは Window.setFlags で実現していました。

window.setFlags(
    WindowManager.LayoutParams.FLAG_FULLSCREEN,
    WindowManager.LayoutParams.FLAG_FULLSCREEN
)

ただ、この FLAG_FULLSCREEN はAPI Level 30からはDeprecatedになっています。

Android 4.1以降、Android 10 以下

Android 4.1以降では、 setSystemUiVisibility を使って実現していました。

window.decorView.systemUiVisibility = View.SYSTEM_UI_FLAG_FULLSCREEN

setSystemUiVisibility ではステータスバーの他にもナビゲーションバーも非表示にすることができるようになっています。

Immersiveモードも導入されています。

setSystemUiVisibility もAPI Level 30からはDeprecatedになっています。

上記のとおり、いずれの方法もDeprecatedになっているため、今後は別の方法で実現する必要があります。

Android 11の対応方法

Android 11 (API Level 30) から WindowInsetsController というのが追加されています。今後はこちらを使って対応していくことになります。

binding.root.windowInsetsController?.run {
    hide(WindowInsets.Type.systemBars())
}

hide メソッドに隠したい WindowInsets.Type を設定することで実現できます。上の systemBars を使うとステータスバーとナビゲーションバーを両方を消すことが出来ます。
ナビゲーションバーは表示したままで、ステータスバーだけを消したい場合は、 hide(WindowInsets.Type.statusBars()) で実現できます。

あとから表示したい場合は show メソッドを同じように使用することで再び表示できます。

実行するタイミングですが、 onCreate 等の一回しか実行されない箇所でやってしまうとホーム画面から戻ったときにそのまま表示されたままになるので、 onResume 等でやるほうが良いでしょう。

systemBarsBehavior

systemBarsBehavior にてステータスバーやナビゲーションバーの再表示の挙動を指定することができます。

• BEHAVIOR_SHOW_BARS_BY_TOUCH: 画面をタップなどのユーザーが何かしら操作したときに表示されます。（デフォルト）
• BEHAVIOR_SHOW_BARS_BY_SWIPE: 画面の上か下をスワイプすると表示されます。
• BEHAVIOR_SHOW_TRANSIENT_BARS_BY_SWIPE: こちらも画面の上から下をスワイプすると表示されますが、表示後にしばらくすると自動でまた非表示になります。Sticky immersiveのような動きになります。

Android 12からの対応

これを書いてる時点ではAndroid 12はDeveloper Preview2ですが、すでに変更が入るようです。

systemBarsBehavior に設定する値に変更が入ります。まだDeveloper Preiewなので更に変更があるかもですが、注意が必要です。

BEHAVIOR_SHOW_BARS_BY_SWIPE はDeprecatedになり、 BEHAVIOR_DEFAULT に変更され、BEHAVIOR_SHOW_BARS_BY_TOUCH はDeprecatedなるため今後は使用しないほうがよくなります。

Jetpackの対応

androidx coreの1.5.0-alpha05から WindowInsetsController のバックポートである、 WindowInsetsControllerCompat が追加されています。

しかし、これを書いてる時点ではバグがあり、BEHAVIOR_SHOW_TRANSIENT_BARS_BY_SWIPE が期待通りの挙動になりません。DeprecatedになったSYSTEM_UI_FLAG_IMMERSIVE の代わりにを使うようにドキュメントに記載されていますが、同様の挙動にはなっていないようです。

詳しくは こちらのIssue を見てください。

ドキュメント関連

WindowInsetsController のAPIドキュメントはありますが、これを書いてる時点では、ガイドはありませんでした。

古いガイドのほうは、まだ残っています。

https://developer.android.com/training/system-ui

参考

Jetpack ComposeにおいてUIの下位階層にデータを渡すには、Composable関数に引数を渡していくのが一般的だと思います。

引数で渡す以外の方法として、CompositionLocal があります。

これの使い方について解説します。

注意事項

先に CompositionLocal に関する注意事項を書いておきます。

CompositionLocal はほとんどケースでは使わなくて良いものです。グローバル変数のように見えるため乱用するとメンテンスが難しくなったりバグを引き起こしやすくなったりする可能性があります。

一部ケースで有用なものですが、使用する際は十分に注意してください。

実装方法

例として、User情報を下位階層に渡したい場合を実装していきます。

まず compositionLocalOf を使ってCompositionLocal のキーを作成します。

型パラメータとして下位階層に渡したい型を指定し、引数の関数にはデフォルトの値を指定します。この例では、もし渡されてなかった場合はエラーにしています。

次に CompositionLocalProvider を使って実際にUserの情報を提供します。

compositionLocalOf で作ったキーに対して provides を使って実態を渡します。分かりにくいですが、provides はinfix関数になっていて、 ProvidedValue を生成するようになっています。

最後に渡された値を取得します。

上のようにキーのcurrentからいつでもUserの情報が取得できるようになります。

もし、 CompositionLocalProvider で渡してない場合は、compositionLocalOf で指定したデフォルトが使用されますが、今回はエラーになるようにしています。

提供されてるCompositionLocal

特に意識しなくても使えるようになってる CompositionLocal がいくつかあります。androidx.compose.ui.platform にLocal~みたいな名前で定義されています。

https://developer.android.com/reference/kotlin/androidx/compose/ui/platform/package-summary

よく使いそうなものでいうと、 Contextが取得できる LocalContext や、URLを開くことができる LocalUriHandler があります。

参考

https://developer.android.com/reference/kotlin/androidx/compose/runtime/CompositionLocal

おまけ

ぼくが思いついた便利な使い方としてはNavigation Composeと組み合わせた使い方です。

まず画面遷移のメソッドを定義したinterfaceをつくります。

CompositionLocal のキーを作ります。

先程のNavigatorを実装したクラスをつくります。