SwiftUI

SwiftUIでのMVVM例 - 本当にMVVMはComposableではないのか

Qiitaに【SwiftUI】なぜ、MVVMをやめて、The Composable Architecture(TCA)を採用するのか?という記事が上がっていました。 趣旨は以下のようです。 MVVMはComposableではないTCAはComposableであるMVVMよりTCAがおすすめ本当にMVVMはComposableではないのでしょうか?この記事のMVVMのコードにはいろいろ問題があるので、修正してSwiftUIでのMVVMのコード例を作成してみましょう。 当該記事のコードの問題点当該記事のMVVMのコードはCounterViewに対するViewModelをRandomCounterViewのViewModelに流用していることです。 RandomCounterViewにはRandomCounterViewModelを作成するのが一般的な実装です。 もう一つの実装方法はモデルレベルで抽象化してしまう方法です。この記事ではこの方法を採用します。 TCA版ではCounterViewをCounter/RandomCounterに利用しているのでMVVMでもそのように実装してみましょう。 修正版MVVM修正してみましょう。 まずモデルです。 protocol Countable { var count: Int { get } func increment() func decrement() } class

宣言的UIフレームワークのアーキテクチャパターン考察

この記事では宣言的UIにどのアーキテクチャパターンが良いかを述べるのではなく、宣言的UIでのアーキテクチャパターンの課題とアドバイスを記しています。 概論私はiOSネイティブアプリのプログラマでした。現在でも個人ではSwiftUIでアプリを作成していますが、業務ではFlutterアプリを作成しています。ですのでAndroidネイティブのことはわからないのでiOSとFlutterを主に話題にします。 iOSのUIKitではMVCが標準のアーキテクチャパターンでした。一方SwiftUIやFlutterは標準のアーキテクチャパターンが存在しません。存在しないとどうなるのでしょうか。去年私が引き継いだFlutterプロジェクトが、存在しない場合の最悪な実装を示してくれました。 簡単に述べると「WidgetがAPIアクセスを行い、JSONから子Widgetが生成され表示する」という実装です。当然Widgetは肥大化してスパゲッティコードになっていました。 UIKitではMVCのCが肥大化する問題が注目されていますが、標準アーキテクチャパターンが存在することで少なくともVとCは分離され、Vの見通しはある程度良い状態が保たれていました。 React Nativeは詳しくないのですがReactと同様にReduxが一般的のようで、Reduxに乗ってしまえば設計に関して問題は発生しにくいと言えます。 しかしSwiftUIやFlutterでは上記のようなVにすべてを載せてしまう実装まですでに発生しているのです。この2つのフレームワークではアーキテクチャパターンによる設計を十分検討して適用する必要があると言えます。 MVSwiftUIやFlutterではMVで良い、という意見をよく目にします。 VがMを購読Vがビジネスロジックの起動を依頼という構造です。この構造、どこかで見たと思いませんか?そう、MVCです。AppleのMVCはCがMとVの仲立ちをするのですが、非AppleのMVCでは上記のような構造になっています。