LiveData vs Flow vs RxJava - Blog - Mori Atsushi
Kotlin Coroutinesの進化はすざましく、とどまるところを知りません。 状態やイベントを扱いやすくなったStateFlowやSharedFlowが登場し、さらには、Lifecycleをより扱いやすくなったLifecycleOwner.addRepeatingJobやLifecycleOwner.repeatOnLifecycle、Flow.flowWithLifecycleが追加されました。 RoomやDataStore等Jetpackの各種ライブラリでもCoroutinesが使われており、Jetpack Composeでも様々なところでCoroutinesが活用されています。 そういった中で、一部LiveDataやRxJavaからCoroutinesに書き直す動きが見られ、多少混乱を招いていると感じています。 結論から言うと、現時点において積極的にCoroutinesに移行す
Android Architecture Components 雑感。 - なるようになるかも
Architecture Components - Introduction (Google I/O ‘17) 解説はこのビデオを見るのがとても分かりやすいです。 機械翻訳で日本語字幕が出せるので、英語が聞き取れなくてもだいじょうぶ。 いままでの Android の世界観 ※人によってかなり違う気がします バックグラウンド処理は Service を使うことができました Service をキックするのは Activity でもいいし、SyncAdapter とかを使う手もあったり この辺使うのが面倒だったりで、AsyncTask の不治の病に陥ってたり、RxJava 使ったりの方が多いですよね… ContentProvider を経由することでデータベース実装を抽象化 やってるの、正直あんまり見たことない… 連絡帳プロバイダとかにちょっと凝ったクエリ（グルーピングとか）を投げようとすると、途
Android Architecture Components 雑感2。 - なるようになるかも
主に Lifecycle と LiveData について。 Lifecycle 某ポエムサイトにあったクラス図がしっくりこなかったので、自分で書き直してみました。 Lifecycle のキモは、ライフサイクルメソッドのオーバーライドはもうやめましょう、ということ。 なぜかというと、Activity や Fragment を容易に Fat にする上に、処理を追うのが直感的ではなくなってしまうから。 その代わり、Activity や Fragment は State を持つように変わります。ライフサイクルイベントが発生すると、どこからともなく（後述） Event が投げられて、これを受けて State の更新が行われます。 State と Event は公式サイトの以下の図の通りです。 （Handling Lifecycles より） このイベントの変更を受け取りたいクラスは、Lifecycl
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Connection Detection Using LiveData — Android
