我应该使用 Android 帐户管理器做什么？

我在 Android SDK 中看到过 AccountManager，它用于存储帐户信息。因此，我找不到任何关于它的目的的一般性讨论。有没有人知道关于 AccountManager 背后的意图是什么以及它能给你带来什么的有益讨论？对于这种帐户适合什么类型有什么意见吗？这是您放置一般 Web 服务用户帐户信息的地方吗？

67608 次浏览
小开

来自 http://www.c99.org/2010/01/23/writing-an-android-sync-provider-part-1/:

拼图的第一块是 称为帐户认证程序 定义用户的帐户将如何 出现在“会计与同步”中 设置。实现帐户 身份验证器需要3个部分: a 服务，该服务返回 中的 AbstractAccountAuthenticator OnBind 方法，要提示的活动 用户输入他们的凭据, 和一个 xml 文件，描述您的 当显示到 您还需要添加 权限 允许你 AndroidManifest.xml.

小开

AccountManager 类与您的电话帐户集成在一起。因此，如果你遵循所有的指南，让它正常工作，你会看到你的帐户在菜单“设置-> 帐户和同步”。从那里您可以定制它们，甚至删除它们。此外，AccountManager 还有一个用于您的帐户的身份验证票据缓存。 如果您不打算同步您的帐户(据我所知) ，这也可以使用。

如果您不希望您的帐户出现在该菜单下，您不应该使用 AccountManager 并将帐户数据存储在其他地方(可能在共享首选项中) http://developer.android.com/guide/topics/data/data-storage.html

小开

这个问题有点老，但我认为它仍然很有意思。

AccountManager，SyncAdapter和 ContentProvider一起走。

但你可以:

使用 AccountManager/SyncAdapter/ContentProvider:

  • AccountManager为用户提供了一个中心点(设置 > 帐户)来定义他们的凭据
  • Android 决定何时可以通过 SyncAdapter进行同步。这有助于优化电池(例如，网络关闭时不进行同步)
  • ContentProvider是跨应用程序共享数据的一种方便方法 注意: 有 安卓系统的其他行程间通讯。
  • ContentProvider在后台线程中调度数据库访问 AsyncQueryHanlder帮助在后台线程中查询 ContentProvider，防止应用程序不响应(ANR)错误，同时不要求显式处理线程。
  • ContentProvider绑定到 ContentResolver的观察者: 这意味着当内容发生变化时很容易通知视图

底线 : 框架 AccountManager/SyncAdapter/ContentProvider有助于从 Web 资源同步数据。API 7要求使用假货/愚蠢的实现。还有

  • 如果只想存储数据，则应考虑使用 更简单的数据存储机制
  • 如果只需要获取唯一的资源，则可以使用 AsyncTaskLoader
  • 如果希望异步加载图像，可以使用专门的库，如 毕加索广场
  • 如果您只想在给定的时间执行某些代码，可以考虑使用 Service/Alarm
  • 只能从 API > = 7获得(这已经不重要了)

最后，如果你使用的是 SyncAdapter，认真考虑一下 火库云消息(之前的 Google云消息传递) ，也就是“推送通知”，以便更新和优化电池使用。

小开

基于以下原因，AccountManager表现良好:

  • 首先是在一个帐户类型下存储具有不同级别的应用程序功能访问权限的多个帐户名称。例如，在一个视频流应用程序中，一个可能有两个帐户名称: 一个用于演示访问数量有限的视频，另一个用于全月访问所有视频。这不是使用 Accounts的主要原因，但是，因为你可以很容易地在你的应用程序管理，而不需要这个花哨的 Accounts东西..。
  • 使用 Accounts的另一个好处是，每次用户请求授权功能时，都能摆脱使用用户名和密码的传统授权，因为身份验证是在后台进行的，只有在特定情况下才会请求用户输入他们的密码，这一点我稍后会讲到。
  • 在 android 中使用 Accounts特性也消除了定义自己帐户类型的需要。您可能已经遇到过使用谷歌帐户进行授权的应用程序，这省去了创建新帐户和记住用户凭据的麻烦。
  • Accounts可以通过设置→帐户独立添加
  • 使用 Accounts可以很容易地管理跨平台用户授权。例如，客户端可以在他们的机器人设备和 PC 上同时访问受保护的材料，而不需要重复登录。
  • 从安全性的角度来看，在每个对服务器的请求中使用相同的密码可以在不安全的连接中进行窃听。这里的密码加密不足以防止密码被盗。
  • 最后，在 android 中使用 Accounts特性的一个重要原因是，在不损害客户(用户)凭证的情况下，将任何依赖于 Accounts的业务(即所谓的身份验证器和资源所有者)中涉及的双方分开。这些条款可能看起来相当模糊，但是不要放弃，直到你读到下面的段落..。

让我用一个视频流应用程序的例子来详细说明后者。A 公司是视频流媒体业务的持有者，与 B 公司签订合同，为其某些会员提供优质的流媒体服务。公司 B 使用用户名和密码方法来识别其用户。对于 A 公司来说，要识别 B 公司的高级会员，一种方法是从 B 公司获得这些高级会员的名单，并利用类似的用户名/密码匹配机制。这样，身份验证器和资源所有者是相同的(公司 A)。除了用户有义务记住第二个密码外，他们很可能为使用 A 公司的服务而设置与 B 公司的配置文件相同的密码。这显然是不利的。

为了减轻上述缺点，引入了 OAuth。作为授权的开放标准，在上面的例子中，OAuth 要求授权由公司 B (身份验证器)完成，为合格的用户(第三方)发出一个名为 Access Token 的令牌，然后向公司 A (资源所有者)提供该令牌。所以没有信物就意味着没有资格。

我已经在我的网站 给你。上详细阐述了更多关于 AccountManager的内容

This is a simple app using AccountManager


提交答案