Setup Android IDE SDK

The Android SDK supports several different integrated development environments (IDEs). For this book we will focus on Eclipse because it is the IDE that is best integrated with the SDK, and, hey, it's free. No matter which operating system you are using, you will need essentially the same set of tools:

• The Eclipse IDE
• Sun's Java Development Kit (JDK)
• The Android Software Developer's Kit (SDK)
• The Android Developer Tool (ADT), a special Eclipse plug-in

Since you're probably going to develop on only one of the host operating systems, skip to the appropriate section that pertains to your selected operating system.

Android Activity Lifecycle

Android is designed around the unique requirements of mobile applications. In particular, Android recognizes that resources (memory and battery, for example) are limited on most mobile devices, and provides mechanisms to conserve those resources. The mechanisms are evident in the Android Activity Lifecycle, which defines the states or events that an activity goes through from the time it is created until it finishes running. The lifecycle is shown diagrammatically in Figure 1-1.


Your activity monitors and reacts to these events by instantiating methods that override the Activity class methods for each event:



onCreate

Called when your activity is first created. This is the place you normally create your views, open any persistent datafiles your activity needs to use, and in general initialize your activity. When calling onCreate, the Android framework is passed a Bundle object that contains any activity state saved from when the activity ran before.



onStart

Called just before your activity becomes visible on the screen. Once onStart completes, if your activity can become the foreground activity on the screen, control will transfer to onResume. If the activity cannot become the foreground activity for some reason, control transfers to the onStop method.



onResume

Called right after onStart if your activity is the foreground activity on the screen. At this point your activity is running and interacting with the user. You are receiving keyboard and touch inputs, and the screen is displaying your user interface. onResume is also called if your activity loses the foreground to another activity, and that activity eventually exits, popping your activity back to the foreground. This is where your activity would start (or resume) doing things that are needed to update the user interface (receiving location updates or running an animation, for example).



onPause

Called when Android is just about to resume a different activity, giving that activity the foreground. At this point your activity will no longer have access to the screen, so you should stop doing things that consume battery and CPU cycles unnecessarily. If you are running an animation, no one is going to be able to see it, so you might as well suspend it until you get the screen back. Your activity needs to take advantage of this method to store any state that you will need in case your activity gains the foreground again—and it is not guaranteed that your activity will resume. If the mobile device you are running on runs out of memory, there is no virtual memory on disk to use for expansion, so your activity may have to make way for a system process that needs memory. Once you exit this method, Android may kill your activity at any time without returning control to you.



onStop

Called when your activity is no longer visible, either because another activity has taken the foreground or because your activity is being destroyed.



onDestroy

The last chance for your activity to do any processing before it is destroyed. Normally you'd get to this point because the activity is done and the framework called its finish method. But as mentioned earlier, the method might be called because Android has decided it needs the resources your activity is consuming.

Components of an Android Application

Your Android applications will be built from four basic component types that are defined by the Android architecture:

Activities

These are comparable to standalone utilities on desktop systems, such as office applications. Activities are pieces of executable code that come and go in time, instantiated by either the user or the operating system and running as long as they are needed. They can interact with the user and request data or services from other activities or services via queries or Intents (discussed in a moment).

Most of the executable code you write for Android will execute in the context of an Activity. Activities usually correspond to display screens: each Activity shows one screen to the user. When it is not actively running, an Activity can be killed by the operating system to conserve memory.

Services

These are analogous to services or daemons in desktop and server operating systems. They are executable pieces of code that usually run in the background from the time of their instantiation until the mobile handset is shut down. They generally don't expose a user interface.

The classic example of a Service is an MP3 player that needs to keep playing queued files, even while the user has gone on to use other applications. Your application may need to implement Services to perform background tasks that persist without a user interface.

Broadcast and Intent Receivers

These respond to requests for service from another application. A Broadcast Receiver responds to a system-wide announcement of an event. These announcements can come from Android itself (e.g., battery low) or from any program running on the system. An Activity or Service provides other applications with access to its functionality by executing an Intent Receiver, a small piece of executable code that responds to requests for data or services from other activities. The requesting (client) activity issues an Intent, leaving it up to the Android framework to figure out which application should receive and act on it.

Intents are one of the key architectural elements in Android that facilitate the creation of new applications from existing applications (mobile mashups). You will use Intents in your application to interact with other applications and services that provide information needed by your application. Intents and Intent Receivers are covered in more detail in Chapter 13.

Content providers

These are created to share data with other activities or services. A content provider uses a standard interface in the form of a URI to fulfill requests for data from other applications that may not even know which content provider they are using. For example, when an application issues a query for Contact data, it addresses the query to a URI of the form:

content://contacts/people

The operating system looks to see which applications have registered themselves as content providers for the given URI, and sends the request to the appropriate application (starting the application if it is not already running). If there is more than one content provider registered for the requested URI, the operating system asks the user which one he wants to use.

An application doesn't have to use all of the Android components, but a well-written application will make use of the mechanisms provided, rather than reinventing functionality or hardcoding references to other applications. URIs and Intents together allow Android to provide a very flexible user environment. Applications can be easily added, deleted, and substituted, and the loose coupling of intents and URIs keeps everything working together.

Why android is better than proprietary software stacks

Proprietary software stacks

Most existing smartphones use proprietary, relatively closed software stacks, such as Nokia's Series 60 with the Symbian operating system, or Microsoft's Windows Mobile. Modifications to these stacks (adding a driver, for example) have to be done either by the stack owner or by the handset manufacturer. The stacks are not open source, so changing anything in the stack is difficult at best. Most Linux-based phones to date have an open source kernel (as required by the GPL license), but keep other details of the software stack (application framework, multimedia framework, applications) proprietary.