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


Чтобы использовать 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 можно узнать тут:


Будете ли вы использовать гугло-велосипед для Lifecycle Management?

Проголосовало 109 человек. Воздержалось 46 человек.

Будете ли вы использовать гугло-велосипед для Data Persistance?

Проголосовало 119 человек. Воздержалось 42 человека.

Только зарегистрированные пользователи могут участвовать в опросе. Войдите, пожалуйста.

Поделиться с друзьями
-->

Комментарии (2)


  1. forceLain
    18.05.2017 11:53
    +2

    Попробовать то обязательно стоит, может взлетит. Но если посмотреть их мастер-классы и доклады на предыдущих I/O, то можно заметить примерно такое:
    — ребята, используйте AsyncTask
    — а не, удобнее использовать пустой Fragment с setRetainInstance(true)
    — короче, используйте фоновый сервис и ServiceConnection/ResultReceiver
    — погодите, мы вам Loader и LoaderManager запилили
    — всё фигня, теперь у вас есть JobScheduler!

    Хотя, возможно, я утрирую. В любом случае «MVVM» + Data Binding должны хорошо дополнить друг друга.


    1. tumbler
      18.05.2017 12:05

      Недавно они объявили устаревшим свой тулчейн Jack, впиленный в 2014 году. Так что скорее всего приведенный диалог будет справедлив и для Room/Lifecycle, но узнаем мы об этом года через 3.