【連載】iOS/Androidアプリ開発入門「サーバ連動アプリを開発しよう！」 (3) API実装
2015/03/12
みなさん、こんにちは！
第2回「(2) 画面設計・データベース設計・API設計」の続編です。
前回同様、本格的なアプリを開発するためには「何を知っておかなければならないか」「何を勉強すればいいか」を中心に書いていきたいと思います。
今回はAPIの実装を進めます。
早速はじめていきましょう。
MVCを意識して開発する
本格的なアプリを開発するには、サーバ側もクライアント側（アプリ側）もMVCを意識して開発することが大切です。
MVCとは、「モデル(M)」「ビュー(V)」「コントローラー(C)」の略語で、開発思想の一つです。
MVCという概念は、入門者にはわかりにくいと思いますので、以下のようにわかりやすく整理しておきます。
サーバ側のMVC
| 説明 | 実装のコツ | |
|---|---|---|
| モデル(M) | データベースとやりとりする部分。また、データを加工する部分。 | 基本的にプログラムはここに書いていく。 |
| ビュー(V) | HTMLまたはJSONを出力する部分。また、そのためのテンプレート。 | HTMLとJSONの生成・整形だけを行う。 |
| コントローラー(C) | モデルからデータをもらってビューに貼り付ける部分。 | 基本的にプログラムはここに書かない。 |
クライアント側（アプリ側）のMVC
| 説明 | 実装のコツ | |
|---|---|---|
| モデル(M) | オブジェクト。プロパティとメソッドからなる。 | 基本的にプログラムはここに書いていく。 |
| ビュー(V) | Storyboard（iOS）またはXMLのレイアウトファイル（Android）。 | 画面の見た目、操作性をここで定義する。 |
| コントローラー(C) | UIViewController（iOS）またはActivityとFragment（Android）。 | 基本的にプログラムはここに書かない。 |
軽いコントローラーを目指す
ポイントは、コントローラー(C)になるべくプログラムを書かないことです。
初心者は、コントローラーにプログラムをどんどん書いてしまいます。
これはあまりよくない習慣です。
サッカーに例えるなら、司令塔役の10番がゴールキーパーからストライカーまでの全部の業務を担おうとするようなもので、いずれ無理が出てきます。
具体的には、コントローラーにプログラムを書いてしまうと、開発時にテストがしづらいだけでなく、1つのアプリ内でプログラムのコピペが増えるため、保守効率が大きく下がります。
いわゆるスパゲッティプログラムになってしまうということです。
DRYなコードを書く
このため、コントローラではなく、モデル(M)にプログラムを書いていくのがコツとなります。
モデルにプログラムを書くことで、データと処理を一箇所にまとめることができ、カプセル化が進んで、DRYなコードが書けるようになります。
カプセル化およびDRY(Don’t repeat yourself)というのも著名な開発思想の一つで、要するに1つのアプリ内でプログラムのコピペを乱用しないということです。
司令塔であるコントローラーは、ボールを持たず（データを保持せず）、パス（データの受け渡し）に集中させるようにします。
サーバ側APIを実装する
サーバの主な役割はJSONの出力
さて、サーバ側APIを実装していきましょう。
本格的なアプリにおけるサーバの主な役割をざっくりと言えば、JSONを出力することとなります。
そのほかに、ジョブとメッセージングという大きな役割もありますが、連載の後の方で触れることにします。
PHPにはJSONを扱う便利な関数（json_encode(), json_decode()）がありますので、それを使います。
CakePHPを使う場合、JSONビューまたは独自ビューを使ってJSONを出力します。
実装
Cakebookにサンプルプログラムがありますので、それを参考に実装します。
前回、RESTなAPIを設計しましたので、実装は簡単なはずです。
一例として、コントローラーは以下のようになりました（主要部分のみ）。
class PostsController extends AppController {
public function index() {
$posts = $this->Post->viewAll(); ・・・(1)
$this->sendJson(200, $posts); ・・・(2)
}
public function add() {
$result = $this->Post->add($this->request->data); ・・・(3)
if ($result) {
$this->sendJson(200, $result); ・・・(4)
} else {
$this->sendJson(500, null, $this->Post->errorMessage()); ・・・(5)
}
}
}
ポイントは以下のとおりです。
(1) データを取得する処理は、モデルにまかせる。
(2) データを出力する処理は、ビューにまかせる（sendJson()は独自に作成した関数）。
(3) データを追加する処理は、モデルにまかせる。
(4) データを出力する処理は、ビューにまかせる。
(5) エラーメッセージの出力も、ビューにまかせる。
あとは、モデルとビューを実装すればサーバ側APIの完成です。
ここではサンプルを例示しませんので、自分で考えてみてください。
クライアント側APIを実装する
アプリの主な役割はJSONの取得と画面表示
アプリの主な役割をざっくりといえば、JSONを取得して画面に表示することになります。
iOSの場合AFNetworkingライブラリを使って、Androidの場合Retrofitライブラリを使って、サーバからJSONデータを簡単に取得できます。
AFNetworkingの場合、サーバから取得したJSONデータは、自動的にNSDictionary型に変換されて楽に扱えるようになります。
Retrofitの場合、サーバから取得したJSONデータは、自分で定義したクラスに変換されて楽に扱えるようになります。
Retrofitのページにサンプルプログラムがありますので、それを参考に実装します。
一例として、Retrofitでは以下のようになりました（主要部分のみ抜粋）。
public interface MyAppAPI { ・・・(1)
@GET("/posts")
List<Post> viewPosts();
@POST("/posts")
void addPost(@Body Post post, Callback<Post> callback);
}
RestAdapter restAdapter = new RestAdapter.Builder() ・・・(2)
.setEndpoint("http://localhost")
.build();
MyAppAPI api = restAdapter.create(MyAppAPI.class);
List<Post> posts = api.viewPosts(); ・・・(3)
Post aPost = new Post("hoge"); ・・・(4)
api.addPost(aPost, callback);
ポイントは以下のとおりです。
(1) Retrofitのルールに従い、APIのインターフェイスを定義します。
(2) Retrofitのルールに従い、通信クラスを生成します。
(3) APIを呼び出し、最新の投稿一覧をPostクラスのListに格納します。
(4) APIを呼び出し、新しい投稿をサーバに送信します。
Retrofitライブラリを使うことで、サーバとの通信処理が数行の実装で済むようになります。
また、前提知識がなくとも、読むだけで何をやっているのかわかるプログラムが書けるようになります。
これが外部ライブラリを導入した効果です。
第3回のまとめ
設計が終わったら、まず手始めにAPIを実装しましょう。
- コントローラーになるべくプログラムを書かない
- サーバの主な役割はJSONを出力すること
- アプリの主な役割はJSONを取得して画面に表示すること
- フレームワークや外部ライブラリの機能を活用して素早くAPIを実装する
本日は以上です。
連載目次
iOS/Androidアプリ開発入門「サーバ連動アプリを開発しよう！」
(10) 開発の旅をうまく乗り切る（最終回）
(9) バックグラウンドでメール送信
(8) サーバの監視とデータのバックアップ
(7) リモートサーバ（本番環境）の構築
(6) ローカルでの単体・結合テスト
(5) コントローラーとビューの実装
(4) モデル実装
(3) API実装
(2) 画面設計・データベース設計・API設計
(1) 開発環境の構築