サクサク読めて、アプリ限定の機能も多数!
トップへ戻る
ドラクエ3
at-sushi.work
StateFlowの深堀り、SharedFlowとの違いとstateIn【kotlin coroutines flow】 StateFlowはkotlin corouteinsの1.3.6で追加された状態管理用の特別なFlowです。 以前、「StateFlowのドキュメントを読み込む」という記事を書きましたが、その後SharedFlowが追加され、若干実装に変更がありました。 また、新たにstateInというoperatorも追加されています。 今回はそれらを含めたStateFlowの詳細な仕様に関して深堀りしていきたいと思います。 Flow, SharedFlow, StateFlowの比較はこちらの記事を、SharedFlowの深堀りはこちらの記事を参考にしてください。 StateFlowの基本的な使い方StateFlowは状態管理に特化したFlowです。 StateFlowはMuta
宣言的UIの考え方はReact、Flutter、SwiftUI、Jetpack Composeと広がり、ほぼ全てのプラットフォームで利用できるようになりました。 今までのHTMLやXMLに対して命令的に処理を書くのに対し、宣言的UIはUIの構築や更新を圧倒的に簡素にしてくれます。 また、差分更新の仕組みを備えているものも多く、パフォーマンスの向上も見込めます。 今回はいくつかある宣言的UIのツール群の中から、代表的なJetpack Compose、React、Flutter、SwiftUIを個人的な見解も含めて比較していきます。 コンポーネントの記述宣言的UIの大きなメリットの一つに、再利用可能なコンポーネントが挙げられるでしょう。 StatelessコンポーネントとStatefulコンポーネントそれぞれについて比較を行います。 SwiftUI Statelessコンポーネントまずは状態を
Jetpack Composeの大きな特徴として、再利用可能なコンポーネントを作りやすくなったことがあるでしょう。 細かい単位でComposable関数に切り出すことで、同じUIを共通化できるだけでなく、今後の仕様追加/変更の際にもスムーズにコンポーネントを再利用できるでしょう。 一方で、再利用可能なコンポーネントの実現にはいくつか注意すべき点があります。 今回は公式から述べられている注意事項や、自分が書いていて注意していることについて紹介します。 その前に:再利用しない選択肢再利用の話に入る前に、再利用しない選択肢について書かせてください。 同じコードを何度も再利用することができれば、変更時に一箇所だけ変更すれば良くなりますし、何より楽です。 一方で、共通化することにより予期していなかった問題が発生することはよくあります。 一般的にUIの変更は多く、コンポーネントの切り出しの難易度は高い
先週、「Jetpack Compose, React, Flutter, SwiftUIを比較する」という記事で宣言的UIの各ツールの比較を行いました。 その中で、Jetpack Compose特有の特徴としてコンポーネントに返り値がないことを紹介しました。 @Composable fun Greeting(name: String) { Text("Hello $name") }これは、React等で遵守されてきたコンポーネントは純粋関数として扱うというルールから逸脱したものとなります。 その理由について、Jetpack Composeの開発に携わるJim SprochさんからTwitterで以下のようにリプライを頂きました。SwiftUI Four reasons: (1) more natural for conditionals and loops, where coalescin
この記事は Android Advent Calendar 2021 の13日目の記事です。 Jetpack Composeは内部でもKotlin Coroutinesを多く使っており、非常に相性が良いです。 今回はJetpack ComposeとKotlin Coroutinesを組み合わせて使ういくつかの方法について紹介します。 collectAsStateJetpack Composeでは、Stateの値を変化させることで画面更新をさせることができます。 ViewModel等でStateFlowを使っている場合、collectsState を使うことでStateに変換することができ、Composeに反映させることができるようになります。 @Composable fun Sample( viewModel: SampleViewModel = viewModel() ) { val c
Jetpack Composeの導入は、アーキテクチャについて再検討する良い機会でしょう。 GoogleはAndroid Architecture Components(AAC)のViewModelとJetpack Composeを結合する方法を解説しており、今まで通りのViewModelが利用できるとしています。一方でTwitter等ではViewModelは不要になるのでは?といった議論もされてきました。 結論から言うと、Jetpack Composeの導入によってViewModelの形や名称は変化する可能性はあるが、関心の分離の観点からUIとロジックの分離は依然として重要であり、今後もViewModelに相当するものは無くならないでしょう。 今回はJetpack Comopseを使う上で、ViewModelをどのように扱うのが良いのか、どのように変化する可能性があるのか、いくつかの考察
Kotlin Coroutinesの進化はすざましく、とどまるところを知りません。 状態やイベントを扱いやすくなったStateFlowやSharedFlowが登場し、さらには、Lifecycleをより扱いやすくなったLifecycleOwner.addRepeatingJobやLifecycleOwner.repeatOnLifecycle、Flow.flowWithLifecycleが追加されました。 RoomやDataStore等Jetpackの各種ライブラリでもCoroutinesが使われており、Jetpack Composeでも様々なところでCoroutinesが活用されています。 そういった中で、一部LiveDataやRxJavaからCoroutinesに書き直す動きが見られ、多少混乱を招いていると感じています。 結論から言うと、現時点において積極的にCoroutinesに移行す
この記事は Kotlin Advent Calendar 2020 の15日目の記事です。 非同期処理を書く際に、kotlin coroutinesは使いやすく、非常に強力です。 一方で、単体テスト等を書くのには一定のハードルがあります。 今回は、suspend functionをテストしたり、モックする方法について紹介します。 時間のかかるsuspend functionをテストする例えば、以下のような実行に10秒かかるsuspend functionがあったとします。 suspend fun sample(): Int { delay(10_000) return 10 }これをテストする際に、runBlocking等を使ってしまうと、テストの実行に10秒かかってしまいます。 @Test fun test() { val actual = runBlocking { sample()
この記事はAndroid Advent Calendar 2020 の2日目の記事です。 SharedFlowやStateFlowの登場により、ますますkotlin coroutinesを手軽に扱えるようになってきました。 AndroidのMVVMにおいても、LiveDataの代わりにStateFlowを使ってViewとViewModelをbindingすることが可能になりました。 GitHub - Mori-Atsushi/android-flow-mvvm-sample: Android MVVM sample app that uses kotlin coroutines flow (without LiveData) 一方で、ViewModelからViewに状態ではなくイベントを送るのは未だいくつかの問題があります。 今回は、複数の方法をメリットデメリットとともに紹介したいと思いま
まず、Flowの定義はこのようになっています。 今回は型のみを重視するため、一旦メンバに関しては考慮しません。 public interface Flow<out T> 次にSharedFlowです。 public interface SharedFlow<out T> : Flow<T> Flowを継承していることがわかると思います。 また、書き換え可能なSharedFlowである、MutableSharedFlowの定義はこうです。 public interface MutableSharedFlow<T> : SharedFlow<T>, FlowCollector<T>SharedFlowを継承しており、またFlowCollectorという型も継承しています。 FlowCollectorはこのような定義になっています。 public interface FlowCollector<
Navigation componentの登場により、画面遷移をFragmentベースで行う例が増えてきたように思います。 Fragmentで画面遷移をさせることで、toolbarやbottom navigation view等の共通のUIを表示し続けられるようになったり、activityでの画面遷移よりパフォーマンスがよかったり、いくつかの利点があります。 一方で、activityでの画面遷移とは違い、navigation利用時は遷移時にデフォルトのアニメーションがつきません。 そこで、今回はいくつかの遷移アニメーションの例を提示したいと思います。 カタログアプリ今回提示する例は一つのカタログアプリとして見れるようにし、githubで公開しています。 GitHub - Mori-Atsushi/android-nav-anim-catlog アニメーションの作り方アニメーションの定義はさ
Kotlin Android Extensionは現在2つ機能があり、findViewByIdを省略できる views とParcelableの実装を楽にしてくれる parcelize があります。 特に views は非常に便利で、僕自身もよく使っていました。(今後、Kotlin Android Extensionsと書いた場合はviewsの方を示します) 一方、ViewBindingというものも登場し、DataBindingの軽量版みたいな立ち位置で、こちらもfindViewByIdを省略することができます。 Kotlin Android ExtensionとViewBinding、DataBindingを比較し、使い分けについて議論したいと思います。 -2020/12/08追記- kotlin 1.4.20からandroid-kotlin-extensionsはdeprecatedに
kotlin coroutines 1.3.6 にて、StateFlowというものが導入されました。 状態管理のために用いられる型で、将来的にConflatedBroadcastChannelから置き換わるとも言われています。 今回は、ドキュメントを詳しく見つつ、実際にコードを動かして特徴について見ていきたいと思います。 - 2020/11/15追記 -この記事はSharedFlowがリリースされる前に書かれています。 SharedFlowとの比較等をしている、こちらの記事も合わせて確認してください。 今回は、このドキュメントを上から順番に読んでいきます。 まず、定義はこうなっています。 @ExperimentalCoroutinesApi interface StateFlow<out T> : Flow<T> { public val value: T }ExperimentalCor
このページを最初にブックマークしてみませんか?
『at-sushi.work』の新着エントリーを見る
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く