Main components Андроид что это за программа

Основной код активности — это Java-файл MainActivity.java. Это фактический файл приложения, который в конечном итоге преобразуется в исполняемый файл Dalvik и запускает ваше приложение. Ниже приведен код по умолчанию, созданный мастером приложений для Hello World! приложение — пакет com.

Какая основная деятельность Android?

Большинство приложений содержат несколько экранов, что означает, что они включают несколько действий. Как правило, одно действие в приложении указывается как основное действие, которое первый экран, который появляется, когда пользователь запускает приложение. Затем каждое действие может запускать другое действие для выполнения различных действий.

Какая польза от XML-файла AndroidManifest?

У каждого проекта приложения должен быть файл AndroidManifest. xml (именно с этим именем) в корне исходного набора проекта. Файл манифеста описывает важную информацию о вашем приложении для инструментов сборки Android, операционной системы Android и Google Play..

Android для начинающих. Урок 2: Структура приложения. Activity и Layout.

Где находится основной файл активности в Android Studio?

Найдите файл MainActivity Java или Kotlin в Android Studio

1. Найдите 1. Проект на верхней левой вертикальной панели.
2. Вы увидите папку: app.
3. Разверните папку приложения -> Вы увидите 3 папки с одинаковым именем, например: com.abc.example.
4. Разверните 1-ю папку -> вы должны увидеть файл MainActivity.
5. Дважды щелкните по нему, чтобы открыть файл.

Какова цель Activity_main XML?

Согласно новому шаблону проектирования в студии android activity_main. xml определит, каким должен быть глобальный пользовательский интерфейс Activity. А с другой стороны content_main. xml определит содержимое файла activity_main.

Зачем вам нужен XML-файл AndroidManifest?

Файл AndroidManifest. xml файл содержит информацию о вашем пакете, включая компоненты приложения, такие как действия, службы, широковещательные приемники, поставщики контента и т. д. отвечает за защиту приложения для доступа к любым защищенным частям, предоставляя разрешения, .

Какая польза от JNI в Android?

JNI — это собственный интерфейс Java. Это определяет способ для байт-кода, который Android компилирует из управляемого кода (написанного на языках программирования Java или Kotlin) для взаимодействия с машинным кодом (написанным на C / C ++).

Как передать намерение?

Самый простой способ сделать это — передать идентификатор сеанса действию выхода из Intent, которое вы используете для запуска действия: Намерение намерение = новое намерение (getBaseContext (), SignoutActivity. класс); намерение. putExtra («EXTRA_SESSION_ID», sessionId); startActivity (намерение);

Как мне найти свое основное приложение для занятий?

Это можно найти в манифест приложения. Основное действие — это действие с фильтром намерений с именем android.

Как размещаются макеты в Android?

Файлы макета хранятся в «Res-> layout» в приложении для Android. Когда мы открываем ресурс приложения, мы находим файлы макета приложения Android. Мы можем создавать макеты в файле XML или в файле Java программно.

Главные компоненты Android приложения за 5 минут

Какова основная цель ViewGroup?

Какова основная цель ViewGroup? В нем собраны наиболее распространенные представления, которые разработчики используют в приложениях для Android. Он служит контейнером для объектов View и отвечает за размещение в нем объектов View. Требуется сделать представление интерактивным, чтобы можно было сгруппировать TextView на экране.

Что такое Android ViewGroup?

ViewGroup — это специальное представление, которое может содержать другие представления. ViewGroup — это базовый класс для макетов в android, например LinearLayout, RelativeLayout, FrameLayout и т. д. Другими словами, ViewGroup обычно используется для определения макета, в котором представления (виджеты) будут установлены / упорядочены / перечислены на экране Android.

Источник: frameboxxindore.com

Что такое компонент Navigation?

Всем известно, что навигация между экранами является одним из фундаментальных принципов в приложениях Android. Как правило, мы осуществляем ее при помощи Intents или Event Bus. Но как быть в сложных ситуациях, например с боковым навигационным меню (navigation drawer) или меню, расположенным внизу (bottom navigation), когда необходимо выделить выбранную вкладку, сохранив отображение панели вкладок и синхронно изменить экран на тот, что соответствует вкладке, не говоря уже об управлении бэкстеком. Для реализации этих задач нам явно потребуется что-то получше.

Компонент Navigation — это комплексное решение всех проблем для любого типа навигации в приложениях Android. Он помогает управлять навигацией, транзакциями фрагментов, бэкстеком, анимацией, глубокими ссылками, а также многим другим. Компонент JetPack Navigation представляет собой набор библиотек и инструментов, сопровождается руководством и обеспечивает продуманную структуру навигации внутри приложения.

Компонент Navigation обеспечивает новый тип навигации в разработке Android, включающей навигационный граф (navigation graph), который позволяет видеть все экраны и пути навигации между ними.

Давайте рассмотрим три главные части компонента Navigation:

1. Навигационный граф. Это ресурс XML, содержащий всю навигационную информацию в одном централизованном месте. Он включает в себя все отдельные области контента в приложении, называемые пунктами назначения (destinations), а также возможные пути навигации по приложению, доступные для пользователя.

2. NavHost. Это пустой контейнер, отображающий пункты назначения из навигационного графа.

3. NavController. Это объект, управляющий навигацией приложения в NavHost. Он координирует смену контента пунктов назначения в NavHost в процессе перемещения пользователя по приложению.

Обратим внимание еще на два понятия, которые мы будем часто использовать:

• Пункты назначения. Это не что иное, как все области контента в приложении, такие как активности (activities), фрагменты (fragments), диалоговые окна и т. д.
• Действия (actions). Они используются для создания навигации, имеющей атрибут destination , в котором можно указать id конечной заставки.

Когда мы осуществляем навигацию по приложению с использованием NavController, то он показывает соответствующий пункт назначения в NavHost.

Компонент Navigation обеспечивает еще ряд полезных возможностей, среди которых:

• упрощенная настройка стандартных шаблонов навигации;
• обработка транзакций фрагментов;
• безопасность типов при передаче информации в процессе навигации;
• обработка анимации переходов;
• централизация и визуализация навигации;
• корректная обработка действий “верх” (Up) и “назад” (Back) по умолчанию;
• предоставление стандартизированных ресурсов для анимации и переходов;
• реализация и обработка глубоких ссылок (deep links).

Итак, мы познакомились с компонентом Navigation и его возможностями. Теперь пора приступить к реализации базового процесса навигации.

Что же у нас в планах?

Мы создадим простое приложение с тремя экранами (главная активность (Main Activity) с тремя фрагментами, имеющими по две кнопки) и установим навигацию между ними.

Требования:

• базовые знания Kotlin;
• Android Studio 3.2 или более новые версии;
• эмулятор или устройство с API 14+.

После создания базового проекта Android добавьте приведенную ниже зависимость в файл сборки верхнего уровня build.gradle.

def nav_version = «2.1.0»dependencies classpath «androidx.navigation:navigation-safe-args-gradle-plugin:$nav_version»
>

Теперь добавьте ниже указанные зависимости в файл build.gradle модуля app. Как только вы это сделали, сразу щелкните Sync now для синхронизации!

apply plugin: «androidx.navigation.safeargs.kotlin»android .
compileOptions sourceCompatibility JavaVersion.VERSION_1_8
targetCompatibility JavaVersion.VERSION_1_8
>kotlinOptions jvmTarget = JavaVersion.VERSION_1_8.toString()
>
>def nav_version = «2.2.2»
dependencies implementation «androidx.navigation:navigation-fragment ktx:$nav_version»
implementation «androidx.navigation:navigation-ui-ktx:$nav_version»
>

Safe Arguments. Safe Args является плагином Gradle, который используется для передачи данных между пунктами назначения. Главное его преимущество состоит в том, что некоторые проверки, происходящие в среде выполнения, теперь будут осуществляться во время компиляции.

Подготовительная работа окончена — продолжаем!

Сначала создадим навигационный граф для нашего приложения.

Как же нам это сделать?

Мы уже выяснили, что навигационный граф — это ресурсный файл со всей навигационной информацией, следовательно создадим этот файл в директории res с ресурсом типа navigation.

Этапы создания навигационного графа:

1. В окне Project щелкните правой кнопкой мыши на директорию res и выберите New > Android Resource File в директории navigation. Если вы ее еще не создали, то пора это сделать.
2. В директории navigation создаем новый файл navigation resource.В нашем примере он получил названиеnavigation,но вы можете назвать его, как пожелаете.
3. Выбираем Navigation в выпадающем списке Resource type и нажимаем OK.

Теперь мы изменим activity_main.xml и заменим , выставленный по умолчанию, на , приведенный ниже:

Выполнив это действие, мы должны увидеть хост (activity_main), добавленный в навигационный граф (в navigation.xml).

Теперь можно добавить новый пункт назначения, щелкнув на опцию ‘Click to add a destination’ (Щелкните, чтобы добавить пункт назначения) в центре навигационного графа. Затем выберите опцию ‘Create new destination’ (Создать новый пункт назначения), вслед за этим откроется диалоговое окно Android New Component, где мы можем создать новый фрагмент.

Для нашего примера создадим два фрагмента, а именно SignupFragment и LoginFragment. После этого щелкнем на один фрагмент и присоединим его к другому. Навигационный граф будет выглядеть следующим образом:

Для выше указанного навигационного графа navigation.xml примет следующий вид:

Здесь корневым тегом будет navigation с атрибутом startDestination , в котором мы укажем id первоначально загружаемого фрагмента, за которым следуют пункты назначения (фрагменты, диалоговые окна и т. д.) с одним из атрибутов name , значение которого будет названием вашего пункта назначения.

Вот мы и подошли к навигации. Будем использовать тег action в конкретном пункте назначения, с которого мы намерены начать навигацию. Также есть атрибут, в котором мы указываем id пункта назначения.

У макета SignupFragment будет две кнопки (Buttons) с id signupBtn и gotoLoginBtn, а также три компонента EditText с id signupUsername, signupPassword и otherInfo.

override fun onViewCreated(view: View, savedInstanceState: Bundle?) super.onViewCreated(view, savedInstanceState)
gotoLoginBtn.setOnClickListener onGotoLogin(it)>private fun onGotoLogin(v: View) val action = SignupFragmentDirections.actionGoToLogin()
Navigation.findNavController(v).navigate(action)
>

Типобезопасная зависимость создаст класс в формате name_of_file_Directions (в нашем случае исходный фрагмент SignupFragmentDirections), состоящий из в файле навигации (navigation).

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

Посмотрим на код XML во вкладке навигации для создания графа по типу указанного выше.

Готово: в вашем приложении реализована базовая навигация. Теперь вы сможете переместиться к LoginFragment.

Освоив базовую реализацию, можем переходить к реализации навигации с аргументами (Navigation With Arguments):

Для этого существуют два возможных способа:

1. Использование объектов bundle.
2. Использование SafeArgs.

Ниже я представлю вам два способа реализации и объясню, почему лучше передавать данные, используя SafeArgs вместо Bundle.

Использование Bundle. Передаем данные из исходного фрагмента, получая навигационный контроллер представления как:

val bundle = bundleOf(«username» to signupUsername.text.toString())
Navigation.findNavController(signupUsername).navigate(R.id.actionGoToMain, bundle)

bundleOf() является методом расширения androidx. Для этого нам нужно добавить ниже указанную зависимость в файл build.gradle модуля app:

implementation ‘androidx.core:core-ktx:1.3.0-rc01’

Получаем данные во фрагменте назначения как:

override fun onViewCreated(view: View, savedInstanceState: Bundle?) super.onViewCreated(view, savedInstanceState)signoutBtn.setOnClickListener onSignout() >
usernameTV.text = «Hello «+ arguments?.getString(«username»)observeViewModel()
>

Вот таким образом мы осуществили передачу данных от одного фрагмента к другому, используя bundle. Однако предчувствую вполне закономерный вопрос с вашей стороны: “Зачем же нам использовать SafeArgs, если мы так легко справились с задачей с помощью выше указанного способа?”.

Конечно, можно передавать данные, используя bundle. Но бывают ситуации, когда мы пытаемся получить данные в пункте назначения, которые никогда не передавались в качестве дополнительных параметров bundle, что вызывает в среде выполнения NullPointerException. Для избежания подобных проблем архитектурные компоненты предоставляют типобезопасный способ.

Как же использовать Safe Arguments для передачи данных?

Так как в нашем проекте есть активный плагин safe args, посмотрим, как его можно использовать.

Сначала укажем аргументы, необходимые для пункта назначения в navigation.xml, как показано ниже:

Мы отправляем данные также из исходного файла как:

super.onViewCreated(view, savedInstanceState)
signupBtn.setOnClickListener onSignup() >
>private fun onSignUp()val action = SignupFragmentDirections.actionGoToMain(signupUsername.text.toString())
Navigation.findNavController(signupUsername).navigate(action)
>

Получаем данные также во фрагменте назначения как:

override fun onViewCreated(view: View, savedInstanceState: Bundle?) super.onViewCreated(view, savedInstanceState)signoutBtn.setOnClickListener onSignout() >
deleteUserBtn.setOnClickListener onDelete() >

usernameTV.text = «Hello «+ MainFragmentArgs.fromBundle(requireArguments()).username>

Типобезопасная зависимость создаст класс в формате name_of_file_Args (в нашем случае фрагмент назначения MainFragmentArgs), который состоит из в файле навигации.

Ура. Двигаемся дальше.

Вы также можете добавлять действия и глубокие ссылки через навигационный граф.

Навигация с Deeplink:

В Android глубокая ссылка означает ссылку, по которой вы переходите непосредственно в конкретный пункт назначения внутри приложения. Для добавления глубокой ссылки щелкните на значок + на панели Argument в секции Deep Link. В диалоговом окне Add deep link (Добавить глубокую ссылку) введите URI.

На этом всё! Пишите код с удовольствием!

С полной информацией о проекте вы можете ознакомиться, пройдя по ссылке на GitHub.

Источник: medium.com

Введение в компоненты архитектуры Android

Tin Megali Last updated Jul 28, 2017

Read Time: 12 min
This post is part of a series called Android Architecture Components.

Android был представлен миру еще в 2005 году, и за эти 12 лет существования платформа достигла удивительного успеха, став самой установливаемой мобильной ОС. За это время было запущено 14 различных версий операционной системы, Android всегда становится более зрелой. Тем не менее, очень важная область платформы по-прежнему игнорировалась: стандартный шаблон архитектуры, способный обрабатывать особенности платформы и достаточно простой, чтобы его мог понять средний разработчик.

Ну, лучше поздно, чем никогда. В последнем Google I/O команда Android, наконец, решила эту проблему и ответила на призывы разработчиков по всему миру, объявив официальную рекомендацию для архитектуры приложений Android и предоставив ее для реализации: новая архитектурные компоненты. Что еще лучше так это то, что им удалось это сделать без ущерба для открытости системы, которую все мы знаем и любим.

В этом уроке мы рассмотрим стандартизованную архитектуру, предложенную командой Android в Google I/O, и рассмотрим основные элементы новых компонентов архитектуры: Lifecycle , ViewModel , LifeData и Room . Мы не будем уделять слишком много внимания коду, вместо этого фокусируясь на концепции и логике этих тем. Мы также рассмотрим некоторые простые фрагменты, все они написаны с использованием Kotlin, изумительного языка, который теперь официально поддерживается Android.

1. Чего не хватало Android?

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

Архитектура приложения

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

Архитектура прикладного программного обеспечения — это процесс определения структурированного решения, отвечающего всем техническим и эксплуатационным требованиям, при одновременной оптимизации общих атрибутов качества, таких как производительность, безопасность и управляемость. Она включает в себя ряд решений, основанных на широком спектре факторов, и каждое из этих решений может оказать значительное влияние на качество, производительность, поддерживаемость и общий успех приложения.

— Руководство по архитектуре и дизайну программного обеспечения Microsoft

Хорошая архитектура учитывает множество факторов, особенно характеристики и ограничения системы. Есть много разных архитектурных решений, все из них со своими плюсами и минусами. Однако некоторые ключевые понятия являются общими для всех видений.

Старые ошибки

До последнего Google I/O система Android не рекомендовала какую-либо конкретную архитектуру для разработки приложений. Это означает, что вы были совершенно свободны в принятии любой модели: MVP, MVC, MVPP или даже отсутствие какого либо шаблона вообще. Кроме того, инфраструктура Android даже не предоставляла собственные решения проблем, создаваемых самой системой, в частности жизненного цикла компонента.

Итак, если вы хотите использовать шаблон Model View Presenter для вашего приложения, вам нужно было придумать свое собственное решение с нуля, написать много шаблонов кода или взять библиотеку без официальной поддержки. И это отсутствие стандартов создало много плохо написанных приложений, с кодовыми базами, которые трудно поддерживать и тестировать.

Как я уже сказал, эта ситуация подвергалась критике годами. На самом деле, я недавно написал об этой проблеме и о том, как ее решить в разделе «Как использовать модель View Presenter для Android». Но важно то, что через 12 лет команда Android наконец решила выслушать наши жалобы и помочь нам в решении этой проблемы.

2. Android-архитектура

В новом руководстве по архитектуре Android определены некоторые ключевые принципы, которые должны соответствовать хорошему Android-приложению, а также оно предлагает безопасный путь для разработчика по созданию хорошего приложения. Однако в руководстве четко указано, что представленный маршрут не является обязательным, и в конечном итоге решение является личным; Разработчик должен решить, какой тип архитектуры он хочет принять.

Согласно руководству, хорошее приложение для Android должно обеспечить четкое разделение обязанностей и управлять пользовательским интерфейсом раздельно от модели. Любой код, который не обрабатывает взаимодействие с пользовательским интерфейсом или операционной системой, не должен находиться в Activity или Fragment, поскольку сохранение их как можно более чистыми позволит вам избежать многих проблем, связанных с жизненным циклом приложения. В конце концов, система может уничтожить действия или фрагменты в любое время. Кроме того, данные должны обрабатываться с помощью моделей, которые изолированы от пользовательского интерфейса и, следовательно, от проблем жизненного цикла.

Новая рекомендуемая архитектура

Архитектура, которую рекомендует Android, не может быть легко отмечена среди стандартных шаблонов, которые мы знаем. Она похожа на шаблон Model View Controller, но она настолько тесно связана с архитектурой системы, что трудно помечать каждый элемент, используя известные соглашения. Однако это не актуально, так как важно, чтобы архитектура основывалась на новых компонентах для создания разделения обязанностей, с хорошей способностью к тестированию и сопровождению. А еще лучше, ее легко реализовать.

Чтобы понять, что предлагает команда Android, мы должны знать все элементы компонентов архитектуры, так как именно они будут делать все тяжелую работу для нас. Есть четыре компонента, каждый из которых имеет определенную роль: Room , ViewModel, LiveData и Lifecycle . У всех этих частей есть свои обязанности, и они работают вместе, чтобы создать прочную архитектуру. Давайте рассмотрим упрощенную схему предлагаемой архитектуры, чтобы лучше понять ее.

Как вы можете видеть, у нас есть три основных элемента, каждый из которых имеет свою ответственность.

1. Activity и фрагмент Fragment собой слой View , который не имеет дело с бизнес-логикой и сложными операциями. Он только настраивает представление, обрабатывает взаимодействие пользователя и, самое главное, наблюдает и демонстрирует элементы LiveData , взятые из ViewModel .
2. ViewModel автоматически отслеживает состояние Lifecycle у представления, сохраняя согласованность во время изменений конфигурации и других событий жизненного цикла Android. Также требуется представление для извлечения данных из Repository , который предоставляется в качестве наблюдаемого LiveData . Важно понимать, что ViewModel никогда не ссылается на View напрямую и что обновления данных всегда выполняются объектом LiveData .
3. Repository не является специальным компонентом Android. Это простой класс без какой-либо конкретной реализации, который отвечает за выборку данных из всех доступных источников, от базы данных до веб-служб. Он обрабатывает все эти данные, как правило, преобразуя их в наблюдаемые LiveData и делая их доступными для ViewModel .
4. База данных Room — это библиотека SQLite, которая облегчает процесс работы с базой данных. Она автоматически записывает кучу готового кода, проверяет ошибки во время компиляции, и, самое главное, она может напрямую возвращать запросы с наблюдаемыми LiveData .

Я уверен, что вы заметили, что мы много говорили о наблюдателях. Шаблон Наблюдатель является одним из базовых для компонентов LiveData и Lifecycle . Этот шаблон позволяет объекту уведомлять список наблюдателей о любых изменениях в его состоянии или данных. Поэтому, когда Activity наблюдает объект LiveData , он будет получать обновления, когда эти данные подвергаются какой-либо модификации.

Еще одна рекомендация для Android состоит в том, чтобы консолидировать свою архитектуру, используя систему Injection Dependency, такую как Dagger 2 от Google, или используя шаблон Service Locator (который проще, чем DI, но без ряда его преимуществ). Мы не будем рассматривать DI или Service Locator в этом уроке, но у Envato Tuts + есть отличные уроки по этим темам. Однако имейте в виду, что есть некоторые особенности работы с Dagger 2 и компонентами Android, которые будут объяснены во второй части этой серии.

Android SDK
Инъекция зависимостей с Dagger 2 на Android
Керри Перес Уанка

3. Компоненты архитектуры

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

Компоненты, связанные с жизненным циклом

У большинства компонентов приложения Android есть привязанные к ним жизненные циклы, которые управляются непосредственно самой системой. До недавнего времени разработчику приходилось следить за состоянием компонентов и действовать соответственно, инициализировать и заканчивать задачи в соответствующее время. Однако было очень легко запутаться и сделать ошибки, связанные с этим типом операции. Но пакет android.arch.lifecycle все это изменил.

Теперь к действиям и фрагментам привязан объект Lifecycle , который можно наблюдать с помощью классов LifecycleObserver , например ViewModel или любого объекта, реализующего этот интерфейс. Это означает, что наблюдатель получит обновления об изменениях состояния объекта, которые он наблюдает, например, когда действие приостановлено или когда оно запущено. Он также может проверять текущее состояние наблюдаемого объекта. Поэтому теперь гораздо проще обрабатывать операции, которые должны учитывать жизненные циклы фреймворка.

На данный момент для создания Activity или Fragment , который соответствует этому новому стандарту, вы должны унаследовать от LifecycleActivity или LifecycleFragment . Однако вполне возможно, что это не всегда будет необходимо, так как команда Android стремится полностью интегрировать эти новые инструменты со своей структурой.

class MainActivity : LifecycleActivity()

Источник: code.tutsplus.com

ПРОграммирование под Android

По существу на http://android-shark.ru это просто очень хороший пересказ оригинальной статьи, хотя некоторые моменты из оригинала не были освещены.

• ОС Андроид это многопользовательская Linux система в которой каждое приложение это отдельный пользователь .
• По умолчанию, система присваивает каждому приложению уникальный идентификатор – Linux User ID. Этот ID используется только системой и не известен приложению .
• Каждое приложение запускается в своем собственном экземпляре виртуальной машины Dalvik, таким образом код каждого приложения изолирован от кода других приложений.
• По умолчанию, каждое приложение запускается в своем собственном Linux процессе. Андроид запускает процесс всегда, когда любому компоненту приложения необходимо быть выполненным и убивает процесс когда в нем больше нет необходимости или когда системе нужны ресурсы для выполнения другого приложения.

• Можно организовать чтобы два приложения использовали один и этот же Linux User ID и таким образом они смогут получить доступ к данным друг друга. Для экономии системных ресурсов приложения с одним и тем же User ID можно запускать в одном Linux процессе и разделять одну и ту же VM ( для этого приложения должны быть подписаны одним и тем же сертификатом ).
• Приложение может запросить разрешение на доступ к устройству и данным таким, как контакты пользователя, SMS-сообщения, SD-карты, камера, Bluetooth и многое другое. Эти разрешения дает непосредственно пользователь, соглашаясь с тем что требует приложение в начале установки. Все эти разрешения определяются в файле AndroidManifest.xml .

Активация компонентов
Еще раз заострим внимание на уникальном свойстве системы Android который заключается в том, что любое приложение может использовать компоненты другого приложения. Например, если вы хотите, чтобы пользователь в вашем приложении сделал фото с помощью камеры устройства, то возможно, есть другое приложение, которое делает это, что и ваше приложение может использовать его функционал, вместо того, чтобы вам самим разрабатывать эту функцию в своем приложении. Вместо этого, вы можете просто запустить компонент в приложение камеры, который делает снимок. Этот компонент сделает фото и вернет его в ваше приложение, так что вы можете использовать это фото в вашем приложении. А для пользователя это будет казаться, как если бы функционал камеры на самом деле является частью вашего приложения.
Когда система запускает компонент приложения, то она запускает процесс данного приложения (если он еще не запущен) и создает классы, необходимые для этого компонента. Например, если ваше приложение запускает Activity приложения камеры, чтобы сделать снимок, то эта Activity, запускается в процессе, который принадлежит приложению камеры, а не процессу вашего приложения . Поэтому, в отличие от приложений на большинстве других систем, приложения для Android не имеют единой точки входа (нет функции main (), например).
Поскольку система запускает каждое приложение в отдельном процессе с правами доступа к файлам, которые ограничивают доступ к этим файлам другим приложениям, приложения не могут непосредственно активировать компонент другого приложения . Однако система Android может. Поэтому, чтобы использовать компонент другого приложения, вы должны сообщить об этом системе Андроид, что у вас есть намерение ( intent ) запустить компонент какого-либо приложения, и система запустит этот компонент для вас.
Три из четырех типов компонент – Activity, Services и Broadcast Receivers активируются через асинхронные сообщения называемые intent (намерение). Интенты (intents) связывают различные компоненты друг с другом в реальном времени (об интентах можно думать как о посланниках, которые запрашивают какое либо действие от компонента) и это безотносительно того, является ли данный компонент частью вашего приложения или другого.
Четвёртый тип компонентов – Content Provider не активируется интентами (intents). Content Provider активируется запросом от ContentResolver .

AndroidManifest.xml

Чтобы система Андроид могла запустить компонент приложения, она должна узнать о его существовании из файла AndroidManifest.xml . Ваше приложение должно объявить все свои компоненты в этом файле, который должен быть в корне каталога каждого проекта .

Кроме этого, напомним еще раз, манифест-файл выполняет другие функции:

• Определяет пользовательские разрешения которые необходимы приложению, такие как доступ в Интернет или чтение контактов.
• Объявление минимального API уровня (версии Android), необходимого для приложения.
• Объявление аппаратных и программных требований, такие как камера, Bluetooth, или мультитач экран.
• API библиотек с которые необходимы приложению, например библиотеки Google Maps.
• и много чего еще

Но все же основная задача манифеста сообщить системе о компонентах приложения. Например, можно объявить Activity (деятельность) следующим образом:

В элементе атрибут Android:icon указывает на ресурсы для иконки приложения.

В элементе атрибут Android:name определяет полный путь на имя класса Activity (деятельности), а атрибут Android:label задаёт заголовок приложения.

• для Activity (деятельности)
• для Service (сервисы)
• для Broadcast reciever (получатели широковещательных сообщений)
• для Content providers (поставщики данных)

Объявление возможностей компонента
Как уже говорилось в разделе «Активация компонентов», для вызова Activity (деятельность), Service (сервис) и Broadcast receiver (получатель широковещательных сообщений) можно использовать класс Intent. Сделать это можно явно, задав конкретное имя компонента, или не явно, а этом случае описывается только тип действия, который нужно выполнить (и, возможно, данные, необходимые для него). Система сама находит компонент устройства, который может выполнить действия и запускает его. Если найдено несколько подходящих компонентов, то пользователь выбирает, какой из них использовать.

Система определяет компоненты, которые могут реагировать на намерение путём сравнения полученного Intent (намерения) от приложеия, с Intent filters (фильтр намерений), определённых в файлах манифеста других приложений.

При объявлении компонента в файле манифеста, можно дополнительно включить фильтр намерений, которые заявляют возможности компонента, чтобы он мог реагировать на запросы из других приложений. Для объявления фильтра намерения используется элемент .

Например, приложение электронной почты с Activity (деятельностью) для создания новых сообщений может объявить Intent filter (фильтр намерения) в своём файле манифеста запускаться на запрос «send» (отправить). Например так (строки 5,6):

Activity (деятельность) в стороннем приложении создаёт Intent (намерение) с типом действия «send» (ACTION_SEND), которое система сопоставит с приложением электронной почты и запустит нужную Activity (деятельность).

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

Например, если приложение требует камеру и использует API, введённые в Android версии 2.1 (API уровень 7), надо записать эти требования в файл манифеста. Например так:

Таким образом, устройства, которые не имеют камеру или с версией Android ниже, чем 2.1 не смогут установить приложение из Google Play.

Однако, приложение может использовать камеру, но но это требование не является критичным для его работы. В этом случае приложение должно выполнять проверку во время выполнения, чтобы отключить функции, использующие камеру.

Ресурсы приложения
Приложения Android состоят не только из исходного кода, но также из ресурсов для визуального представления, такие как изображения или звуковые файлы. Для приложения необходимо определить меню, стили, цвета и разметку пользовательского интерфейса в файлах XML. Использование ресурсов даёт возможность изменять некоторые части приложения без модификации исходного кода, а также позволяет оптимизировать приложение для различных устройств (с различным языком интерфейса или размером экрана).

Для каждого ресурса, включённого в проект Android, SDK определяет уникальный идентификатор (целое число) в файле R.java, которое можно использовать для ссылки на ресурс из кода или из других ресурсов определённых в XML. Например, если приложение содержит изображение с именем logo.png (сохранённое в директории res/drawable), SDK сгенерирует идентификатор ресурса R.drawable.logo, которое можно использовать для ссылки на изображение.

Главным достоинством отдельного хранения исходного кода и ресурсов является возможность создать разные ресурсы для разных аппаратных конфигураций. Например, строки интерфейса для разных языков можно определять в различных xml файлах (они хранятся например в директории res/values-fr/ для французского языка). В зависимости от выбранного пользователем языка система Android подставляет нужные строки в интерфейс.

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

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

Источник: pr0andr0id.blogspot.com