Операционная система 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