1page.title=Building Blocks 2@jd:body 3<h1>Android Building Blocks</h1> 4 5<p>You can think of an Android application as a collection of components, of 6various kinds. These components are for the most part quite loosely coupled, 7to the degree where you can accurately describe them as a federation of 8components rather than a single cohesive application.</p> 9 10<p>Generally, these components all run in the same system process. It's 11possible (and quite common) to create multiple threads within that process, 12and it's also possible to create completely separate child processes if you 13need to. Such cases are pretty uncommon though, because Android tries very 14hard to make processes transparent to your code.</p> 15 16<p>These are the most important parts of the Android APIs:</p> 17 18<dl> 19 <dt><a href="{@docRoot}devel/bblocks-manifest.html">AndroidManifest.xml</a></dt> 20 <dd>The AndroidManifest.xml file is the control file that tells the system 21 what to do with all the top-level components (specifically activities, 22 services, intent receivers, and content providers described below) 23 you've created. For instance, this is the 24 "glue" that actually specifies which Intents your Activities receive.</dd> 25 26 <dt>{@link android.app.Activity Activities}</dt> 27 <dd>An Activity is, fundamentally, an object that has a life cycle. An 28 Activity is a chunk of code that does some work; if necessary, that work 29 can include displaying a UI to the user. It doesn't have to, though - some 30 Activities never display UIs. Typically, you'll designate one of your 31 application's Activities as the entry point to your application. </dd> 32 33 34 <dt>{@link android.view.View Views}</dt> 35 <dd>A View is an object that knows how to draw itself to the screen. 36 Android user interfaces are comprised of trees of Views. If you want to 37 perform some custom graphical technique (as you might if you're writing a 38 game, or building some unusual new user interface widget) then you'd 39 create a View.</dd> 40 41 42 <dt>{@link android.content.Intent Intents}</dt> 43 <dd>An Intent is a simple message object that represents an "intention" to 44 do something. For example, if your application wants to display a web 45 page, it expresses its "Intent" to view the URI by creating an Intent 46 instance and handing it off to the system. The system locates some other 47 piece of code (in this case, the Browser) that knows how to handle that 48 Intent, and runs it. Intents can also be used to broadcast interesting 49 events (such as a notification) system-wide.</dd> 50 51 52 <dt>{@link android.app.Service Services}</dt> 53 <dd>A Service is a body of code that runs in the background. It can run in 54 its own process, or in the context of another application's process, 55 depending on its needs. Other components "bind" to a Service and invoke 56 methods on it via remote procedure calls. An example of a Service is a 57 media player; even when the user quits the media-selection UI, she 58 probably still intends for her music to keep playing. A Service keeps the 59 music going even when the UI has completed.</dd> 60 61 62 <dt>{@link android.app.NotificationManager Notifications}</dt> 63 <dd>A Notification is a small icon that appears in the status bar. Users 64 can interact with this icon to receive information. The most well-known 65 notifications are SMS messages, call history, and voicemail, but 66 applications can create their own. Notifications are the 67 strongly-preferred mechanism for alerting the user of something that needs 68 their attention.</dd> 69 70 <dt>{@link android.content.ContentProvider ContentProviders}</dt> 71 <dd>A ContentProvider is a data storehouse that provides access to data on 72 the device; the classic example is the ContentProvider that's used to 73 access the user's list of contacts. Your application can access data that 74 other applications have exposed via a ContentProvider, and you can also 75 define your own ContentProviders to expose data of your own.</dd> 76</dl> 77