- Home Startseite ホーム 主页 首頁
- SDK
- Dev Guide Handbuch Guía Guide Guida 開発ガイド 开发人员指南 開發指南
- Reference Referenz Referencia Référence Riferimento リファレンス 参考 參考資料
- Resources
- Videos ビデオ
- Blog ブログ 博客 網誌

Android.com

# Building Blocks

# Android Building Blocks

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.

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.

These are the most important parts of the Android APIs:

AndroidManifest.xml
  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.
`Activities`
  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.
`Views`
  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.
`Intents`
  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.
`Services`
  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.
`Notifications`
  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.
`ContentProviders`
  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.

↑ Go to top