перевод статьи
Application Fundamentals

Application Fundamentals

Обзор
  • Приложения Android состоит из одного или более компонентов приложения (activities, services, content providers, и broadcast receivers)
  • Каждый компонент играет свою собственную роль в общей работе приложения, и может запускаться индивидуально (также и другим приложением)
  • Манифест файл должен декларировать все компоненты приложения, а также объявлять требования к версии программного обеспечения и конфигурации оборудования
  • Ресурсы приложения не содержащие кода (рисунки, строковые данные, файлы компоновки, и т. д.) должны включать альтернативы для различных конфигураций устройств (например различные строковые данные для разных языков или различные файлы компоновки для разных размеров экрана)
В этом документе
  1. Компоненты предложения
    1. Активизация компонентов
  2. Манифест файл
    1. Декларация компонентов
    2. Декларация требований к оборудованию
  3. Ресурсы приложения

Приложения Android пишется языке программирования Java. Инструмент Android SDK компилирует его код вместе со всеми данными и файлами ресурсов в Android package, архивный файл с расширением .apk. Весь код в файле .apk является одним приложением, и этот файл используется устройством Android для установки приложения.

Каждое Android приложение установленное на устройство, живет в своей собственной безопасной "песочнице":

Таким образом, система Android реализует принцип минимальных привилегий. Что значит, что каждое приложение по умолчанию имеет доступ только к компонентам которые требуются для ее работы и не более того. Это создает очень защищенное окружение в котором приложение не имеет доступ к части системы для которой у нее нет разрешения.

Тем не менее, существует возможность для приложения разделять данные с другими приложениями, а также иметь доступ к системным сервисам:

Этим заканчиваются начальные понятия того, каким образом приложение Android существует в системе. Далее в этом документе рассматривается:

Компоненты приложения

Компоненты приложения это неотъемлемая часть Android приложения. Каждый компонент это отдельная точка посредством которой система взаимодействует с приложением. Не все комроненты в действительности являются точками взоимодействия с пользователем, но каждая из них существует как сущность и играет специфическую роль - каждый из них - это унниикльный строительный блок который помогает определить общее поведение приложения.

Существует 4 различных вида компонентов. Каждый вид служит разным целям и имеет розличный цикл жизни который определяет кокой компонент создается или разрушоется.There are four different types of application components. Each type serves a distinct purpos nd has a distinct lifecycle that defines how the component is created and destroyed.

Здесь представлены 4 типа компонента приложения:

Activities
Activity представляет собой один единственный экран с пользовательским интерфейсом. Например, почтовое приоложение может иметь одно Activity которое показывает список писем, второе для составления письма и третье для чтения. Тем не менее, все они работают вместе, формируя единое пользовательское впечатление о приложении. Каждое независимо от другого. По существу, какое либо другое приложение может запустить одно из этих (если почтовое приложение допускает это). Например, приложение для съемки видео может запустить в почтовом приложении которое создает письмо для отправки какого либо снимка.

Activity реализовано как подклассis Activity и более подробно читайте на гиде разработчика Activities.

Services
Service компонент который работает в фоновом режиме и реализует длительные операции или выполняют работу для удаленного процесса. Он не представляет пользовательский интерфейс. Service например, может проигрывать музыку в фоновом режиме пока пользователь находится в другом приложении, или может отсылать данные по сети без взаимодействия с пользователем. Другой компонент, такой например, как Activity, может запустить Service и позволить ему выполняться или связаться с ним для взаимодействия.

Service реализован как подкласс Service и более подробно о нем вы можете узнать на Services.

Content providers
Сontent provider управляет разделяемым набором данных приложения. Вы можете хранить данные в файловой системе, базе данных SQLlite, web пространстве или в любом другом месте куда ваше приложение имеет доступ. Посредством этого компонента, другое приложение может запрашивать и даже модифицировать эти данные (если Сontent provider позволяет это). Например, система Android представляет Сontent provider который управляет информацией о контактах пользователя. И, таким образом любое приложение с соответствующими правами может запросить часть Сontent provider (такую как ContactsContract.Data) предоставить информацию о конкретном человеке.

Сontent provider также полезен при чтении и записи данных, которые являются конфиденциальными данными вашего приложения. Например, Note Pad простое приложение использующее Сontent provider для сохранения записей.

Сontent provider реализован как подкласс ContentProvider и должен реализовывать стандартный набор API который делает возможным для другого приложения выполнять транзакции. Более подробно смотрите на Content Providers.

Broadcast receivers
Broadcast receiver это компонент который отвечает за извещение о общее системных событиях. Много событий происходят в самой системе, например, выключение экрана или захват изображения камерой. Приложение также может инициировать извещение о событии, для того например, чтобы позволить другому приложению узнать, что какие-то данные скачаны на устройство и могут быть использованы. Тем не менее, Broadcast receiver не представляют на экране какого-либо пользовательского интерфейса, но могут создавать status bar notification, чтобы информировать пользователя о произошедшем событии. Вообще говоря, Broadcast receiver подобен шлюзу другого компонента и предполагается, что он делает минимум работы.

Broadcast receiver реализован как подкласс BroadcastReceiver и поставляется как Intent объект.Более подробно смотрите на BroadcastReceiver

Уникальным аспектом системы Android является то, что любое приложение может запустить компонент другого. Например, если вы хотите получить фотографию с камеры устройства, существует вероятно какое либо другое приложение которое может это делать и ваше приложение может использовать эту особенность, а не разработывать свой собственный компнент для этого. Вы не должны вводить новый код для этого, или связывать код своего приложения с кодом другого. Вместо этого вы просто запускаете Activity другого компонента, который производит захват изображения. После окончания, изображение передается вашему приложению для использования. Пользователю при этом, кожется, что все это происходит в одном приложении.

Когда система запускает компонент, она запускает процесс для этого приложения(если он еще не запущен) и создает классы необходимые для этого компонента. Например, если ваше приложение зарускает активити прирадлежащее приложению фотокамеры для захвата фото, то это Activity выполняется в процессе который принадлежит приложению камеры, а не процессу вашего приложения. Таким образом, в отличии от других систем, приложение Andriod не имеет только одну точку входа (у него нет метода main, например).

Так как система выполняет каждое приложение в отдельном процессе с определенными правами доступа к файлам, это огранмчивает доступ к другим приложениям, ваше приложение не может на прямую активировать компонент другого приложения. Системк Android может это делать. Так, для актрвации компонента другого приложения вы должны передать сообщение системе спицифицирующий ваш Intent объект для запуска определенного компонента, после чего, система запстит его для вас.

Activating Components

Три из четырех типов компонентов—activities, services, и broadcast receivers—активируются асинхронным вызовом называемым intent. Intents связывает индивидуальный компонент с любым другим во время выполнения (you can think of the s the messengers that request an action from other components), не зависимо от того, принадлежит комронент этому приложению или другому.

An intent is created with an Intent object, which defines a message t ctivate either a specific component or a specific type of component—an inten an be either explicit or implicit, respectively.

For activities and services, an intent defines the action to perform (for example, to "view" or "send" something) and may specify the URI of the data to act on (among other things that th omponent being started might need to know). For example, an intent might convey a request for a ctivity to show an image or to open a web page. In some cases, you can start a ctivity to receive a result, in which case, the activity also return he result in an Intent (for example, you can issue an intent to le he user pick a personal contact and have it returned to you—the return intent includes a URI pointing to the chosen contact).

For broadcast receivers, the intent simply defines th nnouncement being broadcast (for example, a broadcast to indicate the device battery is lo ncludes only a known action string that indicates "battery is low").

The other component type, content provider, is not activated by intents. Rather, it i ctivated when targeted by a request from a ContentResolver. The conten esolver handles all direct transactions with the content provider so that the component that' erforming transactions with the provider doesn't need to and instead calls methods on the ContentResolver object. This leaves a layer of abstraction between the conten rovider and the component requesting information (for security).

There are separate methods for activiting each type of component:

For more information about using intents, see the < ref="/guide/topics/intents/intents-filters.html">Intents and Intent Filters document. More information about activating specific components is also provide n the following documents: < ref="/guide/topics/fundamentals/activities.html">Activities, < ref="/guide/topics/fundamentals/services.html">Services, BroadcastReceiver and < ref="/guide/topics/providers/content-providers.html">Content Providers.

The Manifest File

Before the Android system can start an application component, the system must know that th omponent exists by reading the application's AndroidManifest.xml file (the "manifest" file). Your application must declare all its components in this file, which must be at the root o he application project directory.

The manifest does a number of things in addition to declaring the application's components, such as:

Declaring components

The primary task of the manifest is to inform the system about the application's components. Fo xample, a manifest file can declare an activity as follows:

 


    
        
        
        ...
    

In the < ref="/guide/topics/manifest/application-element.html"> element, the android:icon attribute points to resources for an icon that identifies th pplication.

In the < ref="/guide/topics/manifest/activity-element.html"> element, the android:name attribute specifies the fully qualified class name of the Activity subclass and the android:label attributes specifies a strin o use as the user-visible label for the activity.

You must declare all application components this way:

Activities, services, and content providers that you include in your source but do not declar n the manifest are not visible to the system and, consequently, can never run. However, broadcas eceivers can be either declared in the manifest or created dynamically in code (as BroadcastReceiver objects) and registered with the system by calling registerReceiver().

For more about how to structure the manifest file for your application, see the < ref="/guide/topics/manifest/manifest-intro.html">The AndroidManifest.xml File documentation.

Declaring component capabilities

As discussed above, in Activating Components, you can use an Intent to start activities, services, and broadcast receivers. You can do s y explicitly naming the target component (using the component class name) in the intent. However, the real power of intents lies in the concept of intent actions. With intent actions, you simpl escribe the type of action you want to perform (and optionally, the data upon which you’d like t erform the action) and allow the system to find a component on the device that can perform th ction and start it. If there are multiple components that can perform the action described by th ntent, then the user selects which one to use.

The way the system identifies the components that can respond to an intent is by comparing th ntent received to the intent filters provided in the manifest file of other applications o he device.

When you declare a component in your application's manifest, you can optionally includ ntent filters that declare the capabilities of the component so it can respond to intent rom other applications. You can declare an intent filter for your component b dding an element as a child of the component's declaration element.

For example, an email application with an activity for composing a new email might declare a ntent filter in its manifest entry to respond to "send" intents (in order to send email). A ctivity in your application can then create an intent with the “send” action (ACTION_SEND), which the system matches to the email application’s “send” activity and launches it when you invoke the intent with startActivity().

For more about creating intent filters, see the < ref="/guide/topics/intents/intents-filters.html">Intents and Intent Filters document.

Declaring application requirements

There are a variety of devices powered by Android and not all of them provide th ame features and capabilities. In order to prevent your application from being installed on device hat lack features needed by your application, it's important that you clearly define a profile fo he types of devices your application supports by declaring device and software requirements in you anifest file. Most of these declarations are informational only and the system does not rea hem, but external services such as Android Market do read them in order to provide filterin or users when they search for applications from their device.

For example, if your application requires a camera and uses APIs introduced in Android 2.1 (< ref="/guide/appendix/api-levels.html">API Level 7), you should declare these a equirements in your manifest file. That way, devices that do not have a camera and have an Android version lower than 2.1 cannot install your application from Android Market.

However, you can also declare that your applicaiton uses the camera, but does not require it. In that case, your application must perform a check at runtime to determin f the device has a camera and disable any features that use the camera if one is not available.

Here are some of the important device characteristics that you should consider as you design an evelop your application:

Screen size and density
In order to categorize devices by their screen type, Android defines two characteristics fo ach device: screen size (the physical dimensions of the screen) and screen density (the physica ensity of the pixels on the screen, or dpi—dots per inch). To simplify all the differen ypes of screen configurations, the Android system generalizes them into select groups that mak hem easier to target.

The screen sizes are: small, normal, large, and extra large.
The screen densities are: low density, medium density, high density, and extra high density.

By default, your application is compatible with all screen sizes and densities, because the Android system makes the appropriate adjustments to your UI layout and imag esources. However, you should create specialized layouts for certain screen sizes and provid pecialized images for certain densities, using alternative layout resources, and by declaring i our manifest exactly which screen sizes your application supports with the < ref="/guide/topics/manifest/supports-screens-element.html"> element.

For more information, see the < ref="/guide/practices/screens_support.html">Supporting Multiple Screens document.

Input configurations
Many devices provide a different type of user input mechanism, such as a hardware keyboard, rackball, or a five-way navigation pad. If your application requires a particular kind of inpu ardware, then you should declare it in your manifest with the < ref="/guide/topics/manifest/uses-configuration-element.html"> element. However, it is rare that an application should requir certain input configuration.
Device features
There are many hardware and software features that may or may not exist on a given Android-powered device, such as a camera, a light sensor, bluetooth, a certai ersion of OpenGL, or the fidelity of the touchscreen. You should never assume that a certai eature is available on all Android-powered devices (other than the availability of the standard Android library), so you should declare any features used by your application with the < ref="/guide/topics/manifest/uses-feature-element.html"> element.
Platform Version
Different Android-powered devices often run different versions of the Android platform, such as Android 1.6 or Android 2.3. Each successive version often includes additional APIs no vailable in the previous version. In order to indicate which set of APIs are available, eac latform version specifies an < ref="/guide/appendix/api-levels.html">API Level (for example, Android 1.0 is API Level 1 and Android 2.3 is API Level 9). If you use any APIs that were added to the platform afte ersion 1.0, you should declare the minimum API Level in which those APIs were introduced using the element.

It's important that you declare all such requirements for your application, because, when yo istribute your application on Android Market, Market uses these declarations to filter whic pplications are available on each device. As such, your application should be available only t evices that meet all your application requirements.

For more information about how Android Market filters applications based on these (and other) requirements, see the Market Filters document.

Application Resources

An Android application is composed of more than just code—it requires resources that ar eparate from the source code, such as images, audio files, and anything relating to the visua resentation of the application. For example, you should define animations, menus, styles, colors, and the layout of activity user interfaces with XML files. Using application resources makes it eas o update various characteristics of your application without modifying code and—by providin ets of alternative resources—enables you to optimize your application for a variety o evice configurations (such as different languages and screen sizes).

For every resource that you include in your Android project, the SDK build tools define a uniqu nteger ID, which you can use to reference the resource from your application code or fro ther resources defined in XML. For example, if your application contains an image file named logo.png (saved in the res/drawable/ directory), the SDK tools generate a resource ID named R.drawable.logo, which you can use to reference the image and insert it in you ser interface.

One of the most important aspects of providing resources separate from your source cod s the ability for you to provide alternative resources for different devic onfigurations. For example, by defining UI strings in XML, you can translate the strings into othe anguages and save those strings in separate files. Then, based on a language qualifier that you append to the resource directory's name (such as res/values-fr/ for French strin alues) and the user's language setting, the Android system applies the appropriate language string o your UI.

Android supports many different qualifiers for your alternative resources. Th ualifier is a short string that you include in the name of your resource directories in order t efine the device configuration for which those resources should be used. As anothe xample, you should often create different layouts for your activities, depending on th evice's screen orientation and size. For example, when the device screen is in portrai rientation (tall), you might want a layout with buttons to be vertical, but when the screen is i andscape orientation (wide), the buttons should be aligned horizontally. To change the layou epending on the orientation, you can define two different layouts and apply the appropriat ualifier to each layout's directory name. Then, the system automatically applies the appropriat ayout depending on the current device orientation.

For more about the different kinds of resources you can include in your application and ho o create alternative resources for various device configurations, see the < ref="/guide/topics/resources/index.html">Application Resources developer guide.

аяАЯ