我应该使用 Android AccountManager 做什么?
声明:本页面是StackOverFlow热门问题的中英对照翻译,遵循CC BY-SA 4.0协议,如果您需要使用它,必须同样遵循CC BY-SA许可,注明原文地址和作者信息,同时你必须将它归于原作者(不是我):StackOverFlow
原文地址: http://stackoverflow.com/questions/2720315/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me):
StackOverFlow
What should I use Android AccountManager for?
提问by Phil
I've seen AccountManager in the Android SDK and that it is used for storing account information. Thus, I cannot find any general discussion of what it is intended for. Does anyone know of any helpful discussions of what the intention behind AccountManager is and what it buys you? Any opinions of what type of Accounts this is suitable for? Would this be where you'd put your user's account information for a general web service?
我在 Android SDK 中看到过 AccountManager,它用于存储帐户信息。因此,我找不到关于它的用途的任何一般性讨论。有谁知道关于 AccountManager 背后的意图是什么以及它给你带来什么的任何有用的讨论?对这适用于什么类型的帐户有任何意见吗?这是您将用户的帐户信息用于一般 Web 服务的位置吗?
回答by rds
This question is a bit old, but I think it is still of good interest.
这个问题有点老了,但我认为它仍然很有趣。
AccountManager
, SyncAdapter
and ContentProvider
go together.
AccountManager
,SyncAdapter
并ContentProvider
一起去。
- You cannot have a
SyncAdapter
without anAccount
in theAccountManager
. - You cannot have a
SyncAdapter
without aContentProvider
.
But you can:
但是你可以:
- use the
ContentProvider
without the others. - use the
AccountManager
without the others (but you cannot use anAccountManager
without aSyncAdapter
before Android 2.2 / Froyo API 8)
- 在
ContentProvider
没有其他人的情况下使用。 - 使用
AccountManager
不带其他的(但在 Android 2.2 / Froyo API 8 之前不能使用AccountManager
不带SyncAdapter
)
With AccountManager
/ SyncAdapter
/ ContentProvider
:
与AccountManager
/ SyncAdapter
/ ContentProvider
:
AccountManager
gives users a central point (Settings > Accounts) to define their credentials- Android decides when synchronization can be done via
SyncAdapter
. This can be good to optimize battery (no sync is done when network is down, for instance) ContentProvider
is a convenient way to share data across applications Note: there are other methods of inter-process communication on Android.TheContentProvider
schedules the database access in a background threadAsyncQueryHanlder
helps to query theContentProvider
in a background thread, preventing Application Not Responsive (ANR) errors while not requiring you to explicitly handle threading.ContentProvider
ties intoContentResolver
's observer: this means it is easy to notify views when content is changed
AccountManager
为用户提供一个中心点(设置 > 帐户)来定义他们的凭据- Android 决定何时可以通过
SyncAdapter
. 这可以很好地优化电池(例如,当网络关闭时不进行同步) ContentProvider
是跨应用程序共享数据的便捷方式 注意:Android 上还有其他进程间通信方法。的ContentProvider
安排在后台数据库访问线程AsyncQueryHanlder
帮助查询ContentProvider
在后台线程,防止应用程序没有响应(ANR)错误,同时不要求你明确地处理线程。ContentProvider
绑定到ContentResolver
的观察者:这意味着当内容改变时很容易通知视图
Bottom line: the framework AccountManager
/ SyncAdapter
/ ContentProvider
helps if you want to synchronize data from a web resource. Fake/Dumb implementationsare required on API 7. Also
底线:框架AccountManager
/ SyncAdapter
/ContentProvider
帮助,如果你想将数据从一个网络资源同步。API 7 上需要Fake/ Dumb 实现。此外
- If you only want to store data, you should consider a simpler mechanism for data storage
- If you only need to fetch an only resource, you can use an
AsyncTaskLoader
- If you want to load images asynchronously, you can use specialized libraries like Square Picasso
- If you only want to execute some code at a given time, you can consider a Service / Alarm
- only available from API >= 7 (this doesn't matter anymore)
- 如果只想存储数据,应该考虑更简单的数据存储机制
- 如果你只需要获取一个唯一的资源,你可以使用
AsyncTaskLoader
- 如果你想异步加载图像,你可以使用像Square Picasso这样的专门库
- 如果你只想在给定的时间执行一些代码,你可以考虑一个 Service/Alarm
- 仅适用于 API >= 7(这不再重要)
Finally, if you use a SyncAdapter
, seriously consider Firebase Cloud Messaging(previously Google Cloud Messaging) aka "push notifications" to have fresher updates and optimized battery usage.
最后,如果您使用SyncAdapter
,请认真考虑Firebase Cloud Messaging(以前称为 Google Cloud Messaging)又名“推送通知”,以获得更新的更新和优化的电池使用。
回答by Gab
The AccountManager class is integrated with your phone accounts. So if you follow all the guides and get it working correctly you'll see your accounts under the menu "Settings->accounts and sync". From there you can customize them or even delete them. Furthermore the accountManager has a cache of the authentication tickets for your accounts. This can be used also if you don't plan to synchronize your account (as far as I know).
AccountManager 类与您的电话帐户集成在一起。因此,如果您遵循所有指南并使其正常工作,您将在“设置->帐户和同步”菜单下看到您的帐户。从那里您可以自定义它们甚至删除它们。此外, accountManager 具有您帐户的身份验证票证的缓存。如果您不打算同步您的帐户(据我所知),这也可以使用。
If you don't want your accounts to appear under that menu you shouldn't use the AccountManager and store the accounts data elsewhere (maybe in the shared preferences) http://developer.android.com/guide/topics/data/data-storage.html
如果您不希望您的帐户出现在该菜单下,则不应使用 AccountManager 并将帐户数据存储在其他地方(可能在共享首选项中)http://developer.android.com/guide/topics/data/data -storage.html
回答by Macarse
From http://www.c99.org/2010/01/23/writing-an-android-sync-provider-part-1/:
从http://www.c99.org/2010/01/23/writing-an-android-sync-provider-part-1/:
The first piece of the puzzle is called an Account Authenticator, which defines how the user's account will appear in the “Accounts & Sync” settings. Implementing an Account Authenticator requires 3 pieces: a service that returns a subclass of AbstractAccountAuthenticator from the onBind method, an activity to prompt the user to enter their credentials, and an xml file describing how your account should look when displayed to the user. You'll also need to add the android.permission.AUTHENTICATE_ACCOUNTS permission to your AndroidManifest.xml.
谜题的第一部分称为帐户身份验证器,它定义了用户帐户在“帐户与同步”设置中的显示方式。实现帐户身份验证器需要 3 个部分:一个从 onBind 方法返回 AbstractAccountAuthenticator 子类的服务、一个提示用户输入其凭据的活动,以及一个描述您的帐户在向用户显示时的外观的 xml 文件。您还需要将 android.permission.AUTHENTICATE_ACCOUNTS 权限添加到您的 AndroidManifest.xml。
回答by Ali Nem
The AccountManager
is good for the following reasons:
该AccountManager
是由于以下原因好:
- First is to store multiple account names with different levels of access to the app's features under a single account type. For example, in a video streaming app, one may have two account names: one with demo access to a limited number of videos and the other with full-month access to all videos. This is not the main reason for using
Accounts
, however, since you can easily manage that in your app without the need for this fancy-lookingAccounts
thing… . - The other advantage of using
Accounts
is to get rid of the traditional authorization with username and password each time an authorized feature is requested by the user, because the authentication takes place in the background and the user is asked for their password only in certain condition, which I will get to it later. - Using the
Accounts
feature in android also removes the need for defining one's own account type. You have probably come across the apps using Google accounts for authorization, which saves the hassle of making a new account and remembering its credentials for the user. Accounts
can be added independently through Settings → Accounts- Cross-platform user authorization can be easily managed using
Accounts
. For example, the client can access protected material at the same time in their android device and PC without the need for recurrent logins. - From the security point of view, using the same password in every request to the server allows for possible eavesdropping in non-secure connections. Password encryption is not sufficient here to prevent password theft.
- Finally, an important reason for using the
Accounts
feature in android is to separate the two parties involved in any business dependent onAccounts
, so called authenticator and resource owner, without compromising the client (user)'s credentials. The terms may seem rather vague, but don't give up until you read the following paragraph …
- 首先是在单一帐户类型下存储具有不同级别的应用程序功能访问权限的多个帐户名称。例如,在视频流应用程序中,一个可能有两个帐户名:一个具有对有限数量视频的演示访问权限,另一个具有对所有视频的整月访问权限。
Accounts
然而,这不是使用 的主要原因,因为您可以在您的应用程序中轻松管理它,而无需这个看起来很花哨的Accounts
东西......。 - 使用的另一个优点
Accounts
是摆脱了每次用户请求授权功能时使用用户名和密码的传统授权,因为身份验证是在后台进行的,并且仅在特定条件下才要求用户输入密码,这稍后我会谈到它。 Accounts
在 android 中使用该功能还消除了定义自己的帐户类型的需要。您可能遇到过使用 Google 帐户进行授权的应用程序,这样可以省去创建新帐户和记住用户凭据的麻烦。Accounts
可以通过设置→账户独立添加- 可以使用 轻松管理跨平台用户授权
Accounts
。例如,客户端可以同时在他们的安卓设备和 PC 中访问受保护的材料,而无需重复登录。 - 从安全的角度来看,在对服务器的每个请求中使用相同的密码允许在非安全连接中进行可能的窃听。这里密码加密不足以防止密码被盗。
- 最后,
Accounts
在 android 中使用该功能的一个重要原因是将涉及任何依赖于 的业务的两方(Accounts
所谓的身份验证者和资源所有者)分开,而不损害客户端(用户)的凭据。这些条款可能看起来相当模糊,但在阅读以下段落之前不要放弃......
Let me elaborate on the latter with an example of a video streaming app. Company A is the holder of a video streaming business in contract with Company B to provide its certain members with premium streaming services. Company B employs a username and password method for recognizing its user. For Company A to recognize the premium members of B, one way would be to get the list of them from B and utilize similar username/password matching mechanism. This way, the authenticator and resource owner are the same (Company A). Apart from the users obligation to remember a second password, it is very likely that they set the same password as their Company B's profile for using the services from A. This is obviously not favorable.
让我用一个视频流应用程序的例子来详细说明后者。A 公司持有与 B 公司签订合同的视频流媒体业务,为其某些成员提供优质的流媒体服务。B 公司采用用户名和密码方法来识别其用户。对于 A 公司识别 B 的高级会员,一种方法是从 B 获取他们的列表并使用类似的用户名/密码匹配机制。这样,验证者和资源所有者是相同的(A 公司)。除了用户有义务记住第二个密码外,他们很可能在使用 A 公司的服务时设置了与 B 公司配置文件相同的密码。这显然是不利的。
To allay the above shortcomings, OAuth was introduced. As an open standard for authorization, in the example above, OAuth demands that the authorization be done by Company B (authenticator) by issuing some token called Access Token for the eligible users (third party) and then providing Company A (resource owner) with the token. So no token means no eligibility.
为了弥补上述缺点,引入了OAuth。作为授权的开放标准,在上面的例子中,OAuth 要求 B 公司(身份验证者)通过为符合条件的用户(第三方)颁发一些称为 Access Token 的令牌,然后向 A 公司(资源所有者)提供授权来完成授权。令牌。所以没有令牌意味着没有资格。
I have elaborated more on this and more on AccountManager
on my website here.
我AccountManager
在我的网站上对此进行了更多详细说明。