Flutterの状態管理とViewの更新
こんにちは。モバイルクライアントグループの若宮(id:D_R_1009)です。 最近スタンディングデスクを導入しました。業務時間中はずーっとスタンディング状態で、疲れたら業務終了な感じでやってます。 スタディプラスでは一部のプロダクトでFlutterを採用しています。 社内では私がFlutterの開発経験が一番多く、また長くなっているので技術選択などを行っています。 先日、新たにFlutterのアーキテクチャを選びなおす機会がありました。 アーキテクチャを比較するにあたり、社内向けに書いたブログを一部編集して公開します。 はじめに StatelessWidget StatefulWidget StatefulWidgetにmixinするObserver Viewを更新するController Provider (InheritedWidget) InheritedWidgetとは Prov
【Flutter】アプリを分割する3つのレイヤーと依存関係
前回の記事 では、今仕事で開発中のアプリのアーキテクチャを クリーンアーキテクチャ本 の教えを頼りに頑張って考えた話を書きました。 前回の記事では主に レイヤーを分割して依存関係を整理することの意義 について書きましたので、この記事ではそれをさらに深掘りし、具体的にそれぞれのレイヤーがどのような役割を担当し、なぜそれをレイヤーとして独立させる必要があると考えたかを説明していきます。 「クリーンアーキテクチャを適用する」とは このアプリの具体的な話に入る前に、この記事での「クリーンアーキテクチャを適用する」という言葉のイメージをちゃんと書いておこうと思います。 個人的な理解ですが、「クリーンアーキテクチャを適用する」という言葉が表す内容は、あの有名な同心円上の 4 つのレイヤーを忠実に再現することではありません。 クリーンアーキテクチャ本では、例の図の直後に 図 22-1 の円は、概要を示し
【Flutter】アプリ全体のアーキテクチャを0から考えて作り直した話
ここ半年ほど、仕事で Flutter アプリを 0 から作り直しています。 ちょうど今年の個人的なテーマを「アーキテクチャ」に据えていたこともあり[1]、またその一環として 「Clean Architecture 達人に学ぶソフトウェアの構造と設計」 （以下：クリーンアーキテクチャ本）を読んでいたこともあり、この作り直しでは「アーキテクチャ」をしっかりと自分の頭で考えながら作ろうと決めて取り組んできました。 アーキテクチャについて頭を悩ませながら実装を進めること約半年、ようやくアプリが形になるとともにある程度知見も溜まってきましたので、その知見を一般化した内容をこの記事にまとめていきたいと思います。 注意 この記事は、「Flutter アプリのアーキテクチャはこれがベストプラクティス！」という類の記事ではありません。あくまで 私の目の前の要件ではこれが最適と判断した という一例の紹介になり
MVC vs MVP vs MVVM
今日では、アーキテクチャデザインパターンに関して多くのオプションがあります。Model-View-ViewModel（MVVM）、Model-View-Presenter（MVP）、およびModel-View-Controller（MVC）を使用して多くのアプリを開発した後、私はついにそれらの違いについて話す資格があると感じました。わかりやすくするために、BookSearchアプリで本を検索する画面を作成するなどの簡単な例を使用できます。 今から始めましょう…！ MV（X）の必需品 まず、MVC、MVP、およびMVVMアーキテクチャを簡単に理解してから、それらに飛び込む必要があります。 なぜModel-View-（CまたはPまたはVM）なのですか？ これらのアーキテクチャの目的は、UIアプリケーションの視覚化、処理、およびデータ管理の責任を分離することです。 彼らの目標は増加することです。
完全に理解したと思ってたMVC,MVP,MVVM全然理解してなかった件
それぞれの違いとメリデメとなんでCがPになったりVMになったりしてるのかとそれぞれの役割を理解したみだったのでまずはMVCとMVPの違いとかメリットについて↓ によると MVCとMVPはModelとControllerの間にPresenterが入ってて、それはControllerがfatにならないようにというのはわかった これはユーザの入力をコントローラが受け取り、入力値によってモデルとされているビジネスロジックを実行させます。 結果としてモデルに変化が起き、その変化をビューが受け取ります。ビューはオブザーバーとしてモデルの変化を監視しています。 なお、いわゆる MVC フレームワークはこれとは異なります。 MVC フレームワークではコントローラがビューを描画します。 このため、原初の MVC を古典的 MVC、MVC フレームワークのような形を MVC2 と呼ぶことがあるようです。
MVPアーキテクチャについて - Qiita
はじめに 今までは、ずっとMVCを採用してアプリを開発してきましたが MVC脱却を図るため、今回はMVPに関することを備忘録として残しておきます。 まず、MVPを知る前にMVCの流れを復習していきましょう。 MVC API通信の例で簡単に説明すると、 まず、Viewからユーザーのアクションを検知し、そのアクションをControllerに伝えます。 そして、Controllerは必要なModelを取得するためにAPIを叩きます。 その後、APIから必要なModelが返され、Controllerで保持されます。 ControllerからViewにModelを渡して そのModelからViewを更新することによって画面が更新されます。 なぜMVCから脱却したいのか？ MVCだとFatViewControllerになりやすいからです。 iOSDC 2017 前夜祭で「節子、それViewContro
ソフトウェアアーキテクチャの歴史 - tasuwo's notes
改めて ソフトウェアアーキテクチャ GUI のアーキテクチャの歴史を調べてみたくなった。本来の MVC とは何か？何が正しくて何が間違っているか？も重要なのだが、それよりは、なぜそれが生まれたのか？何を解決しようとしたのか？どのような問題点が生まれて、それをどう工夫して解決・発展してきたのか？を知りたい。しかし、そういうことがまとまっている日本語の情報が少ないので、自分で色々かいつまんでメモしておく。 MVC の原点は 70 年代にまで遡り、実装としては Smalltalk-80 のクラスライブラリとして実装されたのが最初だと思われる。しかし、後世に大きな影響を及ぼしたポイントをいくつか持ちつつも、当時のアーキテクチャが現代においてそのまま利用されているケースはほぼないといっていい。したがって、単に MVC といった時には大抵最初期の MVC を指すことは少なく、区別するために最初期の M
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
なぜアーキテクチャ図を必要とするのか？