More Related Content
More from Ken Morishita (6)
IOS/Androidアプリの3つの大事な設計方針
- 5. 端的に言うとこういうこと
• Model と それ以外を分ける
• Objectのライフサイクルと参照関
係の整理理をしよう
• ⾮非同期制御でState Machineを活⽤用
しよう
11つずつ説明していくよ
- 7. まずは「MMooddeellって何?」っ
てことよね。
MMooddeellが意味する範囲は広い
のよ。
基本的にはアプリケーション
データの本質的な処理をする
のがMMooddeellに相当するわ。
といってもピンとこないから、
「何がMMooddeellでないか?」を
考えるとわかりやすいよ。
- 8. 簡単に言うとMMooddeellは
アプリの中でUUIIに関係しない部分
つまりUUIIに関係する部分はMMooddeell
ではないわ
UI=User Interface: ユーザの操作を受け付けたり何かを表⽰示をする部分
- 11. MMooddeellはUUIIに無関係の部分だ
から、
iiPPhhoonneeとiiPPaaddのようにVViieeww
のレイアウトが全く違うよう
な場合でも再利用できるはず
の部分なの。
もしVViieewwが変わったときに、
大きいコピペが必要ならそれ
はMMooddeellかもよ?
極端な話、CCUUIIでもMMooddeellの
部分は再利用できるはず。
CUI=Command UI: テキストベースのUI. Shellとか。
- 15. MMooddeell
EEddiittoorr
お前は絶対にダメだ
MMooddeell → EEddiittoorrは直接アクセスしてはダメ
EEddiittoorr部分は代替可能
なのだから当然よね。
MMooddeellはEEddiittoorrの
具体的な存在を知らないものよ
- 17. MMooddeell EEddiittoorr
ポイント残⾼高を教えて!
例えば、残高を表示したい場合
1000ptだよ
すぐにわかる((同期的にrreettuurrnn
で値が返せる)ならこんなかん
じになるね。
return
- 18. MMooddeell EEddiittoorr
ポイント残⾼高を教えて!
例えば、残高を表示したい場合
あ、今調べるわ
でも、通信したりしないとわか
らないケースがあるよね。その
場合は同期的に値は返せないの。
あっそ, 待ってるよ
return
- 20. MMooddeellからEEddiittoorrへの通知方法
• Observerパターンを使う
• iOS なら NSNotificationCenter を
使っても良良い
こういうときは
OObbsseerrvveerrパターンやその類
似の方法を使うのが普通だね
Observerパターン: デザインパターンの⼀一つ。知らなければググってみよう。
- 23. MMooddeell EEddiittoorr
調べてよ→
←了解
調べてよ→
←了解
調べてよ→
←了解
←通知
通信中
通信中
通信中
←通知
←通知
こんなMMooddeellはダメよ
高橋名人の連打で
アプリが落ちるわ
- 25. じゃあ、まとめるよ
• Model → Editor の直接参照はしない
• ⾮非同期で結果を返すときは Observer
パターンなどを使う
• Modelはいつどんな指⽰示を受けても問
題を起こさないことが⼤大事とても大事なことだか
ら覚えておいてね!
- 30. C
逆に「短命」 → 「長命」
という参照だけだと、
短命OObbjjeeccttが消滅したとき
に一緒に長命OObbjjeeccttが消滅
してしまうよね。
A B
本当は⻑⾧長命
C
A B
事故死天寿
- 32. ライフサイクルと参照関係
• ⻑⾧長命→短命 が基本
• 各Objectがどういうライフサイク
ルであるべきか、を念念頭に参照関
係を設計するのが⼤大事
当たり前体操よね
- 37. 最もよく見かける問題それは
PPaaggeeCCoonnttrroolllleerrだけが本来
長命であるOObbjjeeccttを生成・
維持・使用する
というケースよ
- 43. MMooddeell PPaaggeeCCoonnttrroolllleerr
調べてよ→
通信中
調べてよ→
既読スルー
MMooddeellRReeppoo
生成
Model頂戴
どうぞ
Model頂戴
どうぞ
実現例としては例えば、
MMooddeell RReeppoossiittoorryyのよ
うな超長命のOObbjjeeccttが
MMooddeellを生成・維持する
方法があるわね
- 51. PPaaggee
CCoonnttrroolllleerr
FFrraammeewwoorrkk
UUII
通信
SSeennssoorr//DDeevviiccee
Create/Destroy,
Resume/Suspend
Tap,
etc…
OK,
Error
GPS,
BLE,
Camera
そもそもPPaaggeeCCoonnttrroolllleerr((以降
PPCCと略))は色々なEEvveennttを処理
する必要があるし、
EEvveennttはどんな順番でいつ来る
かはほぼわからないわけよ。
画面表示
どんとこい
- 53. SSttaattuuss管理の場合、
どのSSttaattuussの時にどういう
EEvveennttが来たら、次にどの
SSttaattuussになるかという決まり
があるけど、それが各EEvveenntt
HHaannddlleerrに分散記述されると見
通しが悪くなる。
IIffやsswwiittcchhが大量に出てくる感
じね。こうなると可読性が落ち
ていくわ。
FFllaaggの場合も同様ね。
- 55. じゃあ、どうするか?
簡潔にいうと
SSttaattee MMaacchhiinnee((略してSSMM))を別
途作って状態をそこで管理する
ということよ
SSMMは次の事が主な役割よ
-- EEvveennttを受け付けて状態を遷移
-- 遷移時にAAccttiioonnを呼び出す
状態機械
- 56. 概要はこのくらいにして
例で考えましょう
TTOODDOOを管理するアプリを考え
るわ
TTOODDOO情報はサーバにあり、そ
れを操作するMMooddeellは既にある
とするよ
TODO管理
- 57. TODO3
TODO1
TODO2
削除
削除
削除
削除しますか?
OK
Cancel
• サーバとの通信中はクルクルインジケーターを表示
• TODOをListで表示
• それぞれ削除ボタンがある
• 削除ボタンを押すと、ダイアログが表示されて本当
に削除するか尋ねる。Yesなら削除、Noなら何もしな
い。
• Yesならサーバと通信して、削除成功かエラーかをダ
イアログで表示する
• 削除処理中は、新たな削除は受け付けない。
ざっくり仕様よ
画⾯面イメージ
- 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.. 状態遷移の変更に強い
- 68. こんな感じかなぁ
OOKK//NNGG,, YYeess//NNoo
とかは共通で良いか
もね
- 69. さっきの遷移図が良いかは置い
ておいて、
大事なのは、あのグラフを見て
どういう状態を考えるべきかと
いう本質的な問題に集中できる
ことよ。レビューも著しく捗る
わ。
FFllaagg管理だともうこの複雑レベ
ルですら可読性が超低下してい
ると思うよ
- 71. SSMMCCのDDSSLLで状態を記述する。
さっきSSMMなら例えばこうよ。
hhttttppss::////ggiisstt..ggiitthhuubb..ccoomm//mmookkeemmookkeecchhiicckkeenn//99773333556655 ((7733行))
遷移図画像とかも出力できるか
らとても便利じゃない?
((要GGrraapphhvviizz))
- 73. じゃあ、まとめるよ
• State Machineですっきり実装しよう
• Page Controllerだけじゃなくて
Modelの実装でも使えるよ
• State Machineは⾃自動⽣生成が楽
とても大事なことだか
ら覚えておいてね!
- 74. さいごにもう一度
• Model と それ以外を分ける
• Objectのライフサイクルと参照関
係の整理理しよう
• ⾮非同期制御でState Machineを活⽤用
しよう
大事なことだから22度言います