Transcript

• 1. 効率的なアプリ開発の ベストプラクティス グリー株式会社 矢口裕也
• 2. そういえば 一昨年の今頃に Conference with Developers があり ! 去年の今頃に Conference with Developers 2 というイベントをやっていました。（主催させていただきました） ! 主催者毎回異なるのにiOSの土日イベントが一年おきペースになって いておもしろい
• 3. そういえば2 iOS4.3∼5の時代にPhoneGapみたいなライ ブラリの保守をしたトラウマあり UIWebViewはこわい
• 4. iOS開発の醍醐味： 一つ一つの画面に注力して最高 のアプリを作っていく
• 5. 最高のUXを求めるとき 一つの画面をじっくり時間をかけて磨き上げ ていくことができる 標準パーツを再実装したり、独自UIをつくっ たり、美しいアニメーションをたくさん付け たり
• 6. 一方で 最高のUXを提供する必要のない箇所もある 設定画面とか、大人の事情で追加することになった機能とか (ex. 電子書籍アプリをつくっていたのになぜかFacebook的 なタイムラインの投稿とコメントといいねできる機能を開発 している…） そこまで楽しくないし、すばやく実装することが求められる
• 7. そういうとき なるべく早くつくってしまいたい ＝開発速度を上げたい ! 品質は必要十分であればよい
• 8. 効率的に実装するにはどうし たらいいか
• 9. 大原則：やることを減らす
• 10. 大原則：やることを減らす 単純に作業量を減らすことができればスピード は上がる ! 1. UIの実装コストを減らす 2. 通信の実装コストを減らす
• 11. UIの実装コスト 昔に比べるとだいぶ楽になった
 ・端末の性能向上
 ・Auto Layout ・Storyboard ・Self Sizing Cell
• 12. 改善の余地 React.jsみたいなアプローチ（View の diff & patch)はよ さそう ・ReactNativeに期待 ・小規模であれば自分でも作れる  （NSProgrammersのUITableView+Updatesのような）
• 13. Demo
• 14. 通信の実装コスト ・ほぼ仕様に依存する ・仕様＝だいたいの場合サーバー側が決める ! 実装コストを減らすには？
• 15. 大原則：やることを減らす
• 16. サーバーに処理を任せる どちらでも行える処理であれば サーバー側でやってしまった方が 実装コストが低く修正も簡単になる
• 17. API 共通化・RESTなどにとらわれない。 個々の（iOS, Android別）クライアントの各 画面の都合、
 ライブラリ（Mantle, JSONModel) の都合に 合わせたjsonファイルを返してもらうこと
• 18. State ・ダウンロード可能なアセットを持たない ・クライアント側でCacheを持たない（画像 除く） ・クライアント側でローカルストアを利用し ない。毎回サーバーから取得する
• 19. 例 右のような画面 ・お知らせ ・投稿&コメント Post Post
• 20. 例 API仕様 画面の表示に必要なリソース一覧 ・api.hoge.com/timeline_notification.json ・api.hoge.com/posts.json ・api.hoge.com/comments.json ・hoge.foo-cdn.com/locales/ja.json (asset)
• 21. 例 API仕様 v2 ・api.hoge.com/ios/timeline_top.json ・api.hoge.com/ios/timeline_more.json ・hoge.foo-cdn.com/locales/ja.json (asset) ! comment, post, notificationを統合
• 22. 例 API仕様 v3 ・api.hoge.com/ios/timeline_top.json ・api.hoge.com/ios/timeline_more.json ! localeをサーバーで処理するように。 各JSONのResponseがあらかじめlocale適用 済みに
• 23. サーバー側仕様変更で問題に なるもの ・綺麗な RESTful API のサーバー ・レガシーサーバー
• 24. 綺麗な RESTful API サーバー ・汎用的なAPIであることを理由に特定画面 に特化したAPIを断られることが多い ・原理主義的だとbatch requestの実装すら断 られることがある
• 25. レガシーサーバー ・触るのが怖い ・同じような処理をする新APIを実装した場 合に、実装で共通部を抽出するなどでリファ クタリングしようとするとデグレそうで怖い
• 26. サーバー側をどう説得するか ・パフォーマンスの向上などメリットを説明 ・クライアントの大変さを訴える ・サーバー側も一部自分で書く
• 27. メリットを説明 先ほどの例だと ・リクエスト数4→1となり表示が高速に ・アセット読み込みがなくなるため起動が高 速化。離脱率下がる など
• 28. サーバー側も一部自分で書く ・特にサーバー側エンジニア忙しくて手が回っ ていない場合に有効 ・強いマインドを持つことが大事
• 29. それでもだめなら……
• 30. 中継サーバーをたてましょう Client Proxy for Client REST Server Legacy Server Private Network Client 開発者が書く PHP とかで
• 31. まとめ ・UIまわりの実装はだいぶ楽になった ・通信周りはプロトコルをどう定義するかで 工数がグッと変わる ・サーバーサイドとの協力関係が大切