【Jetpack Compose】NavBackStackEntry - Composable のライフサイクルと ViewModel の状態を確認する

NavBackStackEntry Lifecylecle State

 

■ きっかけ

普通に、トップレベルの Composable内で State/Flow/StateFlow を返す ViewModel に接続します。


Composable ↔ ViewModel (↔ Repository)

👉 Hilt と Navigation

一般的な NavHostController を使う場合には、それは NavBackStackEntryインスタンス となり 一つの Activity の上にスタック上に積まれていく。

👉 Composable の LifecycleOwner は誰なのか - collectAsStateWithLifecycle


NavBackStackEntry3 - Composable3 ↔ ViewModel3 
NavBackStackEntry2 - Composable2 ↔ ViewModel2
NavBackStackEntry1 - Composable1 ↔ ViewModel1
Activity

ライフサイクル上、Activity と NavBackStackEntry との関係は良さそうです。

外側のActivityやFragmentがonStop状態になっていればこのNavBackStackEntryのlifecycleはCREATED状態になってくれていそうにみえます。

👉 ComposeNavigationで使えるNavBackStackEntryのlifecycleとは？
👉 NavBackStackEntryのLifecycleについて | by Kenji Abe | Medium

Flow を扱う ViewModel と、

スタックされる NavBackStackEntry (Screen-Level Composable) のライフサイクル。

気になります。

目視したいです。

遷移によっては同じ Composable がスタックに積まれていくのもキモいし。

 

■ 方法

ViewModel の生き死には、


class TodoViewModel @Inject constructor(
) : ViewModel() {

  init {
    // log
  }

  override fun onCleared() {
    // log
  }

}

で確認します。

👉 ViewModel はいつ生まれていつ死ぬか 【→ Jetpack Compose】

Composable - NavBackStackEntry のライフサイクルは、


LifecycleEventObserver { _, event ->
  // log event
}

を使います。hash 付けてます。

👉 DisposableEffect: クリーンアップが必要な作用

遷移先となる Composale に貼ります。


@Composable
fun TodoScreen(
  viewModel: TodoViewModel = hiltViewModel()
) {

  LocalLifecycleStateLogger(" TodoScreen") // *




@Composable
fun PokeScreen(
  viewModel: TodoViewModel = hiltViewModel()
) {

  LocalLifecycleStateLogger(" PokeScreen") // *

ついでに、これらの親となる NavHostController をセットしている Composale にも貼ります。


@Composable
fun MainScreen() {
  SystemUi(rememberSystemUiController())

  LocalLifecycleStateLogger(screenName = "MainScreen") // *

  val navHostController = rememberNavController()

 

■ 結果

BottomNavigation をつかっていますが、スタックや saveState の設定はデフォルトのままなので、navigation を使っている場合は同様ではないかと思います。


アプリ起動

  ↓ ① click

TodoScreen

  ↓ ② click

PokeScreen

  ↓ ③ click

TodoScreen

  ↓ ④ back

PokeScreen

  ↓ ⑤ back

TodoScreen

  ↓ ⑥ back

アプリ終了



ログ出力結果。


D: @@@ MainScreen - MainActivity@a542ab9 -> ON_CREATE
D: @@@ MainScreen - MainActivity@a542ab9 -> ON_START
D: @@@ MainScreen - MainActivity@a542ab9 -> ON_RESUME
D: @@@  TodoViewModel@abae21d initialized.
D: @@@  TodoScreen - NavBackStackEntry@8ad648d7 -> ON_CREATE
D: @@@  TodoScreen - NavBackStackEntry@8ad648d7 -> ON_START
D: @@@  TodoScreen - NavBackStackEntry@8ad648d7 -> ON_RESUME
D: @@@  TodoScreen - NavBackStackEntry@8ad648d7 -> ON_PAUSE
D: @@@  TodoScreen - NavBackStackEntry@8ad648d7 -> ON_STOP
D: @@@  PokeViewModel@ad0cefd initialized.
D: @@@  PokeScreen - NavBackStackEntry@4049e1c3 -> ON_CREATE
D: @@@  PokeScreen - NavBackStackEntry@4049e1c3 -> ON_START
D: @@@  PokeScreen - NavBackStackEntry@4049e1c3 -> ON_RESUME
D: @@@  PokeScreen - NavBackStackEntry@4049e1c3 -> ON_PAUSE
D: @@@  PokeScreen - NavBackStackEntry@4049e1c3 -> ON_STOP
D: @@@  TodoViewModel@577b5b1 initialized.
D: @@@  TodoScreen - NavBackStackEntry@f1d51055 -> ON_CREATE
D: @@@  TodoScreen - NavBackStackEntry@f1d51055 -> ON_START
D: @@@  TodoScreen - NavBackStackEntry@f1d51055 -> ON_RESUME
D: @@@  TodoScreen - NavBackStackEntry@f1d51055 -> ON_PAUSE
D: @@@  TodoScreen - NavBackStackEntry@f1d51055 -> ON_STOP
D: @@@  PokeScreen - NavBackStackEntry@4049e1c3 -> ON_CREATE
D: @@@  PokeScreen - NavBackStackEntry@4049e1c3 -> ON_START
D: @@@  TodoScreen - NavBackStackEntry@f1d51055 -> ON_DESTROY
D: @@@  TodoViewModel@577b5b1 onCleared.
D: @@@  PokeScreen - NavBackStackEntry@4049e1c3 -> ON_RESUME
D: @@@  PokeScreen - NavBackStackEntry@4049e1c3 -> ON_PAUSE
D: @@@  PokeScreen - NavBackStackEntry@4049e1c3 -> ON_STOP
D: @@@  TodoScreen - NavBackStackEntry@8ad648d7 -> ON_CREATE
D: @@@  TodoScreen - NavBackStackEntry@8ad648d7 -> ON_START
D: @@@  PokeScreen - NavBackStackEntry@4049e1c3 -> ON_DESTROY
D: @@@  PokeViewModel@ad0cefd onCleared.
D: @@@  TodoScreen - NavBackStackEntry@8ad648d7 -> ON_RESUME
D: @@@  TodoScreen - NavBackStackEntry@8ad648d7 -> ON_PAUSE
D: @@@ MainScreen - MainActivity@a542ab9 -> ON_PAUSE
D: @@@  TodoScreen - NavBackStackEntry@8ad648d7 -> ON_STOP
D: @@@ MainScreen - MainActivity@a542ab9 -> ON_STOP

ログから 各Screen = NavBackStackEntry のスタック状態を考えます。


  -

  ↓ ① click

 TodoScreen1 ↔ TodoViewModel1
MainScreen1 - MainActivity

  ↓ ② click

 PokeScreen1 ↔ PokeViewModel1
 TodoScreen1 ↔ TodoViewModel1
MainScreen1 - MainActivity

  ↓ ③ click

 TodoScreen2 ↔ TodoViewModel2
 PokeScreen1 ↔ PokeViewModel1
 TodoScreen1 ↔ TodoViewModel1
MainScreen@1 - MainActivity

  ↓ ④ back

 PokeScreen1 ↔ TodoViewModel2
 TodoScreen1 ↔ TodoViewModel1
MainScreen1 - MainActivity

  ↓ ⑤ back

 TodoScreen1 ↔ TodoViewModel1
MainScreen1 - MainActivity

  ↓ ⑥ back

  -

それぞれの NavBackStackEntry のライフサイクルと ViewModel の状態が確認できました。

ホストの Composable のライフサイクルオーナーは、Activity であることも分かりました。

画面が遷移していくと、NavBackStackEntry はスタックされていき、 back (戻る操作) すると、NavBackStackEntry は ON_DESTROY され、スタックから取り除くかれ、それに対応する ViewModel も onCleard() されていきます。

なんとなく思うのは、今現在としては、ViewModel は、やっぱりあったほうがいいように思います。

👉 【Jetpack Compose】 ViewModel を捨てて Repository を Composable に直結する

そのうち、


hiltViewModel<ViewModel>()

のように、Reposiitory や DataProvider を注入する

androidx.hilt.navigation.compose メソッドやアノテーションが出れば嬉しいです。


👉 Jetpack Compose without ViewModel / Twitter hatena-bookmark

👉 Jim Sproch (@JimSproch) - Jetpack Composeのコンポーネントはなぜ返り値がないのか - Blog - Mori Atsushi hatena-bookmark

もうこれは「UIもマルチスレッドな時代になった」と言っていいんすかね。

👉 User interface frameworks typically are single-threaded. Why is this so and what are the performance implications of this single-threading? - Quora hatena-bookmark
👉 Are Multiple UI Threads Possible? | Apple Developer Forums hatena-bookmark

(つづく...)

【Jetpack Compose】ViewModel を捨てて Repository を Composable に直結する

 

気になるのはライフサイクル。

 

きっかけ

フル Compose でよくあるTodoのようなメモのようなアプリを作ってみました。

一通りの機能は実装しました。




👉 Jetpack Compose without ViewModel #shorts - YouTube hatena-bookmark

いろいろ Compose を試しながら進んでいくと ViewModel がスカスカになりました。


@HiltViewModel
class TodoViewModel @Inject constructor(
  private val repository: TodoRepositoryInterface
) : ViewModel() {

  val items: Flow<List<Todo>> = repository.load()

  fun insert(text: String) = repository.insert(text)

  fun update(id: Long, text: String) = repository.update(id, text)

  fun delete(id: Long) = repository.delete(id)

}

ViewModel いらなくね?

ViewModel を省略して、Repository を直結します。

 

結果

以下、少しの書き換えで問題なく動きます。


@Composable
fun TodoScreen(
  //viewModel: TodoViewModel = hiltViewModel()
  repository: TodoRepository = TodoRepository(
    Database(
      AndroidSqliteDriver(
        schema = Database.Schema,
        context = LocalContext.current,
        name = "database.db"
      )
    )
  )
) {




//val items by viewModel.items.collectAsState(initial = emptyList())
val items by repository.load().collectAsState(initial = emptyList())




//viewModel.insert(target.text)
repository.insert(target.text)




//viewModel.update(target.id, target.text) 
repository.update(target.id, target.text)




//viewModel.delete(target.id)
repository.delete(target.id)




//viewModel.delete(target.id)
repository.delete(target.id)

画面回転問題なし、メモリーリークもありません。

すんなりです。

Square製 SQLDelight + Flow(coroutine extension) を使っていますが、

Room + LiveData でもいけると思います。

Composable で Flow(LiveData) を受け取った瞬間に、

collectAsState(ObserveAsState) で State に変換できるんなら、

それのほうが良くね?

ライフサイクルの差も気にしなくていいし。

しかし、緩衝国がなくなるのはなんだか不安です。

Hilt で @Singleton で、ぶち込んでやりたかったです。

あ、でもこれ、 re-compose のたびに、Repository インスタンスが...

(つづく...)

👉 「SwiftUIでMVVMを採用するのは止めよう」と思い至った理由 - Qiita hatena-bookmark
👉 ViewModel はいつ生まれていつ死ぬか 【→ Jetpack Compose】 hatena-bookmark
👉 Jetpack ComposeとViewModelについて考える - Blog - Mori Atsushi hatena-bookmark

【Jetpack Compose】よくあるボタンの有効化/無効化

読み込み待ち、SwipeRefresh などで見かけるやつ。

ボタン2度押し対策にも使えます。


// @Composable

val sending by viewModel.sending

Button(
  onClick = { 
    viewModel.send() 
  },
  enabled = !sending
) {
  Text("SEND")
}




// ViewModel

private val _sending = mutableStateOf(false)
val sending: State<Boolean> = _sending // *

fun send() {
  viewModelScope.launch(Dispatchers.IO) {
    _sending.value = true
    delay(5000) // heavy
    _sending.value = false
  }
}

【Jetpack Compose】 よくあるボタンの有効化/無効化

ViewModel から露出している sending は State<Boolean> として @Composable 側からの書き換えは許しません。

Navigation 3 時代の「二重遷移」を防ぐ正しい方法 - dropUnlessResumed は debounce ではない
Android アプリでボタンを素早く連打すると、同じ画面が何度も積み重なってしまうことがあります。 Home
android.benigumo.com

👉 【Jetpack Compose】rememberCoroutineScope() vs LaunchedEffect hatena-bookmark

👉 【MVVM】 ViewModel の_プロパティ記述 hatena-bookmark
👉 StateFlow の View への公開 hatena-bookmark

👉 Jetpack Compose 二度押しを避けるボタン | Zenn hatena-bookmark

【Jetpack Compose】TextField の フォーカス と IME 開閉 と カーソル位置

 

TextField を使うときのあれこれ、Jetpack Compose ではどう書くのか。

【Jetpack Compose】TextField の フォーカス と IME 開閉 と カーソル位置

 

キーボードの開閉

それらしいクラスやメソッドがあります。フォーカスが当たっていれば使えます。


val keyboardController = LocalSoftwareKeyboardController.current
keyboardController?.show()
keyboardController?.hide()

フォーカスを当てたり外したりすることのみでも、IMEを開閉できるので今回は無視します。

 

フォーカスを当てる

FocusRequester を使います。


val focusRequester = remember { FocusRequester() }

focusRequester を TextFiled に仕込みます。


TextField(
  modifier = Modifier.focusRequester(focusRequester)
)

それを Button クリックでフォーカスします。


Button(
  onClick = { focusRequester.requestFocus() }
) {
  Text("SHOW IME")
}

フォーカスと同時にIMEも開きます。

compose 時に当てたいときは、


LaunchedEffect(Unit) {
  focusRequester.requestFocus()
}

 

フォーカスを外す

同様に、FocusRequester でやれると思ったら、できません。

LocalFocusManager を使います。


val focusManager = LocalFocusManager.current

フォーカスを外してくれます。

同様に、ボタンに仕込みます。


Button(
  onClick = { focusManager.clearFocus() }
) {
  Text("HIDE IME")
}

これも、フォーカスを外すと同時にIMEが閉じます。

 

カーソルの位置

文字の入った TextField にフォーカスしてIMEが開いたときは、編集です。

文字の最後尾にカーソルがあったほうがいい気がします。

TextFieldValue を使います。


TextFieldValue(
  text = text,
  selection = TextRange(text.length)
)

selection がカーソルの位置です。

text の長さを数えて置きます。日本語でもいけます。

 

まとめ

以下で検証してみました。


@Composable
fun SampleScreen() {

  var text by remember { mutableStateOf("あいうえお") }

  val focusManager = LocalFocusManager.current
  val focusRequester = remember { FocusRequester() }

  Column(
    Modifier.fillMaxSize(),
    Arrangement.Center,
    Alignment.CenterHorizontally
  ) {

    Text(text)
    Spacer(Modifier.height(16.dp))
    Row {
      Button(
        onClick = { focusRequester.requestFocus() }
      ) {
        Text("SHOW IME")
      }
      Spacer(Modifier.width(24.dp))
      Button(
        onClick = { focusManager.clearFocus() }
      ) {
        Text("HIDE IME")
      }
    }
    Spacer(Modifier.height(16.dp))
    CustomTextField(
      text = text,
      focusRequester = focusRequester,
      onChange = { changed ->
        text = changed
      }
    )

  }
}

@Composable
fun CustomTextField(
  text: String,
  focusRequester: FocusRequester,
  onChange: (String) -> Unit
) {

  var textFieldValue by remember {
    mutableStateOf(
      TextFieldValue(
        text = text,
        selection = TextRange(text.length)
      )
    )
  }

  TextField(
    value = textFieldValue,
    onValueChange = { changed ->
      textFieldValue = changed
      onChange(changed.text)
    },
    modifier = Modifier.focusRequester(focusRequester)
  )

}

【Jetpack Compose】TextField の フォーカス と IME 開閉 と カーソル位置

Compose の SideEffect や coroutineScope など、非同期処理系は悩ましくなりそうです。

Kotlin 今どきよくある JSON リクエストからのパース

数年で一気に変わってます、JSONの取り扱い処理。

Gson も Moshi も不要です。

Kotlin 内蔵の serialization を使うのが良いでしょう。

👉 Kotlin/kotlinx.serialization: Kotlin multiplatform / multi-format serialization hatena-bookmark


@Provides
@Singleton
fun provideRetrofit(okHttpClient: OkHttpClient): Retrofit {
  val contentType = "application/json".toMediaType()
  val json = Json { 
    ignoreUnknownKeys = true
    isLenient = true
  } // *
  return Retrofit.Builder()
    .client(okHttpClient)
    .baseUrl(BASE_URL)
    .addConverterFactory(json.asConverterFactory(contentType))
    .build()
}

処理時に便利に設定を変えられるようになっているので、

よくあるやつを並べておきます。

https://api.cryptowat.ch/markets/prices
👉 【仮想通貨】Cryptowatch Public Market REST API を眺める hatena-bookmark

 

ignoreUnknownKeys = true

デフォルトでは、逆シリアル化中に不明なキーが検出されるとエラーが発生します。 これを回避し、ignoreUnknownKeysプロパティをtrueに設定することで、このようなキーを無視できます。

👉 kotlinx.serialization/json.md at master · Kotlin/kotlinx.serialization hatena-bookmark

公開されている WEB-API には不要なデータがたくさんあります。

それを無視するための設定です。

 

isLenient = true

デフォルトでは、JsonパーサーはさまざまなJSON制限を強制して、可能な限り仕様に準拠します（RFC-4627を参照）。 特に、キーは引用符で囲まれている必要があり、リテラルは引用符で囲まれていない必要があります。 これらの制限は、isLenientプロパティを使用して緩和できます。 isLenient = trueを使用すると、非常に自由にフォーマットされたデータを解析できます。

私はどうしても必要なときにしか使いません。

RFCに基づかないJSONは一応留意しておきたいので。

👉 kotlinx.serialization/json.md at master · Kotlin/kotlinx.serialization hatena-bookmark
👉 RFC 4627 - The application/json Media Type for JavaScript Object Notation (JSON) hatena-bookmark

 

まとめ

一度、テンプレート化しておくと、当分使い回すことができます。

調べるときに、いろいろ古い情報が多くて時間かかったので、メモとして。

👉 【Retorofit】コピペで使える NetworkModule【Dagger Hilt】 hatena-bookmark
👉 Kotlin/kotlinx.serialization: Kotlin multiplatform / multi-format serialization hatena-bookmark