Aspectos Éticos

Typically, an Android application is a collection of activities, broadcast receivers, services, and content providers. The Application class is the glue that binds all these disparate pieces into a singular, unified entity. Every time a content provider, activity, service, or intent receiver in your manifest is initialized, an Application class is also spun up and available to it.

THE DEFAULT APPLICATION DECLARATION

Looking in the AndroidManifest.xml file, you’ll see a typical Application declara-tion that looks like the following:

<application android:icon=”@drawable/icon”

android:label=”@string/app_name”>

<!—Activities, Services, Broadcast Receivers, and Content Providers -->

</application>

Here you can see the <application> tag. This part of the manifest typically contains information relevant to your application at large. android:icon tells the system what icon to display in the main application list. android:label in this case refers to another entry in the strings.xml file you were editing earlier.

CUSTOMIZING YOUR OWN APPLICATION

Adding your own application is very similar to the steps you’ve already gone through to add a new activity.

1. Add a name field to the existing AndroidManifest.xml declaration.

2. Create a new class in your package that extends the Application class.

3. Profit!

Let’s go over steps 1 and 2 in depth. You’re on your own for step 3.

THE NAME

When it comes to the manifest, android:name refers not to the name of the object being described, but to the location of the class in your Java package. The Application declaration is no exception. Here’s what the opening tag of the application should look like with the new declaration:

ptg7794906

<application android:icon=”@drawable/icon”

android:label=”@string/app_name”

android:name= “.SampleApplication”>

In this declaration, you tell the system what icon you want to represent your application on the Android application drawer.

Once again, the class loader will look for your Application class by appending the contents of android:name to the end of your package declaration within the

<manifest> opening tag. Now you’ll need to actually create this class to keep the class loader from getting unhappy.

THE APPLICATION CLASS

Here’s what you’ll need, at a very basic level, to have an Application of your very own:

import android.app.Application;

public class SampleApplication extends Application{

public void onCreate(){

super.onCreate();

} }

The Application can be a very simple class. It’s hard to understand what the Application can do for you until you consider a few things:

䊏 Activities are very transient.

䊏 Activities have no access to each other’s memory, and they should com-municate through intents.

䊏 As activities are constantly being stopped and started for a variety of reasons, there’s no way for your activity to know if it’s being started for the very first time in the run of your application. The Application class’s onCreate method, on the other hand, is called only when your app is being initialized.

As such, it can be a good place to take actions that should happen only when your application is first started.

THE APPLICATION CLASS 49

ptg7794906 If you need a temporary holding pen for data that may span many activities, a

data member that’s part of the Application can be a convenient place to store it.

You must be very careful about adding data to the Application. Any single compo-nent declared in your manifest, from the simplest BroadcastReceiver to the most complex activity, will, before it’s created by the system, first create your Application object. This means you must make the Application’s onCreate method run as fast as you possibly can.

ACCESSING THE APPLICATION

All your broadcast receivers, services, activities, and content providers have a method called getApplication provided to them by the appropriate superclass.

When invoked, getApplication will return a pointer to your Application object if you specified one in the manifest. Getting access to it, now that you’ve declared and created the class, is as simple as calling getApplication and casting the returned object to an instance of your own pointer. Here’s what it looks like:

SampleApplication myApplication = (SampleApplication) getApplication();

That’s all there is to it. You can add public data members or context-sensitive methods to your own version of the Application, and with one call all your com-ponents will have access to the same object, like so:

public class SampleApplication extends Application{

public String username;

public void onCreate(){

super.onCreate();

} }

ptg7794906 To access your newly added variable, simply do the object cast listed earlier:

public void onCreate(Bundle bundle){

SampleApplication myApplication = (SampleApplication)getApplication();

myApplication.username = “sparks”;

}

Be sure that any data you put in the Application is relevant everywhere, because the overhead for allocating and initializing the Application can become a drag on startup times.

WRAPPING UP

Over the course of this chapter, I’ve exposed you to the fundamental building blocks of an Android application. I used examples to get you started on

䊏 The manifest

䊏 Creating and using your own activities

䊏 Sending, receiving, and taking advantage of intents

䊏 Creating your own Application object

It’s my hope that through the rest of the book, you’ll be able to use the building blocks you’ve learned in this chapter to understand how an Android application functions. From here on out, I’ll be focusing more on how to do tasks rather than on the theories that back them. On that note, let’s start making screens that include more than just a single text view.

WRAPPING UP 51

ptg7794906

3

CREATING USER