「iOSと同じで」と言われたら? Android版アプリ開発コストの抑え方【前編】

iOSとAndroidを両開発する場合に、iOSデザインを先行して考えてから、それをベースにしてAndroidに落とし込むというパターンがよくあります。その際、デザインコストを抑えるため、「iOS版のデザインを考えたので、Android版はそれと同じようにしてください」というように、半ば投げやりなまま開発がスタートするケースもあると思います。

しかし、iOSのデザインをそのまま踏襲するということは、Androidの標準にないものはすべて独自で実装しなければならないため、必然的に開発コストが大きくなってしまうということになります。

さらに、無理やりほかのプラットフォームのデザインを持ち込んだことで、Androidのデザインガイドラインから大きく外れてしまった場合は、普段使い慣れないものをユーザーに押し付けることになってしまい、最終的にはユーザーへの負担を増やす結果になってしまいます。

本記事では、そういった問題が少なくなるように、Android開発において筆者が普段気をつけている点を前編・後編に分けて紹介していきます。

気をつける点 その1:標準コンポーネントを使う

Android開発においては、「ダイアログをカスタマイズしたい」など、アプリごとにいろいろなこだわりがあると思います。もちろんカスタマイズするだけの時間と工数をかけられるのならば、それもアリでしょう。

ただ、時間もお金も潤沢にある、という場合はなかなかないものです。開発コストを抑えるための第一歩は、当たり前のことですが、Androidで標準的に用意されているコンポーネントを使用していくことです。

その際、デザインが降りてきたときに事前に確認すべきポイントをいくつか紹介します。

スイッチなどのコンポーネント

iOS版の標準スイッチは以下の図のようになっていて、設定画面などに使われることが多いです。

スイッチ機能を独自で実装するとなるとかなり大変なので、この辺りはAndroid標準で実装するようにして、無駄な工数を削減していくとよいでしょう(下記例はHoloテーマの場合)。

また、AppCompat v21から、Lolipopより前のデバイスでも使用できるマテリアルデザインのコンポーネントが追加されたので、今後はこちらが主流になってくると思います。

ユーザーへ選択を求めるとき

たとえば、送られてきたメールに対するアクションを、返信・転送から選んだり、シェアする先を、メール・Twitter・Facebookから選んだりなど、複数のアクションが紐づく場合、iOSではアクションシートで対応することがよくあります。

Androidで複数のアクションを選ぶ場合は、コンテキストメニューやオプションメニュー、ポップアップメニューなどが標準で用意されているので、まずはそちらでデザインを組めるかどうかを検討するほうがよいでしょう。

気をつける点 その2:Intentを使う

Androidの特徴的な機能としてIntentがあります。よく使うものとしては、カメラ・ギャラリー・ブラウザ・メールなどが挙げられるでしょうか。

できるだけほかのアプリでできることはほかのアプリに任せることで、アプリ自体がシンプルになります。アプリがシンプルになると、メイン機能を伝えやすくなり、コストも削減できるというメリットがあります。

今回は、これまでの筆者の経験をふまえて、Intentに関して注意しておいたほうがよさそうな例を紹介します。

ブラウザかWebViewか

利用規約やプライバシーポリシーなどは、変更などに迅速に対応できるように、アプリ内の埋め込みではなく外部リンクになっていることがよくあります。アプリ埋め込み型だと、規約の変更があった場合、アプリをアップデートする必要があったり、古い規約を参照されたりなどの問題があるからです。

そんなときによく迷うのが、WebViewで表示するのか、ブラウザにIntentを投げるのかというところだと思います。

筆者の場合、仕様が決まっていないときはブラウザにIntentを投げる方法を採用しています。その理由は、ブラウザには下記の機能があるからです。

• URLを表示する
• 戻る、進む、更新などのアクション

まずURLの表示についてですが、URLと証明書を表示することで、ユーザー側で正規のリンクかどうかをある程度判断することができます。

続いて「戻る・進む・更新」などのアクションについてです。シンプルな1ページの画面であればよいのですが、「実は規約画面にお問い合わせフォームがあったから、戻るボタンが欲しい」とか「メールを起動したい」などといった要望が後から出てくるというケースは本当によくあります。

基本的な機能がそろっているブラウザに飛ばしていれば、後から出てきた要望にもある程度対応してくれているので便利です。なので、仕様が決まっていないときなどは、ひとまずブラウザで対処するほうがよいと思います。最終的に「やっぱりアプリ内に表示したい」となった場合でも、その段階になれば大体仕様が決まっていると思うので、曖昧なまま実装するよりは、楽に実装できるのではないでしょうか。

シェア機能

メールやTwitter、Facebookなどでユーザーにシェアしてもらえるように、シェア機能などをつけることがよくあります。

基本的にはIntentのアクションに ACTION_SEND を設定してtextを送る、という方法が一番簡単です。

ただ、端末に多くのアプリをインストールしているユーザーでは、大量の選択肢が出ることがあるので、メール・LINE・Twitterなどのアイコンを配置して、事前にある程度選択肢を狭めておきたいという要望が多くありました。そのなかでちょっとしたハマりポイントがあったので、ここで紹介したいと思います。

まずは、SMS(メッセージ)やメールでのシェアですが、これはIntentの規格が決まっているので、対応するアプリに暗黙的インテントを投げるだけで特に問題なく実装できます。

続いて、LINEなどのメッセージ系アプリにシェアを行う場合ですが、これは特に規格がないので、明示的インテントでパッケージ名を指定することで、ひとまず対応ができると思います。

最後に問題になったのはTwitterでした。Twitterは特に規格が決まっていないのでLINEと同様に公式アプリのパッケージ名で明示的インテントを投げる想定でしたが、ここが問題でした。なぜなら、Twitterにはさらにサードパーティー製のクライアントアプリも存在しているからです。Twitter公式アプリの代わりにクライアントアプリを使用しているユーザーも多くいるので、公式アプリに限定してしまうと、クライアントアプリのユーザーを弾くことになります。

もともと見積もりや企画段階では、シェア機能についてはほとんどコストをかけない予定だったのに、最終的にはSDKを導入しアプリ内からツイートできるように実装することになり予想外のコストがかかってしまった、ということになりかねないので、このあたりは注意しておきたいところです。

いかがでしたでしょうか。iOSとAndroidの両開発におけるコスト削減方法として前編では、各プラットフォームの標準コンポーネントの理解を深め、Intentの注意点を紹介させていただきました。

後半では、レイアウト構成の注意点や、スタイルの利用などを重点的に解説していきたいと思います。

執筆者紹介 橋本早樹(HASHIMOTO Saki) クラスメソッド株式会社　iPhoneアプリサービス事業部所属 元々はオンプレミスでのネットワーク・インフラ開発を行っていたが、近年のスマートフォン市場拡大に興味を持ち始め、半年ほどAndroid開発学校で開発手法を学習したのち、2014年から現職のAndroidアプリケーションエンジニアに転換。現在は、主に社内でのAndroidアプリの開発を担当。