#LiveDataを使ってみて
###LiveDataとは
ライフサイクルに応じて自動的に購読解除してくれる通知プロパティ
公式ドキュメント:AndroidDevelopers
####コード例
class A {
private liveData = MutableLiveData<String?>()
override fun onCreate(savedInstanceState: Bundle?) {
super.onCreate(savedInstanceState)
liveData.observe(this, Observer { value ->
value?.let {
Log.d("#######", "liveData Value : $value")
}
})
}
override fun onResume() {
super.onResume()
liveData.value = "test"
}
......
}
onCreate内でLiveDataの監視を始め、onResumeでLiveDataに値を代入した際に、変更が通知され、Log.dが実行される
####LiveData使用する際に気をつけること
- 使用できる条件
- 値のnullチェック
- 監視を始める場所
使用できる条件
ライフサイクルに合った実装になっていること
LibeDataが通知を受け取るのは、Observerがアクティブになっていることが条件
もし、Activity Aでobserveした後、Activity Bに遷移し何らかの方法でLiveDataに値を代入したとしてもActivity Aはアクティブではないため、通知がない
※基本的にLiveDataの変数宣言はViewModelで行い、監視を始めるのはActivityで行なう
値のnullチェック
基本的にLiveDataの値はNullableになっているため、nullチェックを行なう
nullチェックはif文で行なうのも良し、letなどのスコープ関数を用いても良し
監視を始める場所
監視を始める場所=observeする場所
監視を始める場所は公式のサンプルでもonCreate内になっている
もし、onResumeなどで開始をするとどうなるか
onResumeにobserveするとバックグラウンドでの起動状態からアプリに復帰した際に、何度も監視されてしまう
そのため、値が変更された時に何度も通知が起こってしまい、何かのAPI通信のトリガーに用いている場合に多重リクエストしてしまう恐れがある
なので、一度だけ監視が呼ばれるようなライフサイクルを用いる
###まとめ
ニュアンス的にはRxに似ているので捉えやすいかもしれない
LiveDataは使いやすい反面、使い方を間違えると思っていたより面倒くさい事になりそう
まだまだ細かい部分に関してはまだ触れられていないが、気づいたらまた近いうちに、まとめます