Androidアプリ「アプリ間共有の助け Ver.1.3」公開
Androidアプリ「アプリ間共有の助け」公開
このほど、自作Androidアプリ「アプリ間共有の助け」というアプリを公開させていただきました。Androidにおけるアプリ間のデータ共有を少しだけ便利にするアプリです。よろしければ、お使いください！
はじめに
みなさん、Android端末のスマホを使っていると、ちょっとだけ使いにくいな～と思うような機能の1つや2つありますよね？ 私は、各アプリの共有メニューを選択し、共有先のアプリを選択するダイアログが出たときに、ちょっとだけ使いにくいな～と、いつも思っていました。ダイアログでは、沢山のアプリが綺麗に並んでいるのですが、私が選択したいアプリは、ずいぶんと下の方にあったりするのです。毎回、スクロールさせるのが煩わしいのです。
そして、Google Playを探すと、共有メニューをカスタマイズできるアプリがいくつもあることを知り、使ってみました。ですが、カスタマイズする手間が煩わしかったりして、自分にはしっくりきませんでした。
であれば、作ってしまえ！ ということで今回のアプリを作成しました。（そんなわけなので、かなり自分勝手なアプリですね。）
主な特徴
共有先アプリの選択時に、よく使用するアプリを先頭に表示します。（Android標準機能では、使用頻度を考慮してくれません。）
特定の共有先アプリを「標準」として設定することで、選択画面をスキップして、共有先アプリを起動します。標準設定は、共有元アプリ、共有の種類ごとに設定可能です。（Android標準機能では、共有元によらず、共有の種類のみでしか設定できません。）
標準設定した共有先アプリを解除するのも簡単です。
詳細＆ダウンロードは、こちらです。
プログラム
このアプリですが、プログラムをGitHubで公開しています。よろしければ、ご覧下さい。
AndroidでOAuth認証をしたい
タイトルのまんまなのですが、Androidで、OAuth2.0認証をしたくなったので、調べてみました。なかなか理解できませんでしたが、何とか実装することができました。自分が理解したことをまとめてみたいと思います。
なお、私は、WebアプリケーションでOAuth1.0認証を行った経験はありましたので、OAuthの概要については、理解しているつもりでした。
難しかったところ
簡単に沢山の情報が見つかり、それぞれ分かりやすく具体的に書かれていましたが、どれも実装方法が異なり、どの実装方法を参考にすれば良いか、わかりませんでした。
実装方法が異なるのは、アプリケーションの形態や、ユーザーへの見せ方、使用ライブラリなどが異なるためでした。
実装パターン一覧
調べてみた実装方法について、自分なりに解釈した内容を表にまとめてみました。今回は、Androidアプリの実装方法に注目していますが、比較のため、Webアプリケーションとコンソールアプリケーションも記述しています。私がざっと調べて見つけた実装方法のみ記述していますので、探せば他にも色々あると思います。
| パターン番号 | アプリケーション形態 | 接続先 | 認証画面UI | ライブラリ | ユーザ操作 |
| 1 | Androidアプリ | 各Webサービス（コールバック） | WebView | 未使用 or 各種ライブラリ | ID・パスワード入力 |
| 2 | 〃 | 〃 | ブラウザアプリ | 〃 | 〃 |
| 3 | 〃 | 各Webサービス（OOB） | ブラウザアプリ | 〃 | ID・パスワード入力。PINのコピー＆ペースト。 |
| 4 | 〃 | Googleサービス | ブラウザアプリ | Google APIs Client Library for Java ※1,2 | ID選択。パスワード不要。 |
| 5 | 〃 | Googleサービスのみ？ | Android OS | Android SDK (AccountManager) | ID選択。パスワード不要。 |
| 6 | Webアプリケーション | 各Webサービス（コールバック） | ブラウザ | 未使用 or 各種ライブラリ ※2 | ID・パスワード入力 |
| 7 | コンソールアプリケーション | 各Webサービス（OOB） | ブラウザ | 〃 | ID・パスワード入力。PINのコピー＆ペースト |
※1 「Google APIs Client Library for Java」と同様のライブラリとして「Google Data Java Client Library（gdata-java-client）」というものもありました。「Google Data Java Client Library（gdata-java-client）」は、2012年3月頃で開発が止まっているようで、「Google APIs Client Library for Java」の前世代のライブラリのようでした。
※2 「Google APIs Client Library for Java」は、Androidアプリでも、Webアプリケーションでも使えます。たぶん、コンソールアプリケーションでも使えると思います。使う場合は、Androidアプリの場合、GoogleAccountCredentialクラス、GoogleAuthUtilクラスを使います（GoogleAccountCredentialクラスは内部でGoogleAuthUtilクラスを使用）。Webアプリケーションの場合、GoogleAuthorizationCodeFlowクラスを使います。
Androidアプリにおける実装パターン１～５について、画面イメージは次のようになります。
実装パターン１
アプリケーション形態：Androidアプリ
接続先：各Webサービス（コールバック）
認証画面UI：WebView
ライブラリ：未使用、各種ライブラリ使用のいずれでも実装可能
ユーザ操作：ID・パスワード入力
自作アプリです。OAuth認証を行うきっかけを用意しておきます。ここでは、開始ボタンを用意しました。
自作アプリの内部に、WebViewを使用して、各Webサービスの認証画面を表示します。ここでは、Twitterの認証画面を表示しています。認証画面を表示する時には、コールバックURLを設定します。コールバックURLは、認証完了後に呼ばれるURLで、自作アプリ用のURLを設定しておきます。ユーザは、アカウントのIDとパスワードを入力し、アクセス権限を確認します。
認証後、自作アプリから、各Webサービスの情報にアクセスできるようになります。ここでは、アカウント情報を取得し、画面表示してみました。
この実装パターンは、Androidアプリでもよく見かける気がしますし、Webアプリケーションにおいても同じ流れになりますので、ユーザーにとっては、慣れている操作手順かもかもしれません。
ただし、セキュリティ的な危険性を指摘するブログなどを見かけました。悪意ある開発者であれば、自作アプリ内のブラウザで入力されたアカウントのIDとパスワードを盗み取ってしまえるらしいです。ですが、個人的には、自作アプリなり、開発チームや会社などが、ユーザから既に信頼を得られているのであれば、この方式でも概ね受け入れられている気がします。
実装パターン２
アプリケーション形態：Androidアプリ
接続先：各Webサービス（コールバック）
認証画面UI：ブラウザアプリ
ライブラリ：未使用、各種ライブラリ使用のいずれでも実装可能
ユーザ操作：ID・パスワード入力
基本的には、実装パターン１と同じですが、WebViewの替わりに、Android端末内にインストールされているブラウザアプリを呼び出す方式です。
自作アプリです。開始ボタンをタップするとブラウザアプリを起動します。
端末内に複数のブラウザアプリがインストールされ、デフォルトが決められていない場合、ブラウザアプリを選択するダイアログが出ます。認証完了後に自作アプリが呼ばれるように実装しておきます。
認証後、各Webサービスの情報にアクセスできます。
この実装パターンは、WebViewを使った時と比べて、セキュリティ面が改善されています。ブラウザアプリに入力されたアカウントのIDとパスワードを盗み取ることが困難なためです。
実装パターン３
アプリケーション形態：Androidアプリ
接続先：各Webサービス（OOB）
認証画面UI：ブラウザアプリ
ライブラリ：未使用、各種ライブラリ使用のいずれでも実装可能
ユーザ操作：ID・パスワード入力と、PINのコピー＆ペースト
実装パターン２と比較して、各Webサービスの画面から、自作アプリへの戻り方が異なります。
自作アプリです。ここでは、連携確認ボタンをタップするとブラウザが起動するようにしました。
各Webサービスで認証後、PINと呼ばれるコードが払い出されます。ユーザにPINをコピーしてもらい、自作アプリへ戻ってもらいます。
自作アプリに先ほどのPINを貼り付けてもらいます。このPINを使って、各Webサービスに接続し、情報にアクセスできるようになります。
PINを使うことで、各Webサービスと自作アプリの連携が少なくなりますので、セキュリティ面が安全になるようです。ただし、ユーザの操作性が悪くなるため、個人的にはあまり使いたくない実装パターンだと思います。
なお、ブラウザアプリの替わりに、WebViewを使用して実装することもできます。しかしながら、PINを使うことのセキュリティ面のメリットが失われてしまいますので、あまり意味がないと思います。
実装パターン４
アプリケーション形態：Androidアプリ
接続先：Googleサービス
認証画面UI：ブラウザアプリ
ライブラリ：Google APIs Client Library for Java 使用
ユーザ操作：ID選択。パスワード不要。
実装パターン４は、今まで説明した実装パターンとは、だいぶ異なります。
この実装パターンが使えるのは、Android端末で、Googleアカウントのみです。
自作アプリです。
まず、認証に使用するGoogleアカウントを決定します。ここでは、Android SDKのAccountManagerを使用し、Androidの機能を呼び出して、端末に登録されているGoogleアカウントから、今回使用するアカウントを選択してもらいました。新規にGoogleアカウントを端末に追加して、使用することもできるようです。Googleアカウントを選択するだけで、パスワードの入力は不要です。（なぜ、パスワードがいらないのだろう？あまり理解できていないです。）
認証後、Googleサービスの情報にアクセスできます。
この実装パターンでは、ユーザ操作がかなり簡単ですね。文字を入力することがなく、数回タップするだけです。
ただし、セキュリティ面はどうでしょう？端末を紛失して、悪意ある人に使われてしまうと、勝手に認証操作を行われてしまいそうです。とはいえ、端末を奪われた時点で、もっと大きな問題が発生するでしょうから、他者に操作される懸念は別の観点で考えたほうがよいのではないでしょうか。
実装パターン５
アプリケーション形態：Androidアプリ
接続先：Googleサービスのみ？
認証画面UI：Android OS
ライブラリ：Android SDKのAccountManager使用
ユーザ操作：ID選択。パスワード不要。
実装パターン５は、ユーザにとって、実装パターン４と似たように見えるかもしれませんが、実装は別物です。認証情報が管理される場所も異なります。実装パターン１～４では、各Webサービスのサーバ側で認証情報が管理され、各WebサービスがWeb上で提供しているアカウント管理画面から認証を解除することができました。しかし、実装パターン５では、Android端末側で管理されるようです。Web上のアカウント管理画面を見ても、自作アプリとアカウントが紐づいていることが分からない状態となっていました。どうしたら認証状態を確認できるのか、どうしたら解除できるのか、わかりませんでした。
自作アプリです。
AccountManagerが、必要に応じて、Account選択ダイアログを出したり、認証ダイアログを表示してくれます。Googleアカウントを選択するだけで、パスワードの入力は不要です。
認証後、Googleサービスの情報にアクセスできます。
この実装パターンでも、実装パターン４と同様に、ユーザ操作がかなり簡単ですね。文字を入力することがなく、数回タップするだけです。
セキュリティ面では、実装パターン４と同じ問題がありまそうです。Androidが進化を続けても、この実装パターンは、使い続けられるのでしょうか？よくわかりません。私の理解不足が多分にあるため、どう扱うべきか決めかねています。
まとめ
以上のように、AndroidアプリにおけるOAuth認証の実装方式は、すくなくとも5パターンありました。しかも、探せばもっと他の実装パターンもあるかもしれません。Webアプリケーションでは、概ね1パターンであったのと比べるとかなり違いますね。
説明した実装パターンについて、比較してみます。
| パターン番号 | 適用範囲 | 操作性 | セキュリティ |
| 1 | ○ | ○ | △ |
| 2 | ○ | ○ | ○ |
| 3 | ○ | △ | ◎ |
| 4 | △ | ◎ | ○ |
| 5 | △ | ◎ | ○ |
Googleサービスのみを使う場合は、実装パターン４で実装すると、使い勝手がよさそうです。実装パターン５も同様ですが、私があまり理解できていないので選択肢から外しています。Googleサービス以外のサービスを使う場合は、実装パターン２がよさそうです。
以上、ひとまず自分の理解をまとめてみました。もし、誤りなどありましたら、コメント頂けるとありがたいです。
動作確認
確認環境
確認用プログラム
参考ページ
ライブラリ
実装方法
- OAuth 2.0でWebサービスの利用方法はどう変わるか（1/3）- ＠IT
- 開発日誌 (7) : scribeでGoogle OAuth 2.0 (client_secretなしで認証) - 家族ToDo(仮)開発日誌
- OAuthの認証にWebViewを使うのはやめよう - Shogo's Blog
- AndroidからGoogle OAuthでプロフィール情報にアクセスする方法 - 今日の役に立たない一言 － Today’s Trifle! －
- Twitter4jを使ってOAuth認証をアプリ内で行う方法 - 素人のアンドロイドアプリ開発日記
- AndroidでのGoogle Account OAuth認証方法 - Qiita
- Android - Google APIs Client Library for JavaからGoogle Drive APIを使用する - Qiita
- 琴線探査: AndroidのAccountManager経由でGoogleのOAuth2認証を行うには？（外部ライブラリ完全非依存版）
変更履歴
2014/11/21 実装パターン５（AccountManager使用）を追加しました。
アプリポケット Ver.0.5.0公開
少し時間が経ってしまった話ですが、2012/10/28に、Android用ランチャーアプリ「アプリポケット」のVersion 0.5.0を公開しました。
今回の大きな変更点は、広告表示を廃止したことです。メイン画面以外で広告表示をしていて、個人的には何も疑問にも思わずに開発・使用していたのですが、Google Playへのコメントを見ると、数名の方が、広告表示を気にしていらっしゃいました。より多くの方にアプリを使って頂きたいので、今回、広告表示を廃止させて頂きました。
変更点概要
- 広告表示を廃止しました。
- アプリ起動情報ダイアログのレイアウトを改善しました。
- デフォルトテーマで透過設定をしている場合に、メイン画面を表示すると、タイトルバーが透明になっていました。タイトルバーは透過しないように修正しました。
- Android端末のアプリ詳細画面を表示する機能が、アプリ起動情報ダイアログ内に存在しましたが、少々わかりづらいようです。アプリアイコン長押しメニューに表示するように変更しました。
Denchin 0.2.7 公開
本日、バージョン0.2.7を公開しました。要望と不具合の対応です。
今回取り入れた要望は、Google Playのプロフィールで公開していたメールアドレスに、ご意見を頂いた内容です。メールで会話して、ユーザーの方が、Denchinをどのように使っているかお聞きする事ができ、とても興味深く感じました。
特に印象深かった話があります。私は、Denchinにおまけ的な扱いで追加したステータスバーへの残量表示機能を作成していました。ですが、会話したユーザーの方は、ステータスバー表示のみを使いたいと思い、ウィジェットは不要と考えていました。「おまけ」が「メイン機能」として使われていたんですね。
Denchin 0.2.6 公開
本日、バージョン0.2.6を公開しました。約半年ぶりのバージョンアップですね。そんな久しぶりのバージョンアップですが、何も華々しいことはありません。
今回の変更は、Google Playでコメント頂いていた、いくつかの不具合の修正です。
変更内容
１．メイン画面のオプションメニューから履歴クリア選択時に、エラー発生し、履歴を消せなかった問題を修正。
２．メイン画面における前回充電の充電量が100%にならない端末がある問題を修正。
３．ウィジェットの右と下の余白が、多少広かったのを微調整。
４．DB処理を見直し。
その他
Google Playのコメントにて、端末再起動時に、Denchinが自動起動しない問題が報告されています。私の手持ち端末では、現象が再現しないため、原因が特定出来ていません。
ネットの情報では、Android OS 4.0 (ICS)では、マニフェストファイルの設定（targetSdkVersion）が未設定だと、自動起動の権限が認識されないことがあるようです。DenchinでもtargetSdkVersionを設定していなかったので、今回のリリースでは、設定を行なってみました。
もし、原因を特定できるような情報をお持ちの方がいましたら、情報提供をお願いします。当ブログやGoogle Playへのコメントでも構いませんし、Google Playに公開してあるメールアドレスでも構いません。
アプリポケット Ver.0.4.2/0.4.3公開
Android用ランチャーアプリ「アプリポケット」のVersion 0.4.2/0.4.3を公開しました。
0.4.2は、バージョンアップユーザに対して不具合が発生しました。ご迷惑をお掛けし申し訳ありません。すぐに0.4.3を公開し現在では修正されています。
変更内容は下記です。
概要
次の機能を改善しました。Google Play ストアのコメント欄で頂いていたご要望になります。
- タグ管理画面にて、実行中アプリ、最近使用したアプリ、よく使用するアプリ、タグなし、も並び替え可能としました。
- メイン画面表示時のパフォーマンスアップに取り組みました。期待するほどの成果は出ていないかもしれませんが。。。
