Android Application & Activities
An activity is a single, focused thing that the user can do. Almost all activities interact with the user, so the Activity class takes care of creating a window for you, in which you can place your UI with
setContentView(View). While activities are often presented to the user as full-screen windows, they can also be used in other ways: as floating windows (via a theme with
windowIsFloating set) or embedded inside of another activity (using
ActivityGroup). There are two methods almost all subclasses of Activity will implement:
onCreate(Bundle)is where you initialize your activity. Most importantly, here you will usually call
setContentView(int)with a layout resource defining your UI, and using
findViewById(int)to retrieve the widgets in that UI that you need to interact programmatically.
onPause()is where you deal with the user leaving your activity. Most importantly, any changes made by the user should at this point be committed (usually to the
ContentProviderholding the data)
To create an activity, you must create a subclass of Activity (or an existing subclass of it). In your subclass, you need to implement callback methods that the system calls when the activity transitions between various states of its lifecycle, such as when the activity is being created, stopped, resumed, or destroyed. The two most important callback methods are:
You must implement this method. The system calls this when creating your activity. Within your implementation, you should initialize the essential components of your activity. Most importantly, this is where you must call setContentView() to define the layout for the activity’s user interface.
The system calls this method as the first indication that the user is leaving your activity (though it does not always mean the activity is being destroyed). This is usually where you should commit any changes that should be persisted beyond the current user session (because the user might not come back).
There are several other lifecycle callback methods that you should use in order to provide a fluid user experience between activities and handle unexpected interruptions that cause your activity to be stopped and even destroyed.
Implementing a user Interface
Your app’s user interface is everything that the user can see and interact with. Android provides a variety of pre-built UI components such as structured layout objects and UI controls that allow you to build the graphical user interface for your app. Android also provides other UI modules for special interfaces such as dialogs, notifications, and menus.
Android provides a number of ready-made views that you can use to design and organize your layout. “Widgets” are views that provide a visual (and interactive) elements for the screen, such as a button, text field, checkbox, or just an image. “Layouts” are views derived from ViewGroup that provide a unique layout model for its child views, such as a linear layout, a grid layout, or relative layout. You can also subclass the View and ViewGroup classes (or existing subclasses) to create your own widgets and layouts and apply them to your activity layout.
The most common way to define a layout using views is with an XML layout file saved in your application resources. This way, you can maintain the design of your user interface separately from the source code that defines the activity’s behavior. You can set the layout as the UI for your activity with setContentView(), passing the resource ID for the layout. However, you can also create new Views in your activity code and build a view hierarchy by inserting new Views into a ViewGroup,then use that layout by passing the root ViewGroup to setContentView().
Declaring the Activity in the Manifest
The activity must be declared in the manifest file in order to access by the system. The manifest file is an xml file included in the application and default known as AndroidManifest.xml.
Open the file from the project and edit the xml to add the activity in the file.
The activity is the child node of the application node. The multiple activities can specify by multiple nodes of activity.
Each node of activity will specify the name of the activity to recognize by the system. One activity must be declare as the main activity.
<? xml version="1.0" encoding="utf-8"?>
//add the minsdkVersion to support backward compatibility
<uses-sdk android:minSdkVersion="4" android:targetSdkVersion="15" />
android:icon="@drawable/ic_launcher" //change your app icon here
android:label="@string/app_name" > //change your app name here
<activity //main activity
<action android:name="android.intent.action.MAIN" />
<category android:name="android.intent.category.LAUNCHER" />
<activity //add another activity
USING INTENT FILTERS
An <activity> element can also specify various intent filters—using the <intent-filter> element—in order to declare how other application components may activate it.
When you create a new application using the Android SDK tools, the stub activity that’s created for you automatically includes an intent filter that declares the activity responds to the “main” action and should be placed in the “launcher” category. The intent filter looks like this:
<activity android:name=".ExampleActivity" android:icon="@drawable/app_icon"> <intent-filter>
<action android:name="android.intent.action.MAIN" />
<category android:name="android.intent.category.LAUNCHER" /> </intent-filter>
The <action> element specifies that this is the “main” entry point to the application. The <category> element specifies that this activity should be listed in the system’s application launcher (to allow users to launch this activity).
If you intend for your application to be self-contained and not allow other applications to activate its activities, then you don’t need any other intent filters. Only one activity should have the “main” action and “launcher” category, as in the previous example. Activities that you don’t want to make available to other applications should have no intent filters and you can start them yourself using explicit intents.
However, if you want your activity to respond to implicit intents that are delivered from other applications (and your own), then you must define additional intent filters for your activity. For each type of intent to which you want to respond, you must include an <intent-filter> that includes an <action> element and, optionally, a <category> element and/or a <data> element. These elements specify the type of intent to which your activity can respond.