Managing Accounts with the Account Manager Android

From a user perspective, the Android 2.0 platform introduced many exciting new device features. For instance, the user can register and use multiple accounts for email and contact management. This feature was provided through a combination of new synchronization and account services that are also available to developers. Although you can use the account and synchronization packages with any kind of data, the intention seems to be to provide a way for developers and companies to integrate their business services with the system that synchronizes data to the built-in Android applications.

Android user accounts are manipulated using the classes available within the android.accounts package. This functionality is primarily designed for accounts with services that contain contact, email, or other such information in them. A good example of this type of online service is a social networking application that contains friends’ contact information, as well as other relevant information such as their statuses. This information is often delivered and used on an Android device using the synchronization service (we talk more about synchronization later in the chapter).

First, we talk about accounts.Accounts registered with the Android account manager should provide access to the same sort of information—contact information, for the most part. Different accounts can be registered for a given user using the Android AccountManager class. Each account contains authentication information for a service, usually credentials for a server account somewhere online. Android services, such as the synchronization services built-in to the platform, can access these accounts, mining them for the appropriate types of information (again, primarily contact details, but also other bits of data such as social networking status).

Let’s look at how using account information provided via the AccountManager and Account classes works. An application that needs to access the server can request a list of accounts from the system. If one of the accounts contains credentials for the server, the application can request an authentication token for the account. The application would then use this token as a way to log in to the remote server to access its services. This keeps the user credentials secure and private while also providing a convenience to the user in that they only need to provide their credentials once, regardless of how many applications use the information. All these tasks are achieved using the AccountManager class. A call to the getAccountByType() method retrieves a list of accounts and then a call to the getAuthToken() method retrieves the token associated with a specific account, which the application can use to communicate with a password-protected resource, such as a web service.

On the other side of this process, authenticating credentials against the back-end server are the account providers. That is, the services that provide users with accounts and with which user information is authenticated so the applications can get the auth tokens. In order to do all of this (handle system requests to authenticate an Account object against the remote server), the account provider must implement an account authenticator. Through the authenticator, the account provider requests appropriate credentials and then confirms them with whatever account authentication operations are necessary—usually an online server. To implement an account authenticator, you need to make several modifications to your application. Begin by implementing the AbstractAccount Authenticator class. You also need to update the application’s Android Manifest file, provide an authenticator configuration file (XML), and provide an authenticator preference screen configuration in order to make the authentication experience as seamless as possible for the user.

Synchronizing Data with Sync Adapters

The synchronization feature available in the Android SDK requires the use of the accounts classes we talked about earlier. This service is principally designed to enable syncing of contact, email, and calendar data to the built-in applications from a back-end datastore— you’re “adapting” back-end server data to the existing content providers. That is, the service is not generally used for syncing data specific to your typical Android application. In theory, applications could use this service to keep data in sync, but they might be better served by implementing synchronization internally. You could do this using the Using AlarmManager class to schedule systematic data synchronization via the network, perhaps using an Android service.

If, however, you are working with data that is well suited to syncing to the internal applications, such as contacts or calendar information that you want to put in the built-in applications and content providers, implementing a sync adapter makes sense. This enables the Android system to manage synchronization activities.

The account service must provide the sync adapter by extending the Abstract Threaded Sync Adapter class. When the sync occurs, the onPerformSync() method of the sync adapter is called. The parameters to this method tell the adapter what account (as defined by the Account parameter) is being used, thus providing necessary authentication tokens (auth token, for short) for accessing protected resources without the need for asking the user for credentials. The adapter is also told which content provider to write the data to and for which authority, in the content provider sense, the data belongs to.

In this way, synchronization operations are performed on their own thread at a time requested by the system. During the sync, the adapter gets updated information from the server and synchronizes it to the given content provider. The implementation details for this are flexible, and up to the developer.

All rights reserved © 2018 Wisdom IT Services India Pvt. Ltd Protection Status

Android Topics