Enterprise Android: Programming Android Database Applications for the Enterprise

Enterprise Android: Programming Android Database Applications for the EnterpriseReviews
Author: Zigurd Mednieks, G. Blake Meike, Laird Dornin, Zane Pan
Pub Date: 2014
ISBN: 978-1-118-22747-3
Pages: 408
Language: English
Format: PDF
Size: 10 Mb

Download

Android devices have moved beyond consumer applications into corporate and enterprise use. If you are eager to start building data-driven Android applications that integrate with enterprise systems, this book shows you how. The authors thoroughly explain how to use content providers to share data, adapters to display data, and web services to transmit data. They also show how to integrate applications with existing enterprise systems, secure data, and synchronize data. By the end of the book, you’ll have a solid understanding of how to create data-intensive applications that today’s businesses demand.
Enterprise Android:
– Focuses on making and using simple databases for caching or syncing results for REST-based applications
– Covers ContentProvider, REST, concurrency, and networking
– Details ways to use Hibernate to create a RESTful web service and connect it to Android
– Helps you enhance performance by avoiding CRUD-over-the-Internet
– Gets you started writing backend cloud services that connect to Android
– Introduces a new open source and generic synchronization framework designed specifically to integrate with Android APIs
– Addresses the security-oriented aspect of application implementation

+

In immediate mode, an authenticator methods return a bundle that contains any values the authenticator wants to return to its caller. The implementation of the addAccountmethod in Listing 5-11, for instance, has enough information so that when it is run, it can create the account on the spot (using AccountManager.addAccountExplicitly). The type and name for the single account it will create are simply resource values that it looks up.

In the bundle, the authenticator returns the account type for which the caller requested an account. If it successfully creates an account of that type, it makes the new account synchronizable, sets it up to sync automatically, and returns the account name and an authorization token for it.

Understanding the other two modes, intent and delayed, requires revisiting the client side of account management. Most of the methods on the account manager — the client-side framework that an application, Settings, in this example, uses to manage accounts — return values that are Java Futureobjects (AccountManagerFuturespecii cally). A method that creates an IPC connection and proxies its request to another process cannot provide its return values immediately. Instead it returns a future, a token that represent an asynchronous computation. The future can be redeemed for the value of that computation when the computation completes.

In the example, the Settings program calls the account manager’s addAccountmethod to manage a SyncContacts account. The method returns a Futureobject that represents the computations being done by the bound account authenticator at the other end of the connection. If the Settings program needs to obtain a result from that remote computation, it calls the future’s getResultmethod. This method blocks until the asynchronous computation is complete and then returns the bundle that is forwarded across the IPC connection from the authenticator’s addAccountmethod.

In immediate mode, the authenticator returned its result relatively quickly.The future’s getResult method on the client side of the connection would block only briel y (still too long to be called from the UI thread, however).

In intent mode, however, instead of returning values to be forwarded to the client application, the authenticator instead returns a bundle with string value for the key KEY_INTENTlike this:

Intent intent = new Intent(ctxt, AuthenticatorActivity.class);
intent.putExtra(AccountManager.KEY_ACCOUNT_AUTHENTICATOR_RESPONSE, response);
reply.putParcelable(AccountManager.KEY_INTENT, intent);

The returned bundle may contain other content, as necessary. Instead of returning this bundle directly to the client, though, the framework processes it specially. If the bundle contains a KEY_INTENTkey, the framework extracts the intent that is its value and uses it to start the activity it identii es (AuthenticatorActivity.classin this case). When the activity runs, it can take as much time as it likes and is free to interact with the user, the network, biometrics sensors, goat entrails, or anything else necessary to authenticate a new account. Frequently this means collecting some data from the user and forwarding them to a backend server. The Android framework provides the handy activity subclass AccountAuthenticatorActivityas a base class for activities that support an account authenticator.

When the activity eventually completes, it (or one of its delegates) retrieves the response object, also in the bundle returned by the authenticator, and calls its onResponsemethod.

Remember the calling client? It is still waiting for the getResultmethod of the future object returned from its call to unblock and return a value! It is only when the onResponsemethod of the response object — it was passed to the account authenticator in the original client call — is invoked, that the client’s getResultmethod i nally unblocks and returns the bundle that the authenticator supplied as parameter to the onResponsemethod. Obviously, if the authenticator is operating in intent mode, the client can wait for a very long time, to get its response. It must be designed to accommodate that eventuality.

Delayed mode is similar to intent mode, except that the account authenticator returns null instead of a bundle. When the framework observes the null response, it, again, does not unblock the caller’s getResultmethod. Unlike intent mode, though, it does not take any other action. In this mode, it is the authenticator’s responsibility to make sure that the response object’s onResponsemethod gets called. The authenticator is free to take action itself or to pass the response object along to any delegate it chooses. Eventually, though, it must make a decision and allow the client to proceed.