Android architecture components dependencies java

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

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, которые будут объяснены во второй части этой серии.

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

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

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

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

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

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

LifecycleObserver получает события Lifecycle и может реагировать через аннотацию. Не требуется переопределение метода.

Компонент LiveData

Компонент LiveData является держателем данных, который содержит значение, которое можно наблюдаться. Учитывая, что наблюдатель предоставил Lifecycle во время создания LiveData , LiveData будет вести себя в соответствии с состоянием Lifecycle . Если состояние Lifecycle наблюдателя STARTED или RESUMED , наблюдатель active ; В противном случае он inactive .

LiveData знает, когда данные были изменены, а также когда наблюдатель active и должен получать обновление. Еще одна интересная характеристика LiveData заключается в том, что она способна удалять наблюдателя, если он находится в состоянии Lifecycle.State.DESTROYED , избегая утечек памяти при наблюдении за действиями и фрагментами.

LiveData должен реализовывать методы onActive и onInactive .

Чтобы наблюдать компонент LiveData , вы должны вызвать observer(LifecycleOwner, Observer ) .

Компонент ViewModel

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

Чтобы создать модель представления, отнаследуйтесь от класса ViewModel .

Чтобы получить доступ из представления, вы можете вызвать ViewProviders.of(Activity | Fragment).get (ViewModel::class) . Этот фабричный метод вернет новый экземпляр ViewModel или при необходимости сохранит его.

Room компонент

Android с самого начала поддерживает SQLite; Однако, чтобы заставить его работать, всегда приходилось писать много начального кода. Кроме того, SQLite не сохранял POJO (простые старые объекты Java) и не выполнял запросы во время компиляции. Room пришел чтобы решить эти проблемы! Это библиотека сопоставления SQLite, способная сохранять Java POJO, напрямую конвертировать запросы в объекты, проверять ошибки во время компиляции и получать данные LiveData из результатов запроса. Room представляет собой библиотеку реляционных объектов с некоторыми классными дополнениями для Android.

До сих пор вы могли бы сделать большую часть того, что может Room , используя другие ORM библиотеки Android. Однако ни одна из них официально не поддерживается и, самое главное, они не могут возвращать результаты в виде LifeData . Библиотека Room идеально подходит как слой хранения данных предлагаемой архитектуры Android.

Чтобы создать базу данных Room , вам понадобится @Entity , которая может быть любым Java POJO, интерфейс @Dao для создания запросов и операций ввода-вывода, а также абстрактный классом @Database , который должен расширять RoomDatabase .

Добавление компонентов архитектуры в ваш проект

На данный момент для использования новых компонентов архитектуры вам необходимо сначала добавить репозиторий Google в файл build.gradle . Для получения дополнительной информации см. Официальное руководство.

Заключение

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

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

Источник