blob: b8a609e1fcedb458c674347e14da6db7d3ba7b86 [file] [log] [blame]
page.title=Building Blocks
@jd:body
<h1>Android Building Blocks</h1>
<p>You can think of an Android application as a collection of components, of
various kinds. These components are for the most part quite loosely coupled,
to the degree where you can accurately describe them as a federation of
components rather than a single cohesive application.</p>
<p>Generally, these components all run in the same system process. It's
possible (and quite common) to create multiple threads within that process,
and it's also possible to create completely separate child processes if you
need to. Such cases are pretty uncommon though, because Android tries very
hard to make processes transparent to your code.</p>
<p>These are the most important parts of the Android APIs:</p>
<dl>
<dt><a href="{@docRoot}devel/bblocks-manifest.html">AndroidManifest.xml</a></dt>
<dd>The AndroidManifest.xml file is the control file that tells the system
what to do with all the top-level components (specifically activities,
services, intent receivers, and content providers described below)
you've created. For instance, this is the
"glue" that actually specifies which Intents your Activities receive.</dd>
<dt>{@link android.app.Activity Activities}</dt>
<dd>An Activity is, fundamentally, an object that has a life cycle. An
Activity is a chunk of code that does some work; if necessary, that work
can include displaying a UI to the user. It doesn't have to, though - some
Activities never display UIs. Typically, you'll designate one of your
application's Activities as the entry point to your application. </dd>
<dt>{@link android.view.View Views}</dt>
<dd>A View is an object that knows how to draw itself to the screen.
Android user interfaces are comprised of trees of Views. If you want to
perform some custom graphical technique (as you might if you're writing a
game, or building some unusual new user interface widget) then you'd
create a View.</dd>
<dt>{@link android.content.Intent Intents}</dt>
<dd>An Intent is a simple message object that represents an "intention" to
do something. For example, if your application wants to display a web
page, it expresses its "Intent" to view the URI by creating an Intent
instance and handing it off to the system. The system locates some other
piece of code (in this case, the Browser) that knows how to handle that
Intent, and runs it. Intents can also be used to broadcast interesting
events (such as a notification) system-wide.</dd>
<dt>{@link android.app.Service Services}</dt>
<dd>A Service is a body of code that runs in the background. It can run in
its own process, or in the context of another application's process,
depending on its needs. Other components "bind" to a Service and invoke
methods on it via remote procedure calls. An example of a Service is a
media player; even when the user quits the media-selection UI, she
probably still intends for her music to keep playing. A Service keeps the
music going even when the UI has completed.</dd>
<dt>{@link android.app.NotificationManager Notifications}</dt>
<dd>A Notification is a small icon that appears in the status bar. Users
can interact with this icon to receive information. The most well-known
notifications are SMS messages, call history, and voicemail, but
applications can create their own. Notifications are the
strongly-preferred mechanism for alerting the user of something that needs
their attention.</dd>
<dt>{@link android.content.ContentProvider ContentProviders}</dt>
<dd>A ContentProvider is a data storehouse that provides access to data on
the device; the classic example is the ContentProvider that's used to
access the user's list of contacts. Your application can access data that
other applications have exposed via a ContentProvider, and you can also
define your own ContentProviders to expose data of your own.</dd>
</dl>