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?
This question is a bit old, but I think it is still of good interest.
- You cannot have a
- You cannot have a
But you can:
- use the
ContentProviderwithout the others.
- use the
AccountManagerwithout the others (but you cannot use an
SyncAdapterbefore Android 2.2 / Froyo API 8)
AccountManagergives 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)
ContentProvideris a convenient way to share data across applications
Note: there are other methods of inter-process communication on Android.
ContentProviderschedules the database access in a background thread
AsyncQueryHanlderhelps to query the
ContentProviderin a background thread, preventing Application Not Responsive (ANR) errors while not requiring you to explicitly handle threading.
ContentResolver‘s observer: this means it is easy to notify views when content is changed
Bottom line: the framework
ContentProvider helps if you want to synchronize data from a web resource. Fake/Dumb implementations are required on API 7. Also
- 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
- 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)
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.
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).
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
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
permission to your
AccountManager is good for the following reasons:
- 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-looking
- The other advantage of using
Accountsis 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
Accountsfeature 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.
Accountscan 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
Accountsfeature in android is to separate the two parties involved in any business dependent on
Accounts, 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 … 😉
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.
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.
I have elaborated more on this and more on
AccountManager on my website here.