ロケタッチのつくりかた 第7回 プログラマー(iPhoneアプリ)編

こんにちは、ロケタッチでiPhoneアプリ開発を担当している gaooh です。ライブドアといえばPerlが有名ですが、個人的に得意なのはJavaとRubyです。最近はスマートフォンアプリの開発ばかりやっています!

RD6W0191

とにかく動くものをつくる



実際のアプリ開発は、ディレクター1名、デザイナー1名、API担当エンジニア1名、アプリ担当エンジニア1名という構成で行いました。

アプリの提供は当初から想定しており、私自身もかなり早いタイミングでアサインはされていました。とはいえ、スマートフォン用Webアプリが開発が進んでおり、そこがきちんと落ち着かなければ、iPhoneアプリ用のAPIの整備ができないという都合もありました。

ところがスマートフォン用Webアプリリリース後、想定以上に要望が高かっためリリースを急ぎたいということになりました。

当然ですが、APIの整備が終わらなければ機能の作り込みはできなません。これがWebアプリなら待つしかない部分が多いのですが、iPhoneアプリは違います。

iPhoneアプリは機能以上にUIの作り込みに手間がかかります。ただし「どんなUIが使い勝手がよいか」や「どうしたらスムーズな表現ができるか」は実際にコードを組んで、実機で動かさないとわからないことが多いです。なので、APIの整備がされるまでの期間はとにかく画面が動き、使い勝手が想像できるプロトタイプを作ることに集中しました。

もちろんその後改善されて、当初のイメージとは大きく変わった面もたくさんありますが、これにより全体のイメージを最初に固めて、メンバーと共有することができ、必要なAPIの洗い出しもスムーズに行えました。

なので、ロケタッチのiPhoneアプリにはパワポで作るような一般的な「画面遷移書」は存在しません。遷移書の有無は関わるメンバー数などにもよるでしょうが、やはりとにかく動くものをつくってみるというのはiPhoneアプリ開発では重要だと思います。


UIWebViewの活用



ロケタッチのiPhoneアプリではいくつかUIWebViewを活用しています。
UIWebViewを使う1番の利点としては「変更がダイレクトに反映される」ということです。

アプリだと審査の期間もあるため、変更しても反映までに時間がかかってしまいます。またサービス側の都合で仕様をかえる際にもそれがネックになってしまうということにもなりかねません。

また「マップ」画面に関してはUIWebViewの方が柔軟な表現ができるため、あえてアプリ標準のMKMapViewなどは使っていません。例えばロケタッチのマップは時間帯によって色がかわりますし、「地図を作っていく感覚」を重要視しているので、あえて細かい地名情報などを表示していません。これを通常のMKMapViewで実現することは難しかったりします。

png

↑UIWebViewを利用した地図の表示。時間によってベースの色がかわります。

png

↑MKMapViewを利用した地図表示。目的地の場所詳細を示すという目的だとこちらの方がわかりやすいです。


もちろん利用しすぎるとアプリの使い勝手を損ねてしまうのでバランスは大事ですが、iPhoneアプリの開発をスピーディーに行うためには重要なファクターになります。

「遅い」「重い」と思わせない工夫



やはりユーザがアプリを使っていて一番最初に使う気がうせてしまうのは「重い」ときや「遅い」ときでしょう。といっても原因はいくつかあります。

1. 通信が遅い

2. メモリ不足などで本体自体が重い

3. アプリ自体の処理速度が遅い

3に関しては当然アプリ側で改善すべき点なのですが、1に関しての根本解決はアプリ自体では難しいです。もちろんキャッシュなどを用いて、呼び出し回数を最低限にすることで、アプリ側で軽減することはできます。

ただほんのちょっとのことでユーザのストレスを減らすこともできます。

例えば表示するごとにデータを取得するような場合、データの取得を画面遷移前にするのと後にするのとでは体感が全く異なります。

// 画面遷移前
-(void) viewWillApper:(BOOL) animated {
}
// 画面遷移後
-(void) viewDidApper:(BOOL) animated {
}


コード上の違いはviewWillApper に書くか、viewDidApperに書くかだけなのですが、画面遷移前に取得処理を行うと当然ながら取得処理が終わるまで画面遷移がされません。こうなるとユーザは通信が遅いとは思わず「アプリが重い」と感じます。もしくはタップが反応していないと感じ、何度もタップして余計にイライラを増加させてしまいます。ところが、画面遷移後で処理を行うと画面は遷移するのでユーザは「アプリが重い」とは感じませんし、正常な値が表示されるまで
の時間は同じなのに、待たされている感覚が変わります。

その他にも画面遷移後にデータを取得する場合、きちんとindicatorを表示したり、押されては困るボタンをdisableにしておくなど、細かい工夫の積み重ねを繰り返すことで、iPhoneアプリでのさくさく感のあるUIを実現することができます。

こうしたことは、開発経験があっても実際に実機で動かしてみないと気がつかないことが多く、とりあえず機能ができあがってからの作り込みがとても重要です。

さいごに



なんて偉そうに語ってしまいましたが、1.0.0のリリースは少しでも早く提供したいということもあり、細かいところでできていないところがいくつかあったり、UI的にも使い勝手が悪いといわれるようなところは多々あり、精進の日々です。
今後ユーザの要望などを聞きながら、よりよいものを少しでも早く提供できるようにがんばっていきますので、よろしくお願いします。

ライブドアではiPhone/Androidのアプリ開発者も募集しています。どうぞこちらからご応募ください。

第1回 プロデューサー編 (佐々木)
第2回 ディレクター編 (荒井)
第3回 デザイナー編 (小黒)
第4回 プログラマー編 (吉川)
第5回 マークアップエンジニア編 (浜)
第6回 プログラマー(ケータイ版)編 (平野)
第7回 プログラマー(iPhoneアプリ)編 (浅見) ※本記事

ロケタッチの<br>
新規登録はこちら