What Should I Use Android Accountmanager For

Android AccountManager :Which account is being used?

Based on the information and clarification by @RocketRandom , it is clear that Account Manager just provides the service.
The user/app developer should work out the proper way to handle the accounts.

For my specific problem (Multi User Login), i present user with a selection list(Custom) which allows me to pass on specific user data to SyncAdapter, which in turn load the account related Sqlite db (I am using separate db for each user).

Should you use AccountManager for storing Usernames and Passwords for an Android app?

This accepted answer to this question would probably help you...
What should I use Android AccountManager for?

It should also be pointed out, as mentioned in the above post and also in AccountManager without a SyncAdapter? , that you can't have an AccountManager without a SyncAdapter, so its probably not good to use this for your particular situation.

I can't see any reason to use an AccountManager specifically for storing this type of information - at the end of the day, its no different to manually storing the data yourself in your own database or file. If anything, it probably complicates things - why don't you just store it in SharedPreferences?

The only reason I could think of that would encourage the use of AccountManager would be if you want to share your account across a number of different apps, as the data is stored in the central Android datastore which can be accessed by all apps. However, if this isn't required, I think its probably easier and simpler to just use SharedPreferences

AccountManager: when to set result?

Methods setAccountAuthenticatorResult(Bundle) and onResult(Bundle) are meant to notify the AbstractAccountAuthenticator about the outcome, but I have a project working without them, what are they for ?

Those methods (as well as onError) are to pass back a result to whoever might wait for one, e.g. have a look at AccountManager.getAuthToken(...) and many others that let you specify a AccountManagerCallback<Bundle>. This is where your result will be passed to. null is valid for the callback, so unless you structure your app around the result, it will work without it.

AccountAuthenticatorResponse.onResult(Bundle) and onError(...) are much more important if you implement getAuthToken where this is how you can return an access token from an asynchronous backend call (e.g. token refresh).

What is onRequestContinued() for ?

There is very little information (reads: none) available. The only time it gets used that I could find was in AccountManagerService where it's but a counter that gets increased for logging purposes. I don't think it does anything at the moment.

When addAccount is finished and the account created, should onActivityResult be called on the Activity that triggered it?

Should work as long as you use startActivityForResult(..)

If an Intent is returned with key AccountManager.KEY_INTENT in addAccount implementation, the AbstractAccountAuthenticator will start the Intent. I have noticed that many developers add extras. Who gets them ?

As already mentioned by kris, you can return an Intent that starts your Activity and pass any extras that you might need.

---

On an unrelated note: You should really try not to store any passwords in plain text. Even though the AccountManager says setPassword() it is not protected and thus not secure.

Accountmanager vs sharedpreference for authentication and server communication

I would recommend you to think about your requirement first. If authentication is like google+, Facebook and Twitter then I would suggest you to use AccountManager

AccountManager: This centralized registry of user's online account. Account Manager is capable of storing the OAuth token and does the job for all Google Apps in Android.

SharedPreferences:This is for storing and retrieving small range of data for more this.

---

Related Topics