В одной статье на хабре (274635) было продемонстрировано любопытное решение для передачи объекта из onSaveInstanceState в onRestoreInstanceState без сериализации. Там используется метод writeStrongBinder(IBInder) класса android.os.Parcel.

Такое решение корректно функционирует до тех пор, пока Android не выгрузит ваше приложение. А он вправе это сделать.

…system may safely kill its process to reclaim memory for other foreground or visible processes…
(http://developer.android.com/intl/ru/reference/android/app/Activity.html)

Однако это не главное. (Если приложению не нужно восстанавливать свое состояние после такого рестарта, то подойдет и это решение).

А вот цель, для чего там используются такие «несериализуемые» объекты мне показалась странной. Там через них передаются вызовы из асинхронных операций в Activity, чтобы обновить отображаемое состояние приложения.

Я всегда думал, что со времен Smalltalk, любой разработчик распознает эту типовую задачу проектирования. Но кажется я оказался не прав.

Задача

• По команде от пользователя (onClick()) запустить асинхронную операцию
• По завершению операции отобразить результат в Activity

Особенности

• Activity, отображаемая в момент завершения операции, может оказаться
  
  • та же, из которой поступила команда
  • другим экземпляром того же класса (поворот экрана)
  • экземпляром другого класса (пользователь перешел на другой экран в приложении)
  
  
• На момент завершения операции может оказаться, что ни одна Activty из приложения не отображается

В последнем случае результаты должны отображаться при следующем открытии Activity.

Решение

MVC (с активной моделью) и Layers.

Подробное решение

Вся остальная часть статьи — это объяснение что такое MVC и Layers.

Поясню на конкретном примере. Пусть нам необходимо построить приложение «Электронный билет в электронную очередь».

1. Пользователь входит в отделение банка, нажимает в приложении кнопку «Взять билет». Приложение посылает запрос на сервер и получает билет.
2. Когда подходит очередь в приложении отображается номер окошка в которое нужно обратиться.

Получение билета от сервера я сделаю с помощью асинхронной операции. Также асинхронными операциями будут считывание билета из файла (после перезапуска) и удаление файла.

Построить такое приложение можно из несложных компонентов. Например:

1. Компонент где будет находиться билет (TicketSubsystem)
2. TicketActivity где будет отображаться билет и кнопка «Взять билет»
3. Класс для Билета (номер билета, позиция в очереди, номер окошка)
4. Класс для Асинхронной операции получения билета

Самое интересное то, как эти компоненты взаимодействуют.

Приложение вовсе не обязано содержать компонент TicketSubsystem. Билет мог бы находиться
в статическом поле Ticket.currentTicket, или в поле в классе-наследнике android.app.Application.
Однако очень важно, чтобы состояние есть/нет билета исходило из объекта способного выполнять роль
Модель из MVC — т. е. генерировать уведомления при появлении (или замене) билета.

Если сделать TicketSubsystem моделью в терминах MVC, то Activity сможет подписаться на события и обновить отображение билета когда тот будет загружен. В этом случае Activity будет выполнять роль View (Представление) в терминах MVC.

Тогда асинхронная операция «Получение нового билета» сможет просто записать полученный билет в TicketSubsystem и больше ни о чем не заботиться.

Модель

Очевидно, что моделью должен являться билет. Однако в приложении билет не может «висеть» в воздухе. Кроме того, билет изначально не существует, он появляется только по завершению асинхронной операции. Из этого следует, что в приложении должно быть еще что-то где будет находиться билет. Пусть это будет TicketSubsystem. Сам билет также должен быть как-то представлен, пусть это будет класс Ticket. Оба этих класса должны быть способны выполнять роль активной модели.

Способы построения активной модели

Активная модель — модель оповещает представление о том, что в ней произошли изменения. wikipedia

В java есть несколько вспомогательных классов для создания активной модели. Вот например:

1. PropertyChangeSupport и PropertyChangeListener из пакета java.beans
2. Observable и Observer из пакета java.util
3. BaseObservable и Observable.OnPropertyChangedCallback из android.databinding

Мне лично нравится третий способ. Он поддерживает строгое именование наблюдаемых полей, благодаря аннотации android.databinding.Bindable. Но есть и другие способы, и все они подходят.

А в Groovy есть замечательная аннотация groovy.beans.Bindable. Вместе с возможностью краткого объявления свойств объекта получается очень лаконичный код (который опирается на PropertyChangeSupport из java.beans).

@groovy.beans.Bindable
class TicketSubsystem {
    Ticket ticket
}

@groovy.beans.Bindable
class Ticket {
    String number
    int positionInQueue
    String tellerNumber
}

Представление

TicketActivity (как практически все объекты относящиеся к представлению) появляется и исчезает по воле пользователя. Приложение всего лишь должно корректно отображать данные в момент появления Activity и при изменении данных пока отображается Activity.

Итак в TicketActivity нужно:

1. Обновлять UI виджеты при изменении данных в ticket
2. Подключать слушателя к Ticket когда он появится
3. Подключать слушателя к TicketSubsytem (чтобы обновить вид, когда появится ticket)

1. Обновление UI виджетов.

В примерах в статье я буду использовать PropertyChangeListener из java.beans ради демонстрации
подробностей. А в исходном коде по ссылке внизу статьи будет использоваться библиотека android.databinding,
как обеспечивающая самый лаконичный код.

PropertyChangeListener ticketListener = new PropertyChangeListener() {
    @Override
    public void propertyChange(PropertyChangeEvent event) {
        updateTicketView();
    }
};

void updateTicketView() {
    TextView queuePositionView = (TextView) findViewById(R.id.textQueuePosition);
    queuePositionView.setText(ticket != null ? "" + ticket.getQueuePosition() : "");
    ...
}

2. Подключение слушателя к ticket

PropertyChangeListener ticketSubsystemListener = new PropertyChangeListener() {
    @Override
    public void propertyChange(PropertyChangeEvent event) {
        setTicket(ticketSubsystem.getTicket());
    }
};

void setTicket(Ticket newTicket) {
    if(ticket != null) {
        ticket.removePropertyChangeListener(ticketListener);
    }
    ticket = newTicket;
    if(ticket != null) {
        ticket.addPropertyChangeListener(ticketListener);
    }
    updateTicketView();
}

Метод setTicket при замене билета удаляет подписку на события от старого билета и подписывается на события от нового билета. Если вызывать setTicket(null), то TicketActivity отпишется от событий ticket.

3. Подключение слушателя к TicketSubsystem

void setTicketSubsystem(TicketSubsystem newTicketSubsystem) {
    if(ticketSubsystem != null) {
        ticketSubsystem.removePropertyChangeListener(ticketSubsystemListener);
        setTicket(null);
    }
    ticketSubsystem = newTicketSubsystem;
    if(ticketSubsystem != null) {
        ticketSubsystem.addPropertyChangeListener(ticketSubsystemListener);
        setTicket(ticketSubsystem.getTicket());
    }
}

@Override
protected void onPostCreate(@Nullable Bundle savedInstanceState) {
    super.onPostCreate(savedInstanceState);
    setTicketSubsystem(globalTicketSubsystem);
}

@Override
protected void onStop() {
    super.onStop();
    setTicketSubsystem(null);
}

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

Асинхронная операция «Взять билет»

Код асинхронной операции тоже довольно простой. Основная идея в том, чтобы по завершению асинхронной операции записывать результаты в Модель. А Представление обновится по уведомлению из Модели.

public class GetNewTicket extends AsyncTask<Void, Void, Void> {
    private int queuePosition;
    private String ticketNumber;

    @Override
    protected Void doInBackground(Void... params) {
        SystemClock.sleep(TimeUnit.SECONDS.toMillis(2));
        Random random = new Random();
        queuePosition = random.nextInt(100);
        ticketNumber = "A" + queuePosition;

        // TODO записать данные билета в файл, чтобы можно было 
        // его загрузить после перезапуска приложения.

        return null;
    }

    @Override
    protected void onPostExecute(Void aVoid) {
        Ticket ticket = new Ticket();
        ticket.setNumber(ticketNumber);
        ticket.setQueuePosition(queuePosition);
        globalTicketSubsystem.setTicket(ticket);
    }
}

Здесь ссылка globalTicketSubsystem (она также упоминалась в TicketActivity) зависит от способа компоновки подсистем в вашем приложении.

Восстановление состояния при рестарте

Допустим, что пользователь нажал кнопку «Взять билет», приложение послало запрос на сервер, а в это время случился входящий звонок. Пока пользователь отвечал на звонок, пришел ответ от сервера, но пользователь об этом не знает. Мало того, пользователь нажал «Home» и запустил какое-нибудь приложение, которое сожрало всю память и системе пришлось выгрузить наше приложение.

И вот наше приложение должно отобразить билет полученный до рестарта.

Чтобы обеспечить эту функциональность я буду записывать билет в файл и считывать его после старта приложения.

public class ReadTicketFromFileextends AsyncTask<File, Void, Void> {
...
    @Override
    protected Void doInBackground(File... files) {
        // Считываем из файла в number, positionInQueue, tellerNumber
    }

    @Override
    protected void onPostExecute(Void aVoid) {
        Ticket ticket = new Ticket();
        ticket.setNumber(number);
        ticket.setPositionInQueue(positionInQueue);
        ticket.setTellerNumber(tellerNumber);
        globalTicketSubsystem.setTicket(ticket);
    }
}

Layers

Этот шаблон определяет правила по которым одним классам позволяется зависеть от других классов, так чтобы не возникало чрезмерной запутанности кода. Вообще это семейство шаблонов, а я ориентируюсь на вариант Крейга Лармана из книги «Применение UML и шаблонов проектирования». Вот здесь есть диаграмма.

Основная идея в том, что классам с нижних уровней нельзя зависеть от классов с верхних уровней. Если разместить наши классы по уровням Layers, то получится примерно такая диаграмма:

Обратите внимание, что все стрелочки, что пересекают границы уровней, направлены строго вниз! TicketActivity создает GetNewTicket — стрелка вниз. GetNewTicket создает Ticket — стрелка вниз. Анонимный ticketListener реализует интерфейс PropertyChangeListener — стрелка вниз. Ticket оповещает слушателей PropertyChangeListener — стрелка вниз. И т. д.

То есть любые зависимости (наследование, использование в качестве типа члена класса, использование в качестве типа параметра или типа возвращаемого значения, использование в качестве типа локальной переменной) допустимы только к классам на том же уровне или на уровнях ниже.

Еще капельку теории, и перейдем к коду.

Назначение уровней

Объекты на уровне Domains отражают бизнес-сущности с которыми работает приложение. Они должны быть независимы от того как устроено наше приложение. Например наличие поля positionInQueue у Ticket обусловлено бизнес требованиями (а не тем, как мы написали наше приложение).

Уровень Application — это граница того, где может располагаться логика приложения (кроме формирования внешнего вида). Если нужно сделать какую-то полезную работу, то код должен оказаться здесь (или ниже).

Если нужно сделать что-то обладающее внешним видом, то это класс для уровня Presentation. А значит этот класс может содержать только код отображения, и никакой логики. За логикой ему придется обращаться к классам с уровня Application.

Принадлежность класса к определенному уровню Layers — условна. Класс находится на заданном уровне до тех пор пока выполняет его требования. То есть в результате правки класс может перейти на другой уровень, или стать непригодным ни для одного уровня.

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

Эвристика

1. Если приложению удалить Уровень Представления, то оно должно быть в состоянии выполнить все свои функции (кроме демонстрации результатов). Наше приложение без Уровня Представления всё ещё будет содержать и код для запроса билета, и сам билет, и доступ к нему.
2. Если объект какого-то класса что-то отображает, или реагирует на действия пользователя, то его место на Уровне Представления.
3. В случае противоречий — разделяйте класс на несколько.

Код

В репозитории https://github.com/SamSoldatenko/habr3 находится описанное здесь приложение, построенное с применением android.databinding и roboguice. Посмотрите код, а здесь я кратко объясню какой выбор я делал и по каким причинам.

Спасибо