[БЕЗ_ЗВУКА] Привет.
В этом видео мы поговорим об основных компонентах Android-приложения.
Вообще, что сам по себе представляет Android с точки зрения разработчика?
Android — это framework, то есть глобальная библиотека,
которая берет на себя всю грязную работу, например, связанную с управлением памятью,
процессами, приложениями, датчиками и тому подобное.
Framework предоставляет нам несколько компонентов,
наследуя и изменяя которые, мы строим свое приложение.
Всего таких компонентов пять.
Это у нас Application, Activity, Service, BroadcastReceiver и ContentProvider.
Давайте скажем пару слов об этих компонентах,
а более подробно о каждом из них мы поговорим в последующих видео.
Первым идет Application.
Application — это компонент,
который первым загружается при начале работы с приложением и умирает последним.
Он представляет собой singleton, то есть единственный экземпляр своего класса.
Реализация Application необязательна, но если вам нужна глобальная точка доступа к
переменными либо методам, то Application — вполне подходящий вариант.
Для того, чтобы система знала о вашем Application,
необходимо указать его класс в манифесте, в node Application через tagname,
иначе будет использоваться стандартная реализация.
Activity.
Activity — это основной компонент,
с помощью которого пользователь взаимодействует с приложением.
Сильно упрощая, скажу, что Activity представляет собой какой-либо экран
приложения, логику в Java-коде и интерфейс в XML-верстке.
Все Activity должны наследоваться от базового класса Activity,
а в методах должны обязательно вызываться методы родителя.
Activity, как и другие компоненты из списка, должны обязательно указываться в
манифесте, чтобы система знала о нем и могла запустить.
Service.
Service, или Сервис, — это компонент, главное предназначение которого
выполнять долгие операции, которые не требуют взаимодействия с интерфейсом.
К примеру, если вы слушаете музыку и она продолжает играть, даже если вы свернули
приложение и открыли другое приложение, то значит, музыка играет в фоновом сервисе.
BroadcastReceiver.
BroadcastReceiver, как понятно из названия, — это приемник широковещательных
сообщений, посылаемых системой, другими приложениями либо вашим приложением,
и каким-либо образом реагирующий на них.
Естественно, вы сами определяете, на что и как будет реагировать ваш приемник.
К примеру, вы можете создать приемник, подписанный на включение устройства,
а реакция будет в виде запроса на сервер с обновлением данных.
К слову, все мессенджеры работают подобным образом.
Уверен, вы замечали.
Отдельно от вышеперечисленных элементов стоит ContentProvider.
ContentProvider — это мощный компонент,
представляющий собой программный интерфейс,
который позволяет нескольким приложениям пользоваться одним источником данных.
Продолжая тему мессенджеров, приведу пример.
Любой более-менее серьезный мессенджер имеет доступ к телефонной книге,
с которой он считывает номера или добавляет новые контакты.
Или, например, банковское приложение также позволяет переводить средства по
номеру телефона, сравнивая номера из списка контактов и своей базе.
Подобных примеров множество, и они не ограничиваются только телефонной книгой.
Работа с ContentProvider сложна, и мы рассмотрим его на следующем курсе.
Повторюсь, что все эти компоненты должны быть обязательно прописаны в манифесте.
А теперь я хотел бы поговорить о классе,
который так или иначе присутствует во всех этих компонентах.
Это так называемый Context.
Context — это абстрактный класс, за реализацию которого отвечает сам Android.
Например, Activity — это одна из таких реализаций,
так как Activity является потомком Context.
Зачем нам вообще нужен Context?
Наиболее частый случай использования — это доступ к ресурсам приложения,
будь то строки, цвета, меню, цифровые константы или RAW-файлы,
не поддающиеся классификации.
Через Context также осуществляется доступ к системным возможностям телефона,
например, к сканеру отпечатков пальцев, будильнику,
акселерометру или другим возможностям.
Также иногда может возникнуть ситуация,
в которой вы не знаете до запуска приложения, как будет выглядеть интерфейс.
Предположим, что интерфейс зависит от того, что придет с сервера.
Тогда для создания элементов интерфейса прямо в коде обязательно нужно передавать
в конструктор этого элемента текущий контекст.
Еще одна возможность контекста — это создание файлов,
хранящихся на устройстве и используемых приложением.
К примеру, база данных, скачанные файлы, сделанные фотоснимки или файлы
preferences, в которых хранятся настройки приложения.
Как видите, класс довольно важный.
Но, конечно же, следует помнить,
что напрямую с контекстом обычно никто не работает.
Все происходит через его реализации.
Эти реализации достаточно сильно отличаются друг от друга.
Давайте рассмотрим парочку моментов.
К примеру, Context, который реализован в Application, как и сам Application,
является singleton.
При создании своих собственных singleton, которым необходим Context для работы,
следует использовать именно Context Application.
Напротив, Context, реализованные в Activity или Service,
у каждого экземпляра свои.
Логично, что такой Context живет столько, сколько живет Activity или Service.
Поэтому хранить ссылки на них — не самая лучшая затея.
В крайнем случае можно воспользоваться WeakReference,
чтобы сборщик мусора мог утилизировать объект контекста и освободить ресурсы.
На этом на сегодня все.
Мы рассмотрели с вами основные компоненты Android,
а также поговорили о важном классе контекста.
Ссылки на дополнительные ресурсы находятся внизу видео.
Рекомендую ознакомиться с ними,
чтобы узнать побольше о различиях разных контекстов.
В следующем видео мы подробнее поговорим об Activity и разберем его жизненный цикл.
До скорой встречи
