IOS/Androidアプリの３つの大事な設計方針
- 5. 端的に言うとこういうこと • Model と それ以外を分ける • Objectのライフサイクルと参照関 係の整理理をしよう • ⾮非同期制御でState Machineを活⽤用 しよう 11つずつ説明していくよ
- 7. まずは「MMooddeellって何？」っ てことよね。 MMooddeellが意味する範囲は広い のよ。 基本的にはアプリケーション データの本質的な処理をする のがMMooddeellに相当するわ。 といってもピンとこないから、 「何がMMooddeellでないか？」を 考えるとわかりやすいよ。
- 8. 簡単に言うとMMooddeellは アプリの中でUUIIに関係しない部分 つまりUUIIに関係する部分はMMooddeell ではないわ UI=User Interface: ユーザの操作を受け付けたり何かを表⽰示をする部分
- 10. MMooddeellが行うことをいくつか 挙げてみると、こんな感じ • 通信処理理 • DB操作、データの永続化 • そのアプリ独特の計算処理理 こういうのってUUII関係ないよね？
- 11. MMooddeellはUUIIに無関係の部分だ から、 iiPPhhoonneeとiiPPaaddのようにVViieeww のレイアウトが全く違うよう な場合でも再利用できるはず の部分なの。 もしVViieewwが変わったときに、 大きいコピペが必要ならそれ はMMooddeellかもよ？ 極端な話、CCUUIIでもMMooddeellの 部分は再利用できるはず。 CUI=Command UI: テキストベースのUI. Shellとか。
- 12. アプリケーション UIに関わる部分 UIに関わらない部分 MMooddeell ここが「EEddiittoorr」 あと「MMooddeell以外」だと呼びにくいから、 今後その部分を「EEddiittoorr」と呼ぶことにするよ
- 13. MMooddeell EEddiittoorr 気軽に超えてはいけない壁 MMooddeellとEEddiittoorrの間のやりとりには、 絶対に守るべきルールがある
- 14. MMooddeell EEddiittoorr よし通れ！ EEddiittoorr → MMooddeellは自由にアクセスして良いわ
- 15. MMooddeell EEddiittoorr お前は絶対にダメだ MMooddeell → EEddiittoorrは直接アクセスしてはダメ EEddiittoorr部分は代替可能 なのだから当然よね。 MMooddeellはEEddiittoorrの 具体的な存在を知らないものよ
- 16. じゃあ、MMooddeellからEEddiittoorrに アクセスすることは無いのか？ もちろん、そんなわけはないよね
- 17. MMooddeell EEddiittoorr ポイント残⾼高を教えて！ 例えば、残高を表示したい場合 1000ptだよ すぐにわかる((同期的にrreettuurrnn で値が返せる）ならこんなかん じになるね。 return
- 18. MMooddeell EEddiittoorr ポイント残⾼高を教えて！ 例えば、残高を表示したい場合 あ、今調べるわ でも、通信したりしないとわか らないケースがあるよね。その 場合は同期的に値は返せないの。 あっそ, 待ってるよ return
- 19. MMooddeell EEddiittoorr あ、、今調べるわ そういうとき、通信が終わった ことを通知する仕組みが必要に なるよ 待ってるよ return あれ、どう伝えよう？
- 20. MMooddeellからEEddiittoorrへの通知方法 • Observerパターンを使う • iOS なら NSNotificationCenter を 使っても良良い こういうときは OObbsseerrvveerrパターンやその類 似の方法を使うのが普通だね Observerパターン: デザインパターンの⼀一つ。知らなければググってみよう。
- 21. MMooddeell EEddiittoorr 残高教えて→ ←ごめん、わからん じゃあ調べてよ→ ←待ってろ ←通知 残高教えて→ ←1000pt だよ 典型的な全体の流れは こんな感じになるよ 通信中
- 22. あと、MMooddeellはいつどんな指示 を受けても問題を起こさない振 る舞いが求められるの。 つまり、外部からの指示に言わ れるがまま従っていてはダメよ
- 23. MMooddeell EEddiittoorr 調べてよ→ ←了解 調べてよ→ ←了解 調べてよ→ ←了解 ←通知 通信中 通信中 通信中 ←通知 ←通知 こんなMMooddeellはダメよ 高橋名人の連打で アプリが落ちるわ
- 24. MMooddeell EEddiittoorr 調べてよ→ ←了解 MMooddeell自身の判断で 動作を変えて良いの。 サーバみたいなものね。 調べてよ→ ←はいはい 調べてよ→ ←はいはい ←通知 通信中
- 25. じゃあ、まとめるよ • Model → Editor の直接参照はしない • ⾮非同期で結果を返すときは Observer パターンなどを使う • Modelはいつどんな指⽰示を受けても問 題を起こさないことが⼤大事とても大事なことだか ら覚えておいてね！
- 27. OObbjjeeccttには生成と消滅があるよ。 OObbjjeeccttの寿命はそれぞれ違う。 いつ生まれていつ死ぬかをライフ サイクルと呼びます。 ライフサイクル ⽣生成 使⽤用 消滅 とあるObjectの⼀一⽣生
- 28. OObbjjeeccttは誰かの指示で生成され て、参照を保持されるの。 そして基本的に誰からも参照さ れないと消滅します。 孤独死上等 A B ⽣生成・保持 A B 消滅
- 29. だから通常は 「長命」 → 「短命」 という参照関係で存在を維持 するわ せいぞーんせんりゃくー
- 30. C 逆に「短命」 → 「長命」 という参照だけだと、 短命OObbjjeeccttが消滅したとき に一緒に長命OObbjjeeccttが消滅 してしまうよね。 A B 本当は⻑⾧長命 C A B 事故死天寿
- 31. あとライフサイクルが無関係 なOObbjjeeccttが参照を保持する と消滅できなくなるね。 メモリ不足の原因になるわ。 A B ライフサイクルが無関係 なのに参照関係がある C 「死ねない、、」 本来の参照
- 32. ライフサイクルと参照関係 • ⻑⾧長命→短命 が基本 • 各Objectがどういうライフサイク ルであるべきか、を念念頭に参照関 係を設計するのが⼤大事 当たり前体操よね
- 34. AAnnddrrooiiddだと AAccttiivviittyyやFFrraaggmmeenntt iiOOSSだと VViieewwCCoonnttrroolllleerr というのがあるよね？
- 35. これらは 画面が遷移すると生成されたり 破棄�されたりするじゃない？ 便宜的にPPaaggeeCCoonnttrroolllleerr（造 語）と呼ぶことにするわ。 WWeebbでいう、一つのページを 制御する役割という感じかしら。
- 36. PPaaggeeCCoonnttrroolllleerrは比較的短命よね ユーザの操作で生成・消滅を繰り 返すわ 遷移喪失
- 37. 最もよく見かける問題それは PPaaggeeCCoonnttrroolllleerrだけが本来 長命であるOObbjjeeccttを生成・ 維持・使用する というケースよ
- 38. MMooddeell PPaaggeeCCoonnttrroolllleerr 調べてよ→ 通信中 FFWW 生成 生成 死んで 調べてよ→ 生成 死んで 生成 通信中 操作(進む) 操作(戻る) 操作(進む) 操作(戻る) 操作(進む) 操作(戻る) こんな感じになるよ
- 39. 今の場合だとユーザが画面を 行ったり来たりするだけで通 信が多重に発生するわね。 通信中のMMooddeellは生き残るか らIInnnneerrCCllaassssとかをMMooddeellに 渡すとPPaaggeeCCoonnttrroolllleerrとそ の配下のVViieewwも大抵生き残る。 どんどん動作が重くなるわ。
- 40. ユーザの操作は防ぐことがで きない（ケースが多い）わ。 問題は何度も不要な重い処理 をするMMooddeellの方にあるわ。
- 41. MMooddeell PPaaggeeCCoonnttrroolllleerr 調べてよ→ 通信中 生成 調べてよ→ 生成 通信中 でもこの構造だと MMooddeellは都度生成され てるから通信中かどう か判断できないわ
- 42. MMooddeell PPaaggeeCCoonnttrroolllleerr 調べてよ→ 通信中 調べてよ→ 既読スルー MMooddeellが状態を維持できれば、回避する こともできるわね。つまりこのMMooddeellは PPaaggeeCCoonnttrroolllleerrより長命であるべきな のよ
- 43. MMooddeell PPaaggeeCCoonnttrroolllleerr 調べてよ→ 通信中 調べてよ→ 既読スルー MMooddeellRReeppoo 生成 Model頂戴 どうぞ Model頂戴 どうぞ 実現例としては例えば、 MMooddeell RReeppoossiittoorryyのよ うな超長命のOObbjjeeccttが MMooddeellを生成・維持する 方法があるわね
- 44. よくサンプルコードで vviieewwDDiiddLLooaadd(()) とかに直接 NNSSUURRLLCCoonnnneeccttiioonnみたいな通信 OObbjjeeccttを生成しているのを見か けるけど あれはデモコードだから許される だけだから 製品コードではダメ、絶対
- 46. PPaaggeeCCoonnttrroolllleerrの他にも TTaabblleeのCCeellllの中のIImmaaggeeVViieewwな どはCCeellllが再利用されたりするか ら気をつける必要があるわ とにかく 短命((EEddiittoorr系))→長命((MMooddeell系） の関係は気をつけた方がいいよ EEddiittoorrはユーザの操作で状態が 変わるからね
- 47. じゃあ、まとめるよ とても大事なことだか ら覚えておいてね！ • 各Objectがどういうライフサイクル であるべきか、を念念頭に参照関係を 設計するのが⼤大事 • PageControllerのModel直接⽣生成は 特に注意 • おかしいなと思ったら基本に⽴立立ち返 ろう
- 49. アプリを作っていると CCoonnttrroolllleerr的な役割のCCllaassssが どんどん肥大化していくことが あるじゃない？ そういうのは FFaatt CCoonnttrroolllleerr と呼ばれる皆よく困っている状 況なのよね
- 50. MMooddeellのコードがCCoonnttrroolllleerrに 混入�しているケースは論外よ。 でも、PPaaggeeCCoonnttrroolllleerrのよう なCCoonnttrroolllleerrは画面の状態を制 御しないといけないのだけど、 状態が増えると管理が難しく なってくるわ。 そういう場合のだいぶマシな実 装方法の話をするわ。
- 51. PPaaggee CCoonnttrroolllleerr FFrraammeewwoorrkk UUII 通信 SSeennssoorr//DDeevviiccee Create/Destroy, Resume/Suspend Tap, etc… OK, Error GPS, BLE, Camera そもそもPPaaggeeCCoonnttrroolllleerr((以降 PPCCと略))は色々なEEvveennttを処理 する必要があるし、 EEvveennttはどんな順番でいつ来る かはほぼわからないわけよ。 画面表示 どんとこい
- 52. 通常各EEvveenntt HHaannddlleerrがPPCCの メソッド((やクロージャ))として 定義される。 そのEEvveennttが来た時の処理は、 他のEEvveennttの発生状況（→現在 の状態）に依存することが多い。 つまりHHaannddlleerrのLLooccaallな状態 だけでは決められないので、現 在の状態をPPCC全体で共有する ためにFFllaaggやSSttaattuussで管理す るようになる。 Event Handler： Eventを処理する部分
- 53. SSttaattuuss管理の場合、 どのSSttaattuussの時にどういう EEvveennttが来たら、次にどの SSttaattuussになるかという決まり があるけど、それが各EEvveenntt HHaannddlleerrに分散記述されると見 通しが悪くなる。 IIffやsswwiittcchhが大量に出てくる感 じね。こうなると可読性が落ち ていくわ。 FFllaaggの場合も同様ね。
- 54. UUIIやVViieewwの仕様は極めて変わり やすいわ PPCCはその影響をモロに受ける PPCCの可読性や保守性を高くで きれば、多くの人がハッピーに なれるわけよ 仕変もこい
- 55. じゃあ、どうするか？ 簡潔にいうと SSttaattee MMaacchhiinnee((略してSSMM))を別 途作って状態をそこで管理する ということよ SSMMは次の事が主な役割よ -- EEvveennttを受け付けて状態を遷移 -- 遷移時にAAccttiioonnを呼び出す 状態機械
- 56. 概要はこのくらいにして 例で考えましょう TTOODDOOを管理するアプリを考え るわ TTOODDOO情報はサーバにあり、そ れを操作するMMooddeellは既にある とするよ TODO管理
- 57. TODO3 TODO1 TODO2 削除 削除 削除 削除しますか？ OK Cancel • サーバとの通信中はクルクルインジケーターを表示 • TODOをListで表示 • それぞれ削除ボタンがある • 削除ボタンを押すと、ダイアログが表示されて本当 に削除するか尋ねる。Yesなら削除、Noなら何もしな い。 • Yesならサーバと通信して、削除成功かエラーかをダ イアログで表示する • 削除処理中は、新たな削除は受け付けない。 ざっくり仕様よ 画⾯面イメージ
- 60. PPaaggee CCoonnttrroolllleerr SSttaattee MMaacchhiinnee ② 状態遷移したら Actionを呼び出す ① Eventを送る PPCCとSSMMとの関係はこう。 PPCCはAAccttiioonnを実装する。
- 61. 例えば 呼び出すAAccttiioonnを こうしておく Action
- 62. この場合、 PPCCが実装するAAccttiioonnは 以下のものになるね -‐‑‒ updateModel -‐‑‒ showDeleteConfirm -‐‑‒ closeDialog -‐‑‒ deleteModel -‐‑‒ showResult -‐‑‒ finishComm
- 63. 33つを並べてみる 整列 -‐‑‒ updateModel -‐‑‒ showDeleteConfirm -‐‑‒ closeDialog -‐‑‒ deleteModel -‐‑‒ showResult -‐‑‒ finishComm
- 64. このやり方のメリットはこんなと ころかしら 11.. 状態遷移がグラフ化され何を したいか理解がし易い 22.. 各AAccttiioonnの位置づけが明確な ので実装しやすい 33.. ボタンの連打や予期せぬ EEvveennttを考慮しなくて良い 44.. 要するに可読性が高い 55.. 状態遷移の変更に強い
- 65. 例えば、仕様変更があるとする Deleteボタンを押した時に サーバに削除可能か確認するよ うにしてください と
- 66. この辺が変わるわね
- 67. また、仕様変更があるとする Deleteが成功したらTodoリスト をサーバから再取得してくださ い と
- 68. こんな感じかなぁ OOKK//NNGG,, YYeess//NNoo とかは共通で良いか もね
- 69. さっきの遷移図が良いかは置い ておいて、 大事なのは、あのグラフを見て どういう状態を考えるべきかと いう本質的な問題に集中できる ことよ。レビューも著しく捗る わ。 FFllaagg管理だともうこの複雑レベ ルですら可読性が超低下してい ると思うよ
- 70. ただ、このSSMMの実装を手でやる と大変。最後の遷移図でJJaavvaaで 880000行くらいになったりするわ。 そこで SMC http://smc.sourceforge.net/ というのを使っているわ。 SMC
- 71. SSMMCCのDDSSLLで状態を記述する。 さっきSSMMなら例えばこうよ。 hhttttppss::////ggiisstt..ggiitthhuubb..ccoomm//mmookkeemmookkeecchhiicckkeenn//99773333556655 ((7733行)) 遷移図画像とかも出力できるか らとても便利じゃない？ ((要GGrraapphhvviizz))
- 72. hhttttpp::////ggooooddppaarrttss..dd..yyuummeemmii..jjpp//ggeenneerraattoorr##SSttaatteeMMaacchhiinneeGGeenneerraattoorr---- dd2233558833bb0044ddaa44ff77bb22ff88ccbbaa3399ee664411ff11aa117722ee6677bbcc55dd とかでさっきの例が見れるよ SSMMCCのツール群を各開発機に IInnssttaallllするのも面倒なので、 WWeebb化したよ hhttttpp::////ggooooddppaarrttss..dd..yyuummeemmii..jjpp// 一応メンテナンスしていくつも りだから誰が使っても良いよ ご自由に
- 73. じゃあ、まとめるよ • State Machineですっきり実装しよう • Page Controllerだけじゃなくて Modelの実装でも使えるよ • State Machineは⾃自動⽣生成が楽 とても大事なことだか ら覚えておいてね！
- 74. さいごにもう一度 • Model と それ以外を分ける • Objectのライフサイクルと参照関 係の整理理しよう • ⾮非同期制御でState Machineを活⽤用 しよう 大事なことだから22度言います