「SwiftUIでMVVMを採用するのは止めよう」と思い至った理由 - Qiita
※2022/04/23 追記 本記事の続編として、以下の記事を書きましたので、合わせて御覧ください。 仕事でSwiftUIでTCAを使ってみて、かなり知見がたまったので、その解説です。 MVVMからTCAへの移行を考えているのであれば、参考になると思います。 宣言的UIに、MVVMって不要なのでは？ iOS開発の現場で、宣言的UIが当たり前に使われるような時代になりました。 SwiftUIの開発体験、素晴らしい です。最高です。 しかし最近、SwiftUIで当たり前のように 「MVVMで開発しよう」 となったときに、 「ほんとにそれでいいんだっけ？」 と疑問に思いました。 自分の考えを深掘ってみると 問い: iOS開発で、宣言的UIにMVVMを採用することは本当にいいんでしたっけ？ 結論: 「SwiftUIを使うのであれば、MVVMを採用するのは止めよう」 理由： ViewModelの存在
なぜiOSのMVVMはdisられるのか — Elm Architectureとの比較記事から考える
iOSアプリではMVVMが多用されている。UIKitとFRPライブラリであるRxSwiftを組み合わせて実装されるのが一般的である。（私はReactiveSwiftの方が好きだけど…） MVVMはマイクロソフトのWPFで考案されたソフトウェアアーキテクチャパターンで、それがiOSに導入されて広まった。 しかししばしばiOSにおけるMVVMは批判の的となってきた。もっとも俎上に上がるのはVMの肥大化・複雑化である。最近では以下の記事があげられる。 なぜ MVVM は Elm Architecture に勝てないのか この記事を元になぜMVVMが批判されるのかを見ていこうと思う。 ViewModelは複雑化する論上記記事ではやはり「複雑化しすぎたViewModel」と主張している。 複雑化したコードが掲載されているので全文は転載しないが、主要な個所を見てみる。 まずViewModelの状態の管
kicksterter/ios-oss を観察してみて思ったこと（その１） - おぼえがき
海外のクラウドファンディングサイト kicksterter.com は自社の iOSアプリ のソースコードをGithubで公開しています。 kicksterter/ios-oss なかなか評判が良さそうだったのでソースコードを観察してみました。 最も印象的だった部分はだいたい他の人の記事で分かりやすくまとめられていたので、 僕は俯瞰的な視点で思ったことをダイジェスト的に書くことにしました。 動機 僕は現在新規のiOSアプリプロジェクトに参加しています。 アプリ開発は最初が肝心なので、なるべく他のプロジェクトを参考にして構成を参考にしようと思い、オープンソースで公開されているkicksterterのiOSプロジェクトを観察してみました。 アプリ開発は最初が肝心 ソフトウェア開発も最初が肝心です。 初期段階のフェーズでの判断次第で、未来の開発環境が大きく変わります。 アプリ開発でも、最初に作っ
某RxSwiftを使ったMVVMの記事の改善案 - Qiita
まずはじめに 11月中旬にリリースされたとある記事が、初心者の方が見たら勘違いしやすい実装が複数紹介されている状態だったので、その実装に対する改善した実装を本投稿で紹介していければと思います。 ちなみに、以下の項目が改善の余地があるのではないかと感じた実装になります。 ViewControllerにObservableを加工する処理が入っている ViewModelから流れてきたイベントをViewControllerで加工せず、そのままViewにバインドするだけの実装のほうが良い Viewの操作で、observeOn(Main)またはBinderを利用していない Variableをvarで定義する Variable.valueを変更するが、Variableのインスタンス自体を変更することはほぼないはず VariableはRxSwiftのDeprecated.swiftに実装されているので（S
CodeZineにあるRxSwiftの記事(第4回)に対して自分ならこうするという話 - Qiita
この文章は、 「RxSwiftの仕組みを利用して、MVVMモデルを導入しよう - RxSwiftを使った一歩進んだiOSアプリ開発 第4回」に書かれている記事にある内容を、自分が説明記事を書くならこうやるなーというものを解説します。自分がアプリケーションを作るときにどうやるかではなくて、元記事も説明をするためにあえてやってることもあると感じるためです。 元記事ではWikipediaのWeb APIに対して文字列を送信し、その結果をtableViewに表示するというものです。 書き換えにあたってコンセプトとしては 無駄にSubject(というかVariable)を使わない Subjectは自由にイベントを発火できるためコードが圧倒的に読みづらくなるため 無意味なprotocolは作らない protocolを作るならそれを利用するコードを書く インターフェースを揃えるだけでは意味をもたない 「
RxSwift + MVVM: how to feed ViewModels – BlaBlaCar Tech – Medium
IntroductionIt’s been almost a year since we started using RxSwift along the Model-View-ViewModel (MVVM) architecture at BlaBlaCar. We’re thrilled with the results. The code we’re writing with this approach is much easier to understand, maintain, test and scale. However, the first weeks were not a piece of cake: we had to iterate on some aspects of our MVVM+RxSwift architecture to get things right
RxExample MVVM のその先へ（Fat ViewModel の倒し方） - Qiita
この記事は、RxSwift が提供する公式のサンプルである RxExample で行き詰まった方向けに、実践的な対処方法を紹介します。具体的には RxExample にある MVVM (Model-View-ViewModel) を真似たアーキテクチャで陥りがちな Fat ViewModel へ対処する方法の解説になっています。 なお、この記事の想定読者は RxExample の初級者〜上級者ですが、それぞれの方向けにこの記事の読み方を説明します。 初級者の方へ 登場するコードは、コメントだけ拾い読みしても内容がわかるように配慮しています。コードを深く追うと疲れてしまうと思うので、コード内のコメントの内容を追ってください。 上級者の方へ この記事では、RxExample 上級者が疑問を感じるであろうコードに「上級者向け注釈」をつけています。記事末に注釈の解説がありますので、そちらをご覧くだ
ライブラリを使わずにMV*の話(iOS)〜MVC, MVP, MVVM〜
話すこと アプリの責務の分け方 Model アプリ内で扱う状態・値を持つ Modelの外から指示を受け処理を行う 状態・値の変化をModelの外へ間接的に知らせる View/Whatever 画面の構築/表示 ユーザー操作の受付 アクションを定義する アクションの結果/途中経過を受け取る 内部表現を視覚表現へ変換する MV* の種類 View/Whatever間での仕事の分け方は複数ある (Model-View-Whatever 間の接続の仕方も複数ある) 分けた後のクラス連結の仕方 Commandパターン(直接指示する) Observerパターン(間接的に通知する) 対象読者 Fatなクラスを作りがちで困っている人 責務の分け方にはどういうものがあるのか知りたい人 分け方と分けた後のクラス間の接続がわからず困っている人 話さないこと ■ MV*の歴史的経緯 理由: どれが正史か判断する手
最近のアプリ界隈での「設計」の違和感 - なるようになるかも
アプリ界隈で「設計」の話をするときに MVC / MVP / MVVM のような「設計パターン」だけが語られるようになった気がする。 往々にして、「アプリの規模によってどれを採択すべきかは変わる」みたいなお茶を濁すような結論で終わることが多い。 私的な結論 「設計」と、「設計パターン」は別物だと思う。 「設計」のレベルを上げたい。 アーキテクチャシンドロームから抜け出して、価値のあるものを作りたい。 以下、思うところのメモ。 MVC は古い / 劣ったやり方か？ MVC は Model をどう構築するかについてとくに規定していない。 MVC への批判をするときに、FatVC が持ち出されることが多いのですが、FatVC を実装してしまうのは単に実装者の能力不足だと考えていて、MVVM を採用しても FatVM を作るだけだと思っている。 また、比較的新しめの Flux アーキテクチャは、良
DataBinding + RxJavaでMVVMパターンな設計を考える - どくぴーの備忘録
今更感がすごいが、DataBindingを使うことによってAndroidアプリケーションの実装でMVVMパターンな設計を考えやすくなったし、DroidKaigi 2017のアプリがMVVMで実装されていたりするので、自分なりに設計をまとめてみる。 全体図 他で実装されている記事を見るとDDDなりと混ぜ合わせた感じの設計がちらほら見えて、一番シンプル（かつ集合知的な知見が溜まっている）と感じたDroidKaigi/conference-app-2017のアーキテクチャを丸パクリする形になった。 github.com 何をしているかざっと書くと View Activity/Fragment/Adapter ItemといったViewは1対1で対応するViewModelを持つ 各Layout XMLには対応するViewModelをDataBindingでbindする ViewModel Viewの
droidcon NYC 2017に行ってAndroidの最新開発事情について調査してきました！ - Gunosy Tech Blog
はじめまして、グノシー開発部新卒エンジニアの山本です。 主にグノシーのAndroid版や、最近リリースしたLucraのAndroid版を作ったり、サーバーサイドでGo/Pythonで開発をしたりしています。 少し時間が空いてしまいましたが、9月25~26日にニューヨークで開催されたdroidconNYC 2017に会社に費用を出してもらって参加してきました。 今回はそのレポートを書いていこうと思います。 droidconについて droidconとは世界各地で行われるAndroid専用のカンファレンスで、Android専用でいえば世界でも最大規模のカンファレンスです。 ニューヨークの他にもロンドンやベルリン等(日本はまだ😢)で行われ、終了後には各サービスでスライド等が盛り上がるので知ってる人も多いかと思います。 今回のdroidcon NYC 2017では70以上のセッションが行われ、9
DroidKaigi 2017で発表してきた - ほげほげ（仮）
MVVMについて話してきました。 このMVVMについて色々と議論はあるかと思いますが、まずはスタートラインに持っていけたかなと思ってます。これを元に色んな方が実践し議論してもっと良い方法を共有してくれるのを期待しています。今日も質問を受けたり議論もあって非常に勉強になりました。もっと改善できるようにこれからも色々模索していきます。 このような発表をすることはこれまでなかったので、かなり緊張してずっと寝不足気味な日々でした。ただ、終わってみるとやってよかった感は半端ないです。色んな人に声をかけてもらえて非常に嬉しかったです。ありがとうございました。 DroidKaigi関係者のみなさんに感謝！そして、相談に乗ってくれたり練習に付き合ってくれたりした同僚に感謝！
モバイルアプリのアーキテクチャを考える - クックパッド開発者ブログ
こんにちは、サービス開発部の森川 (@morishin127) です。主にクックパッドの iOS アプリの開発に携わっています。 日々アプリを開発する中で、近頃は最適なアーキテクチャとは何かを考えながら色々な形を試行錯誤しています。世の中で採用されているモバイルアプリのアーキテクチャには様々なものがあります。MVC, MVP, MVVM, VIPER, Clean Architecture などなど。開発している、あるいは開発しようとしているアプリケーションでどういったアーキテクチャを選択するかというのは難しい問題です。選択するためにはアーキテクチャに求める要件を定義する必要があります。この記事では私がアーキテクチャに求める要件と、それらをある程度満たすと考えた MVVM と Flux という2つのアーキテクチャで実装したサンプルを見つつその長所・短所について考えてみようと思います。 アー
[MVVM] kickstarter/ios-oss での画面遷移のやり方 - Qiita
MVVM の画面遷移 最近 MVVM を始めたのですが、画面遷移の方法やそれに伴うパラメータの引渡し方法をどうすべきかというのを考えていて、 kickstarter/ios-oss の方法がわかりやすいと思ったので紹介します。 忙しい人のための3行まとめ 遷移元の画面遷移ボタンがタップされたら ViewModel にイベントを伝る ViewModel が次の画面に渡すパラメータをセットする View が遷移先の ViewController にパラメータを渡し、画面を開く 実際の処理を追う Signup 画面の Help ボタンから HelpWebView に移動する流れです。 1. 遷移元の画面遷移ボタンがタップされたら ViewModel にイベントを伝る SignupViewController#L214:
![[MVVM] kickstarter/ios-oss での画面遷移のやり方 - Qiita](https://cdn-ak-scissors.b.st-hatena.com/image/square/88de3c78ef5f0e7854d5bd09ce3f252ffe8f3917/height=288;version=1;width=512/https%3A%2F%2Fqiita-user-contents.imgix.net%2Fhttps%253A%252F%252Fcdn.qiita.com%252Fassets%252Fpublic%252Farticle-ogp-background-412672c5f0600ab9a64263b751f1bc81.png%3Fixlib%3Drb-4.0.0%26w%3D1200%26mark64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZ3PTk3MiZoPTM3OCZ0eHQ9JTVCTVZWTSU1RCUyMGtpY2tzdGFydGVyJTJGaW9zLW9zcyUyMCVFMyU4MSVBNyVFMyU4MSVBRSVFNyU5NCVCQiVFOSU5RCVBMiVFOSU4MSVCNyVFNyVBNyVCQiVFMyU4MSVBRSVFMyU4MiU4NCVFMyU4MiU4QSVFNiU5NiVCOSZ0eHQtYWxpZ249bGVmdCUyQ3RvcCZ0eHQtY29sb3I9JTIzMjEyMTIxJnR4dC1mb250PUhpcmFnaW5vJTIwU2FucyUyMFc2JnR4dC1zaXplPTU2JnM9YzkyMWQ4YTMyMjRmYjgyYjkxNWU3YzU4YzA0MDFiZmE%26mark-x%3D142%26mark-y%3D57%26blend64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZoPTc2Jnc9NzcwJnR4dD0lNDBzdGFyX19ob3NoaSZ0eHQtY29sb3I9JTIzMjEyMTIxJnR4dC1mb250PUhpcmFnaW5vJTIwU2FucyUyMFc2JnR4dC1zaXplPTM2JnR4dC1hbGlnbj1sZWZ0JTJDdG9wJnM9MGZiY2M4OGE4NzkxNzU4YTVjNmE2MzI4NTYwYTViZTk%26blend-x%3D142%26blend-y%3D486%26blend-mode%3Dnormal%26s%3D1d7dc11ae5601758e1fdaae62733fcc2)
MVVM with RxSwift
About the content This content has been published here with the express permission of the author. MVVM is the critical design pattern for front-end engineers. There are so many ways that objects can talk to each other in an iOS App: delegates, callbacks, notification. In this Swift Language User Group talk, Max Alexander shows you how to streamline your development process in 3 easy patterns with
トレタのアプリ新機能開発の舞台裏 - トレタ開発者ブログ
開発部の@horimislimeです。普段は@y_koh さんとiPadアプリ開発をさせてもらっています。 先日トレタはメジャーアップデートとなるver5.0.0で、飲食店従業員の方が店内のテーブル配置を作成し、空間的にテーブルを見ながら予約を取れる「テーブルレイアウト」機能をリリースしました。 この機能の詳細や、開発にあたっての想いは弊社ブログのエントリも御覧ください。 トレタ新バージョン「5.0.0」とモノ作りの話 : TORETA（トレタ） ブログ トレタとして大規模なアップデートとなるver5.0.0でしたが、その裏ではiOS開発チームとして新しいチャレンジもありました。それが以下の二点です。 Swiftと新しいパラダイムの導入 これまでのトレタには無かったUIの実現 まずiOS開発チーム内でこの新機能からSwiftを導入し、合わせてMVVM風な設計を取り入れつつ実装を進める方針を
まだMVC,MVP,MVVMで消耗してるの？ iOS Clean Architectureについて - Qiita
＜この記事は「Money Forward Advent Calendar 2015」の22日目の記事です＞ この記事は、iOS Clean Architectureと実際にコードへ適用した内容について紹介します。 コードについては、改善の余地があるため随時修正していくと思います。 → github: https://github.com/koutalou/iOS-CleanArchitecture iOS開発においてよくある問題点 「ビジネスロジックはModelに置くべき」と言うが、開発者によって理解や意見がバラバラで統一的な実装ができない 度重なる仕様変更や複雑な仕様に対応するためにViewControllerや特定のModelが肥大化し、ビジネスロジックの本質を見失う MVC,MVP,MVVMだけで考えると、どこかのレイヤが複数の責務を持つことになり依存度の高い複雑なコードが生まれてし
MVVMをベースに複雑な振る舞いをしっかり把握できるアプリ開発 - Qiita
TL;DR 複雑になりがちな構造やコードをシンプルで把握しやすいコードで記述したい MVVMを用いて責務を明確にし関心事を分離した構造にする ViewDataBindingとFRPを用いて時間とともに変化するデータやステートに伴う処理を宣言的に記述し、Viewとデータの動的な変化を相互的に連動させる 上記をSwiftとそのパラダイムを活かしたライブラリ（SwiftBond)を中心に実現する はじめに Swiftで新規のアプリを開発することになり、MVVM、FRP、ViewDataBindingの要素技術を活用して開発を行いました。設計やライブラリ選定は2015年5月に行っており実装環境はXcode6.4,Swift1.2になります。Swift2.0以上になるとSwift系ライブラリも大きくインタフェースを変更しているため、ここで紹介しているサンプルコードもそのままでは動作しないことをご留意
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
なぜうちのチームは開発中のアプリを
MVVM から MVC に戻したのか - Speaker Deck
Login screen implementation using MVVM + RxSwift