web-dev-qa-db-ja.com

Android AccountManagerの使用目的

Android SDKでAccountManagerを見て、アカウント情報を保存するために使用されていることを確認しました。したがって、それが何を目的としているのかについての一般的な議論を見つけることができません。 AccountManagerの背後にある意図が何であり、何を購入するのか、これがどのタイプのアカウントに適しているのか、一般的なWebサービスのユーザーのアカウント情報を置く場所はどこでしょうか。

androidaccountmanager
147
Phil

この質問は少し古いですが、私はそれがまだ非常に興味深いと思います。

AccountManager、SyncAdapterおよびContentProvidergoを一緒に使用します。

でも君ならできる：

AccountManager/SyncAdapter/ContentProviderの場合：

  • AccountManagerは、ユーザーに資格情報を定義するための中心点（[設定]> [アカウント]）を提供します
  • Androidは、SyncAdapterを介して同期をいつ実行できるかを決定します。これは、バッテリーを最適化するのに適しています（たとえば、ネットワークがダウンしているときは同期されません）。
  • ContentProviderは、アプリケーション間でデータを共有する便利な方法です注： Android上のプロセス間通信の他の方法 があります。
  • ContentProviderは、バックグラウンドスレッドでデータベースアクセスをスケジュールします AsyncQueryHanlder は、バックグラウンドスレッドでContentProviderを照会するのに役立ち、明示的にスレッド化を処理する必要がなく、Application Not Responsive（ANR）エラーを防ぎます。
  • ContentProviderはContentResolverのオブザーバーに結び付けられます。これは、コンテンツが変更されたときにビューに簡単に通知できることを意味します。

一番下の行：フレームワークAccountManager/SyncAdapter/ContentProviderは、データを同期する場合に役立ちますWebリソースから。 Fake/ ダム実装 はAPI 7で必要です。また、

  • データのみを保存する場合は、 データストレージのよりシンプルなメカニズム を検討する必要があります。
  • リソースのみを取得する必要がある場合は、 AsyncTaskLoader を使用できます
  • 画像を非同期で読み込む場合は、 Square Picasso のような特殊なライブラリを使用できます
  • 特定の時間に一部のコードのみを実行する場合は、サービス/アラームを検討できます
  • aPI> = 7からのみ利用可能（これは問題ではありません）

最後に、SyncAdapterを使用する場合、 Firebase Cloud Messaging （以前のGoogle Cloud Messaging）別名「プッシュ通知」を真剣に検討して、最新の更新と最適化されたバッテリー使用量を取得してください。

93
rds

AccountManagerクラスは、電話アカウントと統合されています。したがって、すべてのガイドに従って正しく動作させると、「設定」->「アカウントと同期」メニューにアカウントが表示されます。そこからカスタマイズしたり、削除することもできます。さらに、accountManagerにはアカウントの認証チケットのキャッシュがあります。これは、アカウントを同期する予定がない場合にも使用できます（私の知る限り）。

アカウントをそのメニューの下に表示したくない場合は、AccountManagerを使用してアカウントデータを他の場所に保存しないでください（共有設定にある可能性があります） http://developer.Android.com/guide/topics /data/data-storage.html

23
Gab

から http://www.c99.org/2010/01/23/writing-an-Android-sync-provider-part-1/ ：

パズルの最初のピースはアカウント認証システムと呼ばれ、「アカウントと同期」設定でユーザーのアカウントがどのように表示されるかを定義します。アカウント認証システムを実装するには、3つの部分が必要です。onBindメソッドからAbstractAccountAuthenticatorのサブクラスを返すサービス、ユーザーに資格情報の入力を求めるアクティビティ、およびユーザーに表示されるときのアカウントの外観を記述するxmlファイルです。また、Android.permission.AUTHENTICATE_ACCOUNTS権限をAndroidManifest.xmlに追加する必要があります。

14
Macarse

AccountManagerは、次の理由で適切です。

  • 1つは、単一のアカウントタイプでアプリの機能への異なるアクセスレベルで複数のアカウント名を保存することです。たとえば、ビデオストリーミングアプリでは、2つのアカウント名を持つことができます。1つは限られた数のビデオへのデモアクセス、もう1つはすべてのビデオへの1か月アクセスです。ただし、これはAccountsを使用する主な理由ではありません。これは、この派手なAccountsモノを必要とせずにアプリで簡単に管理できるためです。
  • Accountsを使用するもう1つの利点は、認証がバックグラウンドで行われ、ユーザーにパスワードが要求されるため、ユーザーが認証機能を要求するたびにユーザー名とパスワードを使用して従来の認証を削除することです特定の条件でのみ、これについては後で説明します。
  • AndroidでAccounts機能を使用すると、自分のアカウントタイプを定義する必要もなくなります。おそらく、承認のためにGoogleアカウントを使用するアプリに出くわすことになります。新しいアカウントを作成し、ユーザーの資格情報を記憶します。
  • Accountsは、[設定]→[アカウント]から個別に追加できます
  • クロスプラットフォームのユーザー認証は、Accountsを使用して簡単に管理できます。たとえば、クライアントは、AndroidデバイスとPCで、保護されたマテリアルに同時にアクセスできます。繰り返しログインする必要はありません。
  • セキュリティの観点から、サーバーへのすべてのリクエストで同じパスワードを使用すると、安全でない接続で盗聴される可能性があります。ここでは、パスワードの盗難を防ぐためにパスワードの暗号化は十分ではありません。
  • 最後に、Android=でAccounts機能を使用する重要な理由は、Accountsに依存するビジネスに関係する2つのパーティを分離することです。クライアント（ユーザー）の資格情報を損なうことなく、所有者。用語はかなり曖昧に見えるかもしれませんが、次の段落を読むまであきらめないでください…

ビデオストリーミングアプリの例を使用して、後者について詳しく説明します。 A社は、特定のメンバーにプレミアムストリーミングサービスを提供するためにB社と契約しているビデオストリーミングビジネスの保有者です。会社Bは、ユーザーを認識するためにユーザー名とパスワードを使用します。会社AがBのプレミアムメンバーを認識するための1つの方法は、Bからメンバーのリストを取得し、同様のユーザー名/パスワードマッチングメカニズムを利用することです。このように、認証者とリソース所有者は同じです（会社A）。 2番目のパスワードを記憶するというユーザーの義務とは別に、Aからのサービスを使用するためにB社のプロファイルと同じパスワードを設定する可能性が非常に高くなります。これは明らかに好ましくありません。

上記の欠点を緩和するために、OAuthが導入されました。上記の例では、承認のオープンスタンダードとして、OAuthはB社による承認を要求しています。 （認証者）資格のあるユーザー（サードパーティ）にアクセストークンと呼ばれるトークンを発行し、次にトークンを会社A（リソース所有者）に提供します。

これについてさらに詳しく説明し、ウェブサイトのAccountManagerについて詳しく説明しました here。

This is a simple app using AccountManager

4
Ali Nem