core/java/android/app/package.html - platform/frameworks/base - Git at Google

 <html>
 <head>
 <script type="text/javascript" src="http://www.corp.google.com/style/prettify.js"></script>
 <script src="http://www.corp.google.com/eng/techpubs/include/navbar.js" type="text/javascript"></script>
 </head>

 <body>

 <p>High-level classes encapsulating the overall Android application model.
 The central class is {@link android.app.Activity}, with other top-level
 application components being defined by {@link android.app.Service} and,
 from the {@link android.content} package, {@link android.content.BroadcastReceiver}
 and {@link android.content.ContentProvider}.  It also includes application
 tools, such as dialogs and notifications.</p>

 <p>This package builds on top of the lower-level Android packages
 {@link android.widget}, {@link android.view}, {@link android.content},
 {@link android.text}, {@link android.graphics}, {@link android.os}, and
 {@link android.util}.</p>

 <p>An {@link android.app.Activity Activity} is a specific operation the
 user can perform, generally corresponding
 to one screen in the user interface.
 It is the basic building block of an Android application.
 Examples of activities are "view the
 list of people," "view the details of a person," "edit information about
 a person," "view an image," etc.  Switching from one activity to another
 generally implies adding a new entry on the navigation history; that is,
 going "back" means moving to the previous activity you were doing.</p>

 <p>A set of related activities can be grouped together as a "task".  Until
 a new task is explicitly specified, all activites you start are considered
 to be part of the current task.  While the only way to navigate between
 individual activities is by going "back" in the history stack, the group
 of activities in a task can be moved in relation to other tasks: for example
 to the front or the back of the history stack.  This mechanism can be used
 to present to the user a list of things they have been doing, moving
 between them without disrupting previous work.
 </p>

 <p>A complete "application" is a set of activities that allow the user to do a
 cohesive group of operations -- such as working with contacts, working with a
 calendar, messaging, etc.  Though there can be a custom application object
 associated with a set of activities, in many cases this is not needed --
 each activity provides a particular path into one of the various kinds of
 functionality inside of the application, serving as its on self-contained
 "mini application".
 </p>

 <p>This approach allows an application to be broken into pieces, which
 can be reused and replaced in a variety of ways.  Consider, for example,
 a "camera application."  There are a number of things this application
 must do, each of which is provided by a separate activity: take a picture
 (creating a new image), browse through the existing images, display a
 specific image, etc.  If the "contacts application" then wants to let the
 user associate an image with a person, it can simply launch the existing
 "take a picture" or "select an image" activity that is part of the camera
 application and attach the picture it gets back.
 </p>

 <p>Note that there is no hard relationship between tasks the user sees and
 applications the developer writes.  A task can be composed of activities from
 multiple applications (such as the contact application using an activity in
 the camera application to get a picture for a person), and multiple active
 tasks may be running for the same application (such as editing e-mail messages
 to two different people).  The way tasks are organized is purely a UI policy
 decided by the system; for example, typically a new task is started when the
 user goes to the application launcher and selects an application.
 </p>

 </body>
 </html>
	<html>
	<head>
	<script type="text/javascript" src="http://www.corp.google.com/style/prettify.js"></script>
	<script src="http://www.corp.google.com/eng/techpubs/include/navbar.js" type="text/javascript"></script>
	</head>

	<body>

	<p>High-level classes encapsulating the overall Android application model.
	The central class is {@link android.app.Activity}, with other top-level
	application components being defined by {@link android.app.Service} and,
	from the {@link android.content} package, {@link android.content.BroadcastReceiver}
	and {@link android.content.ContentProvider}. It also includes application
	tools, such as dialogs and notifications.</p>

	<p>This package builds on top of the lower-level Android packages
	{@link android.widget}, {@link android.view}, {@link android.content},
	{@link android.text}, {@link android.graphics}, {@link android.os}, and
	{@link android.util}.</p>

	<p>An {@link android.app.Activity Activity} is a specific operation the
	user can perform, generally corresponding
	to one screen in the user interface.
	It is the basic building block of an Android application.
	Examples of activities are "view the
	list of people," "view the details of a person," "edit information about
	a person," "view an image," etc. Switching from one activity to another
	generally implies adding a new entry on the navigation history; that is,
	going "back" means moving to the previous activity you were doing.</p>

	<p>A set of related activities can be grouped together as a "task". Until
	a new task is explicitly specified, all activites you start are considered
	to be part of the current task. While the only way to navigate between
	individual activities is by going "back" in the history stack, the group
	of activities in a task can be moved in relation to other tasks: for example
	to the front or the back of the history stack. This mechanism can be used
	to present to the user a list of things they have been doing, moving
	between them without disrupting previous work.
	</p>

	<p>A complete "application" is a set of activities that allow the user to do a
	cohesive group of operations -- such as working with contacts, working with a
	calendar, messaging, etc. Though there can be a custom application object
	associated with a set of activities, in many cases this is not needed --
	each activity provides a particular path into one of the various kinds of
	functionality inside of the application, serving as its on self-contained
	"mini application".
	</p>

	<p>This approach allows an application to be broken into pieces, which
	can be reused and replaced in a variety of ways. Consider, for example,
	a "camera application." There are a number of things this application
	must do, each of which is provided by a separate activity: take a picture
	(creating a new image), browse through the existing images, display a
	specific image, etc. If the "contacts application" then wants to let the
	user associate an image with a person, it can simply launch the existing
	"take a picture" or "select an image" activity that is part of the camera
	application and attach the picture it gets back.
	</p>

	<p>Note that there is no hard relationship between tasks the user sees and
	applications the developer writes. A task can be composed of activities from
	multiple applications (such as the contact application using an activity in
	the camera application to get a picture for a person), and multiple active
	tasks may be running for the same application (such as editing e-mail messages
	to two different people). The way tasks are organized is purely a UI policy
	decided by the system; for example, typically a new task is started when the
	user goes to the application launcher and selects an application.
	</p>

	</body>
	</html>