はてなブックマーク

書籍『良いコードの道しるべ 変化に強いソフトウェアを作る原則と実践』に書ききれなかった内容を書き記すシリーズ第2弾として、オブジェクト指向プログラミングにおけるクラスの継承の置き換えについて紹介します。 すでに多くの記事でも言及されている通り、クラスの継承はしばしば保守性に関する重大な問題をもたらします。 私自身、継承によって複雑になったコードに幾度となく悩まされてきました。 このブログ記事では、継承ではなく具体的にどのようなコードを書くべきかについて紹介します。 用語の整理 ここでやめるべきと述べている継承とは、インターフェースの実装は含みません。 何らかの実装を持つ抽象クラスに対する継承を避けることを提案しています。 Kotlinで言えばabstractクラス及びopenクラス、Javaで言えばabstractクラス及びfinalでない通常クラスに対する継承を指します。 継承の問題点

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はMut

宣言的UIの考え方はReact、Flutter、SwiftUI、Jetpack Composeと広がり、ほぼ全てのプラットフォームで利用できるようになりました。 今までのHTMLやXMLに対して命令的に処理を書くのに対し、宣言的UIはUIの構築や更新を圧倒的に簡素にしてくれます。 また、差分更新の仕組みを備えているものも多く、パフォーマンスの向上も見込めます。 今回はいくつかある宣言的UIのツール群の中から、代表的なJetpack Compose、React、Flutter、SwiftUIを個人的な見解も含めて比較していきます。 コンポーネントの記述 宣言的UIの大きなメリットの一つに、再利用可能なコンポーネントが挙げられるでしょう。 StatelessコンポーネントとStatefulコンポーネントそれぞれについて比較を行います。 SwiftUI Statelessコンポーネント まずは状

先週、「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 coalesci

この記事は Android Advent Calendar 2021 の13日目の記事です。 Jetpack Composeは内部でもKotlin Coroutinesを多く使っており、非常に相性が良いです。 今回はJetpack ComposeとKotlin Coroutinesを組み合わせて使ういくつかの方法について紹介します。 collectAsState Jetpack Composeでは、Stateの値を変化させることで画面更新をさせることができます。 ViewModel等でStateFlowを使っている場合、collectsState を使うことでStateに変換することができ、Composeに反映させることができるようになります。 @Composable fun Sample( viewModel: SampleViewModel = viewModel() ) { val

Jetpack Composeの導入は、アーキテクチャについて再検討する良い機会でしょう。 GoogleはAndroid Architecture Components(AAC)のViewModelとJetpack Composeを結合する方法を解説しており、今まで通りのViewModelが利用できるとしています。一方でTwitter等ではViewModelは不要になるのでは？といった議論もされてきました。 結論から言うと、Jetpack Composeの導入によってViewModelの形や名称は変化する可能性はあるが、関心の分離の観点からUIとロジックの分離は依然として重要であり、今後もViewModelに相当するものは無くならないでしょう。 今回はJetpack Comopseを使う上で、ViewModelをどのように扱うのが良いのか、どのように変化する可能性があるのか、いくつかの考察

先週、「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

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に状態ではなくイベントを送るのは未だいくつかの問題があります。 今回は、複数の方法をメリットデメリットとともに紹介したいと思いま

JetpackでもRoom, Paging 3, DataStore等様々なライブラリがkotlin coroutines flowを使い始め、もはやAndroid開発にはflowが必要不可欠になってきました。 そんな中、以前紹介したStateFlowに加えて、SharedFlowが1.4.0-M1から登場しました。 少し複雑に感じますが、実はかなり整理されており、以前より使いやすくなっていると思っています。 今回は、Flow、SharedFlow、StateFlowの概要に関して紹介し、各々の詳細に関しては別途まとめたいと思います。 型の関係を確認する Flow まず、Flowの定義はこのようになっています。 今回は型のみを重視するため、一旦メンバに関しては考慮しません。 public interface Flow<out T> SharedFlow 次にSharedFlowです。 pu

Navigation componentの登場により、画面遷移をFragmentベースで行う例が増えてきたように思います。 Fragmentで画面遷移をさせることで、toolbarやbottom navigation view等の共通のUIを表示し続けられるようになったり、activityでの画面遷移よりパフォーマンスがよかったり、いくつかの利点があります。 一方で、activityでの画面遷移とは違い、navigation利用時は遷移時にデフォルトのアニメーションがつきません。 そこで、今回はいくつかの遷移アニメーションの例を提示したいと思います。 カタログアプリ 今回提示する例は一つのカタログアプリとして見れるようにし、githubで公開しています。 GitHub - Mori-Atsushi/android-nav-anim-catlog アニメーションの作り方 アニメーションの定義

Kotlin Android Extensionは現在２つ機能があり、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との比較等をしている、こちらの記事も合わせて確認してください。 StateFlow 今回は、このドキュメントを上から順番に読んでいきます。 まず、定義はこうなっています。 @ExperimentalCoroutinesApi interface StateFlow<out T> : Flow<T> { public val value: T } Exp