17 Мая 2017
Операционная система Android предоставляет мощный фундамент для разработки приложений, которые отлично работают на множестве разнообразных устройств и форм-факторов. Теперь, как говорится, мы услышали жалобы разработчиков: трудно создавать "безглючные" приложения в условиях сложных циклов жизни объектов и отсутствия рекомендованной архитектуры приложения.
Нам, создателям Android, надо сделать простым и веселым написание устойчивых приложений, чтобы перевести усилия разработчиков в те области, в которых можно создавать инновации. Сегодня мы аннонсируем путеводитель по архитектуре Android-приложений и превью библиотек Architecture Components. Вместо того чтобы изобретать колесо, мы признаем работу, сделанную авторами популярных сторонних Android-библиотек (прим. пер.: WAT?).
Советы а не предписания
Понятно, что существует много способов создания Android-приложений. Мы хотим предложить набор гайдлайнов, которые могли бы помочь разработать архитектуру приложения, лучше всего соответствующую поведению системы Android. В SDK есть отличные API для взаимодействия с ОС, таких как активити, но это именно точки соприкосновения, а не кирпичики архитектуры; компоненты SDK не требуют отделять модель данных от компонентов UI и не предоставляют нормальных способов хранить данные независимо от жизненного цикла.
Строительные блоки
Architecture Components вместе помогают реализовать разумную архитектуру, хотя по отдельности они решают отдельные "попоболи" разработчиков. Первая версия компонентов помогает:
- Автоматически управлять жизненными циклами активити и фрагментов, чтобы избегать утечек памяти и ресурсов.
- Сохранять Java-объекты модели данных в SQLite.
Компоненты управления жизненным циклом
Новые компоненты предоставляют конструкции для привязки ядра приложения к событиям жизненного цикла, избавляя от явных зависимостей. Типичная модель observer должна стартовать слежение в onStart() и останавливать в onStop(). Это звучит достаточно просто, но часто при этом у вас есть несколько одновременных асинхронных вызовов, и все они обрабатывают жизненные циклы своих компонентов. Можно легко пропустить какой-нибудь граничный случай. И тут могут помочь новые компоненты.
Lifecycle, LifecycleOwner и LifecycleObserver
Основной класс для всего этого — Lifecycle. У него внутре неонка есть ENUM для текущего состояния жизненного цикла, и ENUM для набора событий, и он использует их чтобы отслеживать жизненный цикл связанного с ним компонента.
LifecycleOwner — интерфейс, который возвращает объект Lifecycle при вызове getLifecycle(), а LifecycleObserver — это класс, который может отслеживать события жизненного цикла компонента, если к методам компонента добавить парочку аннотаций. Собрав всё это вместе, мы можем создавать компоненты, которые автоматически отслеживают события жизненного цикла и могут запрашивать текущий lifecycle state.
public class MyObserver implements LifecycleObserver { public MyObserver(Lifecycle lifecycle) { // Starts lifecycle observation lifecycle.addObserver(this); ... } public void startFragmentTransaction() { // Queries lifecycle state if (lifecycle.getState.isAtLeast(STARTED)) { // perform transaction } } // Annotated methods called when the associated lifecycle goes through these events @OnLifecycleEvent(Lifecycle.Event.ON_RESUME) public void onResume() { } @OnLifecycleEvent(Lifecycle.Event.ON_PAUSE) public void onPause() { } } MyObserver observer = new MyObserver(aLifecycleOwner.getLifecycle());
LiveData
LiveData — класс-обертка для данных, отслеживающая жизненный цикл. А еще она умеет в "observable". Ваш UI-код может подписаться на изменения в данных, привязанных к LifecycleOwner, а LiveData убедится, что observer:
- Получает обновления данных пока компонент находится в активном состоянии (
STARTEDилиRESUMED). - Удаляется когда
LifecycleOwnerуничтожается. - Получает актуальные данные когда
LifecycleOwnerрестартует из-за изменения конфигурации или при возврате из back stack.
Это помогает устратить кучу способов получить утечки памяти и снижает вероятность крашей за счет предотвращения отправки событий в остановленные активити.
На LiveData могут подписываться несколько слушателей, каждый из которых завязан на жизненный цикл фрагмента или активити.
ViewModel
ViewModel — вспомогательный класс, который содержит данные пользовательского интерфейса для активности или фрагмента и которые служет для отделения управления данными в интерфейсе от логики контроллера UI. ViewModel сохраняется до тех пор, пока жива область обитания его активити или фрагмента, включая ситуации, когда активити или фрагмент уничтожаются и пересоздаются из-за смены конфигурации. Это позволяет ViewModel делать UI-данные доступными для воссозданных активити или фрагментов без необходимости ручного восстановления. Оборачивание UI-данных, хранящихся во ViewModel, в объект LiveData создает для данных теплый уютный дом с поддержкой жизненного цикла и наблюдателей (observable). LiveData следит за механизмами уведомления об изменениях, а ViewModel следит за тем, чтобы данные сохранялись и восстанавливались в нужное время.
Data Persistence
Architecture Components также упрощают хранение данных с помощью библиотеки Room.
"Комната" предоставляет слой отображения объектов (object-mapping abstracion layer), позволяющий простой доступ к БД наряду со всей мощью SQLite. Android SDK предоставляет встроенную поддержку работы с сырым SQL-контентом. Хотя это мощное API, оно достаточно низкоуровневое и требует много времени и усилий:
- Нет проверки сырых SQL-запросов во время компиляции.
- При изменении схемы данных требуется вручную обновлять затронутые SQL-запросы. Этот процесс может быть длительным и подверженным ошибкам.
- Надо писать кучу шаблонного (boilerplate) кода для конвертации между SQL и Java-объектами модели данных.
Room берет на себя все эти обязанности, предоставляя уровень абстракции над SQLite.
Database, Entity, and DAO
В библиотеке Room есть три основных компонента:
- Entity представляет данные для одной строки БД и создается с использованием аннотированного Java-объекта модели данных. Каждая Entity хранится в своей таблице.
- DAO (Data Access Object) определяет методы, которые обращаются к БД, используя аннотации чтобы привязать SQL к каждому методу.
- Database это хранитель одной базы данных, который использует аннотации для определения списка сущностей и версии БД. Содержимое класса определяет список DAO. Database также является основным способом доступа к находящемуся под капоту коннекту к БД.
Чтобы использовать Room, вам надо аннотировать Java-объекты, которые вы хотите хранить как сущности, создать БД, содержащую эти сущности и определить DAO-класс с SQL-кодом для доступа и изменения таблиц в БД.
@Entity public class User { @PrimaryKey private int uid; private String name; // Getters and Setters - required for Room public int getUid() { return uid; } public String getName() { return name; } public void setUid(int uid) { this.uid = uid; } public void setName(String name) { this.name = name; } } @Dao public interface UserDao { @Query("SELECT * FROM user") List getAll(); @Insert void insertAll(User... users); } @Database(entities = {User.class}, version = 1) public abstract class AppDatabase extends RoomDatabase { public abstract UserDao userDao(); }
Путеводитель по архитектуре приложения
Architecture Components спроектированы для отдельного использования, но наиболее эффективны они тогда, когда они используются в эффективной архитектуре приложения.
Сегодня мы запускаем "Путеводитель по архитектуре приложения", который показывает, как создавать устойчивые, модульные и тестируемые приложения с использованием Architecture Components. Этот гайд служит трем основным целям:
- Определяет принципы, которые подходят при разработке приложений Android.
- Описывает архитектуру приложения, которая работает на этих принципах.
- Показывает как реализовать эту архитектуру с помощью Architecture Components.
Мы рекоммендуем всем разработчикам, которым приходится сталкиваться с этими проблемами, почитать "Путеводитель"; даже если вы счастливы в браке с вашей текущей архитектурой, в "Путеводителе" можно будет найти полезные принципы и советы.
Это только начало
Мы собираемся упрямствовать и продолжать разрабатывать новые части Architecture Components, чтобы облегчить Android-разработчикам процесс осознанного выбора вариантов при разработке архитектуры своих приложений. Мы призываем вас попробовать превью и оставлять отзывы о нашей работе, поскольку мы тут все в одной лодке, чтобы сделать разработку устойчивых приложений проще и веселее. Подробнее о архитектуре Android можно узнать тут:
- https://codelabs.developers.google.com/codelabs/android-lifecycles
- https://codelabs.developers.google.com/codelabs/android-persistence
- https://developer.android.com/topic/libraries/architecture/guide.html
ссылка на оригинал статьи https://habrahabr.ru/post/328962/
Добавить комментарий