iOS/Androidアプリエンジニアが理解すべき「Model」の振る舞い

iOS/Androidアプリエンジニアが理解すべき「Model」の振る舞い
iOS/Androidアプリエンジニアが理解すべき「Model」の振る舞い 2014年7月ゆめみ森下健 1 そろそろ聞き飽きた煽りタイトルでごめん
以前「iOS/Androidアプリの３つの大事な設計方針」という話をしたのだけれど、今回はもう少し具体的な設計の話をするよ 2
この１年で10個近くアプリのコードを見てきたのだけど、ほぼ全てにおいて「Modelがない」のよ。皆「MVCです。 Modelあります」というけれど、私にはModelが見えない。そう、「Modelとは何か」が共有できてないのよ 3
Modelという言葉は色々な意味で皆捉えるから、本当は別の良い言葉を使えれば良いのだけど、見つからないのよね。誰かエロイ人が決めてくれればなぁ。 4
以前の資料では「UIではない部分≒Model」としたけど、今回はもう少し具体的に構造を整理して「（よく忘れられている）Modelの重要な振る舞いは何か？」について考察するよ。 Modelって俺のことさ大喜利どうぞ 5
まず、結論から述べよう！それは次の２点！ •  基本死なない •  通知で変更を伝えるこの２点がなぜ重要かをこれから説明するよ 6
(VC) ViewController Fragment View View Model En@ty En@ty En@ty Model Locator Model En@ty En@ty En@ty API API API プレゼンテーション層ビジネス層データ層 State Machine Local Data Access この図はアプリを作る時によく出てくるコンポーネントよ。ここではコンポーネントという言葉を、「一塊の機能を実現するClass群」という意味で使っているわ。（他にいい言葉無いかな…）よく使うコンポーネント外部サービスデータソースコンポーネントコンポーネントコンポーネントコンポーネントコンポーネントコンポーネントコンポーネント 7
(VC) ViewController Fragment View View Model En@ty En@ty En@ty Model Locator Model En@ty En@ty En@ty API API API プレゼンテーション層ビジネス層データ層 State Machine Local Data Access Modelもコンポーネントの一つよ。まずは、他のコンポーネントとModelの違いをはっきりさせることにするよ。よく使うコンポーネント 8
(VC) ViewController Fragment View View Model En@ty En@ty En@ty Model Locator Model En@ty En@ty En@ty API API API プレゼンテーション層ビジネス層データ層 State Machine Local Data Access まずはプレゼンテーション層から。 9
(VC) ViewController Fragment View View Model En@ty En@ty En@ty Model Locator Model En@ty En@ty En@ty API API API プレゼンテーション層ビジネス層データ層 State Machine Local Data Access Viewは「データを表示」したり「ユーザの操作を受け付ける」部分ね。Class名に〜View となっているやつかな。 ViewというよりWidgetみたいなものだけど。ImageView とかBuLonとかね。ボタンやTextbox等 EventをTargetに送るデータを表示する 10
(VC) ViewController Fragment View View Model En@ty En@ty En@ty Model Locator Model En@ty En@ty En@ty API API API プレゼンテーション層ビジネス層データ層 State Machine Local Data Access 次は、iOSならViewController、AndroidならAc@vityや Fragmentと呼ばれる部分ね。iOS的な呼び名で悪いけど、今後VCと呼ぶことにするわ。古典MVCでいうViewというのはこのVCのことだと思うけど、論争になるので略ユーザの操作で生成・消滅ボタン連打などで頻繁に生成・消滅もあり得る 1画面1+インスタンスボタンやTextbox等 EventをTargetに送るデータを表示する UIの状態制御とModelとの対話 11
(VC) ViewController Fragment View View Model En@ty En@ty En@ty Model Locator Model En@ty En@ty En@ty API API API プレゼンテーション層ビジネス層データ層 State Machine Local Data Access VCの役割は画面の制御。Viewとの対話、画面の状態制御、Modelとの対話、が主な役割ね。複雑なビジネスロジックが入り込みがちなのは世の常だけど、ある程度経験がある人はそれを意識して回避するわね。ユーザの操作で生成・消滅ボタン連打などで頻繁に生成・消滅もあり得る 1画面1+インスタンスボタンやTextbox等 EventをTargetに送るデータを表示する UIの状態制御とModelとの対話フルスタックVCはよくあるアンチパターン 12
(VC) ViewController Fragment View View Model En@ty En@ty En@ty Model Locator Model En@ty En@ty En@ty API API API プレゼンテーション層ビジネス層データ層 State Machine Local Data Access VCの特性として忘れてはいけないのは、「ユーザの操作で生成・消滅する」ということよ。それがいつなのか基本的に予測が付かないわ。これ重要だから覚えておいてね。あと、Singletonにするとかやめてね。ユーザの操作で生成・消滅ボタン連打などで頻繁に生成・消滅もあり得る 1画面1+インスタンスボタンやTextbox等 EventをTargetに送るデータを表示する UIの状態制御とModelとの対話トキ、安らかに眠れ 13
(VC) ViewController Fragment View View Model En@ty En@ty En@ty Model Locator Model En@ty En@ty En@ty API API API プレゼンテーション層ビジネス層データ層 State Machine Local Data Access 次はビジネス層。 14
(VC) ViewController Fragment View View Model En@ty En@ty En@ty Model Locator Model En@ty En@ty En@ty API API API プレゼンテーション層ビジネス層データ層 State Machine Local Data Access まず、ビジネス層はプレゼンテーション層を参照してはいけないよ。これは絶対のルール。 ✕ ダメ、絶対 15
(VC) ViewController Fragment View View Model En@ty En@ty En@ty Model Locator Model En@ty En@ty En@ty API API API プレゼンテーション層ビジネス層データ層 State Machine Local Data Access En@tyは「データそのもの」よ。他のModelやAPIを参照したり、そういう複雑な操作は一切しないわ。単にList やMapだったり、DTOやValueObjectみたいなシンプルなObjectをイメージしてね。ユーザ入力やデータ層の結果から生成データそのもの List, Map, Object 不変ObjectがBeLer 16
(VC) ViewController Fragment View View Model En@ty En@ty En@ty Model Locator Model En@ty En@ty En@ty API API API プレゼンテーション層ビジネス層データ層 State Machine Local Data Access でも例えば「画面の範囲」を表すEn@tyで「面積を計算」「中央の位置を計算」程度なら良いと思う。でもGlobal なPropertyを参照したりはしない。さじ加減は難しいけどあまり他のClassを参照することはしないかな。ユーザ入力やデータ層の結果から生成データそのもの List, Map, Object 不変ObjectがBeLer 17
(VC) ViewController Fragment View View Model En@ty En@ty En@ty Model Locator Model En@ty En@ty En@ty API API API プレゼンテーション層ビジネス層データ層 State Machine Local Data Access En@tyはアプリケーションの本質となるデータで、フラグとか画面・通信状態とかとはまた違います。ユーザが入力したり、サーバから取得したようなデータね。ユーザ入力やデータ層の結果から生成データそのもの List, Map, Object 不変ObjectがBeLer 18
(VC) ViewController Fragment View View Model En@ty En@ty En@ty Model Locator Model En@ty En@ty En@ty API API API プレゼンテーション層ビジネス層データ層 State Machine Local Data Access En@tyはマルチスレッドの場合などで、不変Objectである方が便利なこともあるけど、そこまで意識しなくても良いかもしれない。スレッド周りの罠はたくさんあるから今回は触れないようにします。ユーザ入力やデータ層の結果から生成データそのもの List, Map, Object 不変ObjectがBeLer スレッドはパンドラの箱 19
(VC) ViewController Fragment View View Model En@ty En@ty En@ty Model Locator Model En@ty En@ty En@ty API API API プレゼンテーション層ビジネス層データ層 State Machine Local Data Access En@tyがSaveとかLoadとかデータ層へのアクセスを提供するケースもあります。でも、オススメはそういうことは Modelに任せてしまって、En@tyは単なるデータくらいの位置づけが良いと思っています。ユーザ入力やデータ層の結果から生成データそのもの List, Map, Object 不変ObjectがBeLer 色々あるからなー 20
(VC) ViewController Fragment View View Model En@ty En@ty En@ty Model Locator Model En@ty En@ty En@ty API API API プレゼンテーション層ビジネス層データ層 State Machine Local Data Access さて、いよいよModel。Modelはデータを取得・提供・計算・保存するのが主な役割。データを扱う中心的な役割ね。内部状態も持つよ。Modelは複数存在して各々取り扱うデータが異なるよ。ここは概ね良いわよね。ユーザ入力やデータ層の結果から生成データそのもの List, Map, Object 不変ObjectがBeLer データの提供・取得・更新の責任者機能やデータグループ毎に存在基本死なない「通知」で変更を伝える 21
(VC) ViewController Fragment View View Model En@ty En@ty En@ty Model Locator Model En@ty En@ty En@ty API API API プレゼンテーション層ビジネス層データ層 State Machine Local Data Access Modelは、基本Singleton的な非常に長寿命なObject、とするわ。「基本死なない」ということ。Sta@cなロジックやHelper的なものは除くけど。これはいつ消滅するかわからないVCやAPIと大きく違う点になるわ。ユーザ入力やデータ層の結果から生成データそのもの List, Map, Object 不変ObjectがBeLer データの提供・取得・更新の責任者機能やデータグループ毎に存在基本死なない「通知」で変更を伝える 22
(VC) ViewController Fragment View View Model En@ty En@ty En@ty Model Locator Model En@ty En@ty En@ty API API API プレゼンテーション層ビジネス層データ層 State Machine Local Data Access Modelは、データの更新があれば「通知」で変更を伝える、とするよ。「通知」は「Callback的なもの」とは少し意味合いが違うよ。これは後でまた説明します。ちなみに ObserverとかNSNo@fica@onは「通知」の実装例だよ。ユーザ入力やデータ層の結果から生成データそのもの List, Map, Object 不変ObjectがBeLer データの提供・取得・更新の責任者機能やデータグループ毎に存在基本死なない「通知」で変更を伝える 23
(VC) ViewController Fragment View View Model En@ty En@ty En@ty Model Locator Model En@ty En@ty En@ty API API API プレゼンテーション層ビジネス層データ層 State Machine Local Data Access この２点「基本死なない」「通知で変更を伝える」というものをModelとした場合、「Modelがない」ことが多い、というのが最初に言っていたことになるわ。ユーザ入力やデータ層の結果から生成データそのもの List, Map, Object 不変ObjectがBeLer データの提供・取得・更新の責任者機能やデータグループ毎に存在基本死なない「通知」で変更を伝える 24
(VC) ViewController Fragment View View En@ty En@ty En@ty En@ty En@ty En@ty API API API プレゼンテーション層ビジネス層データ層 State Machine Local Data Access 要するに、大抵こういう構成になっているイメージね。ユーザ入力やデータ層の結果から生成データそのもの List, Map, Object 不変ObjectがBeLer データ処理ロジック 25
(VC) ViewController Fragment View View Model En@ty En@ty En@ty Model Locator Model En@ty En@ty En@ty API API API プレゼンテーション層ビジネス層データ層 State Machine Local Data Access 「基本死なない」「通知で変更を伝える」という性質が何故大事なのか、というのは後でまた説明するよ。実はそんなもの必要ないかもしれないよね。でも、これが無いから落ちたりグダグダな実装は多いんだよ。ユーザ入力やデータ層の結果から生成データそのもの List, Map, Object 不変ObjectがBeLer データの提供・取得・更新の責任者機能やデータグループ毎に存在基本死なない「通知」で変更を伝える後ほど 26
(VC) ViewController Fragment View View Model En@ty En@ty En@ty Model Locator Model En@ty En@ty En@ty API API API プレゼンテーション層ビジネス層データ層 State Machine Local Data Access とりあえず残りのコンポーネントの説明をしておくよ。ユーザ入力やデータ層の結果から生成データそのもの List, Map, Object 不変ObjectがBeLer データの提供・取得・更新の責任者機能やデータグループ毎に存在基本死なない「通知」で変更を伝える 27
(VC) ViewController Fragment View View Model En@ty En@ty En@ty Model Locator Model En@ty En@ty En@ty API API API プレゼンテーション層ビジネス層データ層 State Machine Local Data Access Model Locatorは、Modelを保持しておくだけのコンポーネント。「Service Locatorパターン」というのがあるけど、その名前をちょっと借りたの。適切な名前かはよくわからないけど… ユーザ入力やデータ層の結果から生成データそのもの List, Map, Object 不変ObjectがBeLer データの提供・取得・更新の責任者機能やデータグループ毎に存在基本死なない「通知」で変更を伝える死なない Modelは誰かが登録する自分では登録しない Modelを返すのが仕事名前むずい 28
(VC) ViewController Fragment View View Model En@ty En@ty En@ty Model Locator Model En@ty En@ty En@ty API API API プレゼンテーション層ビジネス層データ層 State Machine Local Data Access LocatorはSingletonで「ModelのSeLer/GeLerしかない」と思って良いよ。Setはアプリの起動処理時にしかるべき部分で明示的にModel Objectを作成してSetするよ。ユーザ入力やデータ層の結果から生成データそのもの List, Map, Object 不変ObjectがBeLer データの提供・取得・更新の責任者機能やデータグループ毎に存在基本死なない「通知」で変更を伝える死なない Modelは誰かが登録する自分では登録しない Modelを返すのが仕事 29
(VC) ViewController Fragment View View Model En@ty En@ty En@ty Model Locator Model En@ty En@ty En@ty API API API プレゼンテーション層ビジネス層データ層 State Machine Local Data Access 起動時に明示的にSetするメリットはあって「設定(環境情報)を伴うModelの初期化」「Main Thread以外だと初期化できないModelの初期化」が自然に扱えるというところかな。ユーザ入力やデータ層の結果から生成データそのもの List, Map, Object 不変ObjectがBeLer データの提供・取得・更新の責任者機能やデータグループ毎に存在基本死なない「通知」で変更を伝える死なない Modelは誰かが登録する自分では登録しない Modelを返すのが仕事 Singletonだと少し辛い 30
(VC) ViewController Fragment View View Model En@ty En@ty En@ty Model Locator Model En@ty En@ty En@ty API API API プレゼンテーション層ビジネス層データ層 State Machine Local Data Access 他にも、ModelはSingletonで実装しても良いのだけど「Singletonだと単体テストでTest Doubleに置換しにくい」のを解決するし、「Pluginのような実装が後から ModelのObjectを置換できる」というメリットもあるよ。ユーザ入力やデータ層の結果から生成データそのもの List, Map, Object 不変ObjectがBeLer データの提供・取得・更新の責任者機能やデータグループ毎に存在基本死なない「通知」で変更を伝える死なない Modelは誰かが登録する自分では登録しない Modelを返すのが仕事挿げ替え簡単 31
(VC) ViewController Fragment View View Model En@ty En@ty En@ty Model Locator Model En@ty En@ty En@ty API API API プレゼンテーション層ビジネス層データ層 State Machine Local Data Access Model Locatorを使うかどうかは状況次第だけど、さっき言った問題で困ったら使うと良いよ。ユーザ入力やデータ層の結果から生成データそのもの List, Map, Object 不変ObjectがBeLer データの提供・取得・更新の責任者機能やデータグループ毎に存在基本死なない「通知」で変更を伝える死なない Modelは誰かが登録する自分では登録しない Modelを返すのが仕事 32
(VC) ViewController Fragment View View Model En@ty En@ty En@ty Model Locator Model En@ty En@ty En@ty API API API プレゼンテーション層ビジネス層データ層 State Machine Local Data Access 最後にデータ層。 33
(VC) ViewController Fragment View View Model En@ty En@ty En@ty Model Locator Model En@ty En@ty En@ty API API API プレゼンテーション層ビジネス層データ層 State Machine Local Data Access まず、プレゼンテーション層参照することは絶対にダメ。ビジネス層も参照しないのが原則だけど、「APIの結果でEn@ty Objectを返す」のをどう考えるべきか… 密結合で替えが効かないけど、議論の余地はあるのかも？ ✕ ダメ、絶対？ 34
(VC) ViewController Fragment View View Model En@ty En@ty En@ty Model Locator Model En@ty En@ty En@ty API API API プレゼンテーション層ビジネス層データ層 State Machine Local Data Access APIは、外部サービスの通信の仕様を吸収するよ。1リクエスト1インスタンスの短命さ、他のAPIを呼び出さない単純さ、を原則とすると良いと思うよ。短命単純 1リクエスト1インスタンス外部サービスの通信仕様を吸収 APIは他のAPIを使用しないやっぱり単純は最高だぜ 35
(VC) ViewController Fragment View View Model En@ty En@ty En@ty Model Locator Model En@ty En@ty En@ty API API API プレゼンテーション層ビジネス層データ層 State Machine Local Data Access さっきも触れたけど、APIの結果としてビジネス層の En@ty Class Instanceを返すのをみたことがあります。密結合になる、というのがデメリットなんだけど、En@tyが APIと１対１ならありなのかな、と思わなくもない短命単純 1リクエスト1インスタンス外部サービスの通信仕様を吸収 APIは他のAPIを使用しない何か歪だ 36
(VC) ViewController Fragment View View Model En@ty En@ty En@ty Model Locator Model En@ty En@ty En@ty API API API プレゼンテーション層ビジネス層データ層 State Machine Local Data Access 最後、Local Data Accessは、ファイルやDBなどへのアクセスを提供するよ。同期的な場合と非同期的な場合があるかな。ここも色々なケースがありそうだし今回はあまり触れないことにします。短命単純 1リクエスト1インスタンス外部サービスの通信仕様を吸収 APIは他のAPIを使用しないファイル・DBなどへのアクセス 37
これからは「Callbackと通知」「なぜModelが必要なのか」を説明していくよ! 38
Callbackは、ニュアンスとして「（自分と相手が）基本1対1の関係」「1回呼び出すと1回呼び返される(callback)」という意味で使うよ。 1回呼ぶと１回返ってくる１対１ Callback 39
通知は、ニュアンスとして「（自分と相手が）基本1対多の関係」「呼んでも来ない呼ばなくても来る、ことがある」という意味で使うよ。呼んでも来ない呼ばなくても来る１対０...N 通知誰もいないこともあるたくさん相手がいることもある呼ばなくても来る呼んでも来ない 40
Callbackは「(iOSの)Blocks/delegate」や「(Javaの)無名クラス/Interface実装」や「Deferred-‐Promise」を使ってよく実装されるね。Promiseの場合「１対１の関係」では無いけど、とりあえずこっちに分類しておくよ。 [[[API create: productId] onFinish: ^(Result *result) { // 結果の処理 }] execute]; new API(productId).onFinish(new Finish() { @Override public void onFinish(Result result) { // 結果の処理 } }).execute(); Blocks 無名クラス Callback 41
通知は「(iOS)NSNo@fica@onCenter/Key Value Observing(KVO)」「(iOS)delegate」「(Android)Handler」や「Observerパターン」を使ってよく実装されるね。 delegateの場合「１対多の関係」では無いけどね。 NSNo@fica@onCenter Observer パターン通知 42
Callbackでよく使われる「Blocks」「無名クラス」「Deferred-‐Promise」で(通常)共通するのは、「呼び出し側が相手に参照を掴まれていて解除することができない」ということよ。これは実装方式による特徴ね。呼び出し側呼び出される側 Call Callback Blocks、無名クラス、Deferredではここを断ち切る手段がない Callbackでよくある実装 43
通知でよく使われる実装は、「通知を受け取ることを解除する」方法が大抵あるわ。従って、「参照を掴まれて放されない」という問題を回避する手段があるということね。通知受け取り側通知する側通知通知を受け取ることを解除できる通知受け取り側通知受け取り側通知 44 （Handlerだと無いかな？）
違いをまとめるとこうなるよ。この定義が一般的かはよくわからないけど、今回の話の中ではこういう違いを意識してね。通知は実装が少し面倒だけど「解除手段がある」「１対多もOK」なのが重要だよ。 Callback 的通知相手との関係１対１１対多 Callback/通知回数１回呼ぶと１回Callback 基本、不定（だと思っておく）実装方法 Blocks/無名クラス/Deferred (↑この３つはクロージャ系) Delegate/Interface Observerパターン NSNo@fica@onCenter/KVO (Delegate/Interface) 明示的な解除手段クロージャ系だと普通はない普通はある 45
次に「なぜModelが必要なのか」、つまり、「基本死なない」「通知で変更を伝える」がなぜ必要なのか説明するよ！ 46
まず、Modelが無い状態でどういう問題が起こりえるかを考えるよ。 (VC) ViewController Fragment View View En@ty En@ty En@ty En@ty En@ty En@ty API API API プレゼンテーション層ビジネス層データ層 State Machine Local Data Access データ処理ロジックユーザ入力やデータ層の結果から生成データそのもの List, Map, Object ユーザの操作で生成・消滅ボタン連打などで頻繁に生成・消滅もあり得る短命単純 1リクエスト1インスタンス想像する 47
こういう場合、大抵VCがAPIを生成・所有することになるね。また、APIからVCはCallback的になることが多いわ。 (VC) ViewController Fragment View View En@ty En@ty En@ty En@ty En@ty En@ty API API API プレゼンテーション層ビジネス層データ層 State Machine Local Data Access データ処理ロジック短命単純 1リクエスト1インスタンスユーザ入力やデータ層の結果から生成データそのもの List, Map, Object ユーザの操作で生成・消滅ボタン連打などで頻繁に生成・消滅もあり得る生成・所有する Callback 48
VCはAPI Callをした直後に消滅を始めて、Callbackがある頃にはDestroyされているけどInstance自体は生きている（APIが掴んでいるから）ことがある (VC) ViewController Fragment View View En@ty En@ty En@ty En@ty En@ty En@ty API API API プレゼンテーション層ビジネス層データ層 State Machine Local Data Access データ処理ロジック短命単純 1リクエスト1インスタンスユーザ入力やデータ層の結果から生成データそのもの List, Map, Object ユーザの操作で生成・消滅ボタン連打などで頻繁に生成・消滅もあり得る生成・所有する Callback 49
例えばAndroidだとDestroyされたVCで、Dialogなど出そうとすればそれで落ちるわ。VCが連続でAPIを呼び出す実装だと無駄な処理が継続することになるね。こんな風に「危険」と「無駄」の温床になるということね。 (VC) ViewController Fragment View View En@ty En@ty En@ty En@ty En@ty En@ty API API API プレゼンテーション層ビジネス層データ層 State Machine Local Data Access データ処理ロジック短命単純 1リクエスト1インスタンスユーザ入力やデータ層の結果から生成データそのもの List, Map, Object ユーザの操作で生成・消滅ボタン連打などで頻繁に生成・消滅もあり得る生成・所有する Callback やらなくて良い Callbackのコードが動く既に無効なVC 要らん事しないで 50
また、ユーザが何度もそのVCを生成・消滅させるとその度にAPI呼び出しとCallback処理が実行されることになる。このせいで「画面を行ったり来たりしていると重くなる（果てには落ちる）」原因になるよ。 (VC) ViewController Fragment API 短命単純 1リクエスト1インスタンスユーザの操作 (VC) ViewController Fragment API (VC) ViewController Fragment API 生成・消滅生成・消滅生成ユーザの操作で生成・消滅ボタン連打などで頻繁に生成・消滅もあり得る死ねばいいのに通信通信通信連打に負けた 51
•  「危険」と「無駄」の温床 •  「画面を行ったり来たりしていると重くなる」この２点が主要な「問題」よ 52
(VC) ViewController Fragment View View Model Model Locator En@ty En@ty En@ty API API API プレゼンテーション層ビジネス層データ層 State Machine Local Data Access そこでModelを使うよ。こんな風になるよ。生成・所有する Callback 通知所有更新要求基本死なない「通知」で変更を伝える 53
VCは次の手順で動くよ。 •  通知を受け取る準備をしてModelに「要求」を伝える •  消滅する前にModelからの通知受信を解除する (VC) ViewController Fragment onCreate() { this.model = ModelLocator.getXXModel(); this.model.addObserver(this); ... } updateMyView() { XXEn@ty xx = this.model.getXX(); if (xx == null) { this.model.fetchData(); } else { ... } onDestroy() { this.model.removeObserver(this); } こんな感じ 54
(VC) ViewController Fragment View View Model Model Locator En@ty En@ty En@ty API API API プレゼンテーション層ビジネス層データ層 State Machine Local Data Access まず、VCは無効になる前に「通知の受信を解除」するので、前述の「危険と無駄の温床」はなくなるよ。生成・所有する Callback 通知所有更新要求基本死なない「通知」で変更を伝える既に無効なVC 解除する帰宅するときは社用携帯 OFF！ 55
(VC) ViewController Fragment View View Model Model Locator En@ty En@ty En@ty API API API プレゼンテーション層ビジネス層データ層 State Machine Local Data Access また、ユーザの操作で何度もVCが生成されて、Model に何度も「更新要求」を出しても、Modelが内部状態を持って無視するようにできるよ。「既に通信中」「X秒前に通信したから無視」のようにね。生成・所有する Callback 通知所有更新要求基本死なない「通知」で変更を伝える状態によって要求を無視やり過ごし社員！ 56
これで •  「危険」と「無駄」の温床 •  「画面を行ったり来たりしていると重くなる」この問題が解消するよ 57
VCとModelの呼び出しはこんな感じになるよ。 fetchPoint()みたいなのを明示的に呼ぶかは色々あるかな。その辺はModelの挙動ポリシーかな。 MMooddeell VVCC 残高教えて→ ←ごめん、わからんじゃあ調べてよ→ ←通知残高教えて→ ←1000pt だよ通信中 model.getPoint() -‐> null model.fetchPoint() model.getPoint() -‐> 1000 （通信しないかもしれない）決めの問題かな？ 58
他にもModelは通知の仕組みがあるから、異なるVCに即座に変更を伝えることができるよ。Excelみたいに、「シートの値を変えると複数のグラフ表示が変わる」ようなこともできるよ。 (VC) ViewController Fragment Model Model Locator En@ty En@ty En@ty API API API プレゼンテーション層ビジネス層データ層 State Machine Local Data Access 生成・所有する通知基本死なない「通知」で変更を伝える (VC) ViewController Fragment MVCが綺麗にハマるね 59
Excelなんて作らないよ、って思うかもしれないけど、メールの未読数と未読マークも一つのModelを複数VC が参照するケースだよね。こういう場合もModelから通知で考えておくと自然に作れるよ。未読件数表示未読マーク . 戻った時に更新されて欲しい未読更新通知データは一つ 60
まとめると、今回定義したModelでこうなるよ •  危険と無駄の温床、が解決 •  画面を行ったり来たりしていると重くなる、が解決 •  VC間でデータの共有や表示の更新が簡単になる 61
いくつかこの設計に関する議論を紹介するよ 62
開発時は大抵高速回線でアプリを動かすから、気が付きにくいというのもあるのよね議論 API通信なんて１，２秒で終わるから、そこまで神経質にならなくても良いのではないか？ Mobileだと通信環境が悪いときも多いし、その場合かなり時間かかるかな。ユーザもイライラすると連打したりするし。 63
VCがGCされない、ことだけが問題ではないということかな。VCが「終わった、リソース解放！」した後のCallback が危ないんだよ議論明示的に通知を解除しなくても Model側がWeakRef（弱参照）で VC側を掴んでおけば問題ないんじゃないか？確かに弱参照は推奨されることが多いね。でも、AndroidでDestroyからInstanceが破棄されるまでの間にCallbackが発生すれば問題は同じだよ 64
フラグが乱立するのは死亡フラグ議論通知を解除とかしなくても、無効flag立てて Callback内で無効flagをチェックするとかでも良いのではないか？参照を掴まれている間はVCは消滅しないからメモリの解放が遅れるけど、そういうのが大丈夫なら大きな問題はないかもね。でも、そういうFlagって美しくないなぁ。忘れそうだし。フラグを折れる人になりたい 65
cancel()は通知を解除しつつ、さらにcancel()というように使うと良いよ。議論 VCからcancel()みたいなのを送れれば良いのではないか？確かにcancel()が有効なケースもあるね。特にcancel()によってキューイングされている未実行の重たい処理が破棄できる場合とかね。 66
構造的に潜在的なリスクがあるのは怖いよね議論 Callback処理がたいして無駄でも危険でもない場合は問題ないのではないか？今は危険ではなくても、将来誰かが「問題になる処理」を付け足す可能性があるわ。そういう地雷は無い方が良いと思うの。 67
UIの快適さはNa@veアプリの大事な強みだしね議論通信中なら画面遷移させない・VC破棄させないとか、そういう考えで良いんじゃないか？通信中だろうがユーザの操作はなるべく妨げ無い方が良いよね？それって最後の手段だと思うんだ。 68
志を下げないで議論連打するのはユーザが悪い、とか、そういう考えで良いんじゃないか？ユーザは悪くないよ。可能な操作をしているのに落ちたり重くなる方が悪いよね。ExcelとかPPTが落ちたらその人のせいなの？ 69
「今回のModel定義」ってサーバサイド開発をやってきた人には馴染みがなくて抵抗があるんじゃないかと思うの。私も実はその口なのよ。でも、クライアントアプリをやってきた人には普通らしいんだよね。余談 70
サーバサイドのアプリだと、「リクエストが来てレスポンスを返す」というのが鉄板の流れだよね。サーバリクエスト Controller Model DAO レスポンス PHPとか 71
この場合、各層の静的な参照構造の依存関係をなくしたり、操作を抽象化しておけば、結構良い感じになるよね。 Controller Model DAO 抽象化依存性注入サーバ 72
クライアントアプリだと、それぞれの層に予測しにくいタイミングでイベントが発生するね。特にユーザの操作は読めないわ。 VC Model DAO ユーザの操作 APIレスポンスセンサーデバイス出入口多数クライアント 73
なんかもう住んでる世界が違う感じだと思うの。だからクライアントアプリの場合は、VC-‐Model間はタイミング的な依存関係も無いようなイメージで作る方が上手くいく気がするの。 Model Ac@ve VC Ac@veなVCは移り変わる・指先一つで死ぬ長寿・マイペース APIレスポンスセンサーデバイスユーザの操作ユーザの操作 74
呼んだら呼ばれる、ではなく、お互い好き勝手にメッセージを送り合うような。それで問題なく動くように作るべきかと。そのために互いに状態を持ち、メッセージへの反応には自己責任で対応する感じかな！ Model Ac@ve VC Ac@veなVCは移り変わる・指先一つで死ぬ長寿・マイペース APIレスポンスセンサーデバイスユーザの操作ユーザの操作タイミング的にも緩い結合独自の「時」を刻む独自の「時」を刻む 75
今のは私の脳内イメージの余談だったけど、クライアントアプリケーションの性質を把握した上で設計を検討すると良いと思うよ。 76
77
参考 •  AAfN: アプリケーションとサービスの設計 –  hLp://msdn.microsoq.com/ja-‐jp/library/ms978348.aspx 78

Check these out next

iOS/Androidアプリエンジニアが理解すべき「Model」の振る舞い

Recommended

More Related Content

Slideshows for you(20)

Similar to iOS/Androidアプリエンジニアが理解すべき「Model」の振る舞い(20)

More from Ken Morishita(7)

Recently uploaded(20)

iOS/Androidアプリエンジニアが理解すべき「Model」の振る舞い