IOS/Androidアプリの3つの大事な設計方針

31,246 views
30,947 views

Published on

Published in: Technology
0 Comments
219 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
31,246
On SlideShare
0
From Embeds
0
Number of Embeds
1,733
Actions
Shares
0
Downloads
262
Comments
0
Likes
219
Embeds 0
No embeds

No notes for slide

IOS/Androidアプリの3つの大事な設計方針

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

×