今回は私がこの1ヶ月間で感じたAndroidアプリ開発のポイントについて、サーバサイドJavaやWebフロントエンドの開発と比較して書こうと思います。
Androidアプリの開発において、サーバサイドJava等の開発には見れらない特有の要素として以下が挙げられます。
スマホアプリは通常複数の画面で構成され、ユーザの操作により画面間を行き来します。Androidアプリではアプリそのものに対応するApplicationクラスと、各画面に対応するActivityクラスが用意されており、Android用の標準ライブラリがこれらのオブジェクトのライフサイクルを管理しています。
Activityのライフサイクルは下記の図で表されます。アプリ開発者は図で示された状態変化イベントに伴って呼び出されるメソッドの中身を実装する事でアプリの挙動を制御する事になります。
これはAndroidに特有というよりは、スマホアプリに特有の要素となりますが、スマホはカメラやセンサーなどの様々なデバイスを搭載しているため、それらにアクセスするための専用のAPIが用意されています。また、プッシュ通知やアプリ間通信などの外部連携に対応するための機構も用意されています。
前項とは逆に、類似しているものの多少異なる要素として以下が挙げられます。
AndroidアプリのUI実装にはいくつかのパターンがありますが、標準的な手法としてはXMLによるビュー定義を利用します。JSPやHTMLと似た形式です。レイアウトや外観の細かい指定もHTMLのスタイルシート指定に似た形で行う事ができます。
Javaソースからの制御や書き換えも可能で、JavaやJavaScriptでDOMを扱うように利用する事ができます。ただ、Modelを使ったデータバインドやjQueryのような抽出や一括操作などのAPIは用意されていないため、ライブラリ等を利用しない標準実装ではUI周りの実装が煩雑になりがちです。
AndroidアプリもJavaで実装されているため、マルチスレッドで動作させる事が可能です。画面描画や操作に影響を与えずにバックグラウンドで処理を行いたい場合等に有用となります。
ただし、通常のJavaマルチスレッドプログラムと異なり、メインスレッドが明確に区別され、UIを操作できるのはメインスレッドに限られるという制約があります。バッググラウンドのスレッドからUI操作ができないという点はHTML5のWeb Workersと同じですね。
Webフロントエンドの開発を行っている方であれば経験があるかと思いますが、プラットフォームが複数存在する場合には互換性問題が生じます。Androidには端末やOSのバージョンが多数存在します。そして、端末側の問題によりOSのバージョンアップができないといったケースも多々あるため、サポートしなければならない端末とOSの組み合わせが多数存在する事になります。
Androidアプリの開発を行う場合はこれらの互換性を考慮した実装やテストが必要となります。加えて、端末のサイズも統一されていないため、様々な画面サイズを考慮したレイアウト設計も必要となります。
Androidアプリ開発について、JavaやJavaScript等で開発を行ってきた方が把握しておくと良いポイントをまとめてみました。今回はAndroid用Javaそのものの機能を中心に整理してみましたが、これらを踏まえた上でアプリの内部構造をどう組み立てていくかという所にもまた様々なポイントがあります。その辺りはまた別途整理してみたいと思います。
]]>ついに我が社もエンジニアブログを始めることになりました。先日サービスをリニューアルしたので、第1回目はその時に意識したSPA開発について書こうと思います。
A single-page application (SPA), is a web application or web site that fits on a single web page with the goal of providing a more fluid user experience akin to a desktop application.
- Single-page application From Wikipedia, the free encyclopedia
デスクトップアプリケーションのような流動的なUXを提供するウェブサイトやウェブアプリケーション。
ちょっと昔に隆盛を極めたJavaアプレットやFlashプラグインもSPAの仲間で、それがJavaScriptの成熟により注目されるようになってきた・・・というのが一連の流れのようです。(JavaScriptにはインストール不要などのメリットがあります)
Single Page Web Applications JavaScript end-to-end では、SPAの特徴として下記のユーザメリットが挙げられています。
デスクトップアプリケーションと従来のウェブサイトのいいとこ取りというわけですね。Ajaxを使ったサイトを構築したことのある方は多いと思いますが、実際のイメージはRESTfulなAPIをがっつり使ったサイトという感じです。
How API-First Development Boosts Productivity
trippieceの開発では、PHPのフレームワークCodeIgniterを利用していました。長年お世話になったフレームワークではあるのですが、既にマルチプラットフォームに展開していたこともあり、サーバサイドの同じ処理をそれぞれのプラットフォームのために書かなくてはならなかったり、プラットフォーム毎に仕様に微妙な差異が生まれたり、余計な工数が生まれたりといった弊害が発生していました。
また、ユーザ増加に伴いとあるページの読み込みが重い・・などユーザエクスペリエンス面での問題もあり、APIの下地もできていたので、今回のリニューアルはAngularJSを採用してSPA化を目指していくこととしました。
開発においてはプラットフォーム間の障壁をなくすこと、開発リソースの集中と高速化を特に意識していました。SPAを構築してみた雑感は下記の通りです。
サービスの設計ではAPIファーストを意識し、APIありきで考えることがあたり前になりました。モバイルアプリからウェブへ落とし込む際にも実装上の無理がでないような設計が自然にされるようになったと思います。
非同期のAPIを利用することでページとパーツに依存関係がなくなり、再利用したり変更に強くすることができました。また、BEM風なスタイルガイドを導入したのでデザイン側の作業とコンフリクトすることも少なくなり、妙なストレスから解放された感があります。
サーバサイドの仕様が全プラットフォームに関わるので、自ずとWEB/iOS/Android間の違いが仕様に吸収されるようになりました。特にバリデーションなど細かい部分での面倒くささが減ったのは良かったです。
ページをレンダリングする際に毎回全体を読み込む必要が無くなり、ページの読み込み速度が向上しました。当初の課題だったページについても格段に改善され、10倍以上のパフォーマンスがでました。
クライアントとサーバがクッキリ分かれるので、開発リソースをそれぞれに集中して割り当てることが容易になりました。また、これはAngularJSを採用した効果でもあるのですが、サイトのコード量は格段に減りました。
これもクライアント側とサーバ側が別れたことによるメリットなんですが、テストも役割がはっきりとして書きやすくなりました。
これは通常見過ごしてしまうことをせざるを得なくなった・・・という意味で良かったことなのですが、結果的にはクローラに正しい情報を伝えることができるようになってきたのでプラスかなというところです。
AJAX クロール: ウェブマスターおよびデベロッパー向けガイド - ウェブマスター ツール ヘルプ
実装はprerenderを使ってクローラにHTMLスナップショットを返すようにしました。この辺りの話はまた別の記事で紹介しようと思います。
SPAについて紹介してみましたがいかがでしたでしょうか。今回は技術的な負債を無くし、開発しやすくすることを目指しましたが、界隈にはYeomanのプロジェクトなんかもあり新しいアプリケーションがサクサクつくれるのも面白いですね。大した手間も掛からないので、もし興味をもった方がいましたら是非一度触ってみることをオススメします。
採用情報はコチラ。
新しい旅行体験をつくるエンジニアWANTED!! - trippiece<トリッピース>の求人 - Wantedly
個人的には「ユーザとの距離が近いサービスである」ということがとても気に入っています。
この間も一緒に海外旅行にいったユーザとラーメン巡りをしてきたのですがめちゃくちゃ美味かったのでその写真を貼って締めたいと思います。ではまた。
四つ葉 ラーメン
]]>