[БЕЗ_ЗВУКА] Привет. В этом видео мы поговорим об основных компонентах 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 и разберем его жизненный цикл. До скорой встречи
