効率的なアプリ開発の ベストプラクティス

グリー株式会社 矢口裕也

そういえば

一昨年の今頃に Conference with Developers があり

!去年の今頃に Conference with Developers 2 というイベントをやっていました。（主催させていただきました） !主催者毎回異なるのにiOSの土日イベントが一年おきペースになっていておもしろい

そういえば2

iOS4.3～5の時代にPhoneGapみたいなライブラリの保守をしたトラウマあり UIWebViewはこわい

iOS開発の醍醐味： 一つ一つの画面に注力して最高

のアプリを作っていく

最高のUXを求めるとき

一つの画面をじっくり時間をかけて磨き上げていくことができる 標準パーツを再実装したり、独自UIをつくったり、美しいアニメーションをたくさん付けたり

一方で

最高のUXを提供する必要のない箇所もある 設定画面とか、大人の事情で追加することになった機能とか(ex. 電子書籍アプリをつくっていたのになぜかFacebook的なタイムラインの投稿とコメントといいねできる機能を開発している…） そこまで楽しくないし、すばやく実装することが求められる

そういうとき

なるべく早くつくってしまいたい ＝開発速度を上げたい !

品質は必要十分であればよい

効率的に実装するにはどうしたらいいか

大原則：やることを減らす

大原則：やることを減らす

単純に作業量を減らすことができればスピードは上がる !

1. UIの実装コストを減らす

2. 通信の実装コストを減らす

UIの実装コスト

昔に比べるとだいぶ楽になった

・端末の性能向上

・Auto Layout

・Storyboard

・Self Sizing Cell

改善の余地

React.jsみたいなアプローチ（View の diff & patch)はよさそう ・ReactNativeに期待 ・小規模であれば自分でも作れる 　（NSProgrammersのUITableView+Updatesのような）

Demo

通信の実装コスト

・ほぼ仕様に依存する ・仕様＝だいたいの場合サーバー側が決める !

実装コストを減らすには？

大原則：やることを減らす

サーバーに処理を任せる

どちらでも行える処理であれば サーバー側でやってしまった方が 実装コストが低く修正も簡単になる

API

共通化・RESTなどにとらわれない。

個々の（iOS, Android別）クライアントの各画面の都合、

ライブラリ（Mantle, JSONModel) の都合に合わせたjsonファイルを返してもらうこと

State

・ダウンロード可能なアセットを持たない ・クライアント側でCacheを持たない（画像除く） ・クライアント側でローカルストアを利用しない。毎回サーバーから取得する

例

右のような画面 ・お知らせ ・投稿&コメント

1RWLƓFDWLRQ

Post

&RPPHQW

Post

&RPPHQW

例 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)

例 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を統合

例 API仕様 v3

・api.hoge.com/ios/timeline_top.json

・api.hoge.com/ios/timeline_more.json

!

localeをサーバーで処理するように。

各JSONのResponseがあらかじめlocale適用済みに

サーバー側仕様変更で問題になるもの・綺麗な RESTful API のサーバー ・レガシーサーバー

綺麗な RESTful API サーバー

・汎用的なAPIであることを理由に特定画面に特化したAPIを断られることが多い

・原理主義的だとbatch requestの実装すら断られることがある

レガシーサーバー

・触るのが怖い ・同じような処理をする新APIを実装した場合に、実装で共通部を抽出するなどでリファクタリングしようとするとデグレそうで怖い

サーバー側をどう説得するか

・パフォーマンスの向上などメリットを説明 ・クライアントの大変さを訴える ・サーバー側も一部自分で書く

メリットを説明

先ほどの例だと ・リクエスト数4→1となり表示が高速に ・アセット読み込みがなくなるため起動が高速化。離脱率下がる など

サーバー側も一部自分で書く

・特にサーバー側エンジニア忙しくて手が回っていない場合に有効 ・強いマインドを持つことが大事

それでもだめなら……

中継サーバーをたてましょう

Client Proxyfor Client

REST Server

Legacy Server

Private Network

Client 開発者が書くPHPとかで

まとめ

・UIまわりの実装はだいぶ楽になった ・通信周りはプロトコルをどう定義するかで工数がグッと変わる ・サーバーサイドとの協力関係が大切