Как разделить Android Activity или фрагменты и состояние приложения?

Интересная штучка, я в одном из проектов тоже в итоге к машине состояний пришёл, только к самописной. Потенциал переиспользования в новых проектах у неё довольно слабый, но зато проблемы с инкапсуляцией кода, относящегося к различным состояниям UI, она решает отлично.

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

Нет, возможности показать пример кода нет.

Владимир Якушев: Есть такая MVP библиотека - Mosby. Там есть понятие ViewState. Смысл в том, чтобы в ViewState хранить состояние View, а presenter занимался бы только бизнес логикой. hannesdorfmann.com/mosby/viewstate Я так понимаю что ViewState это и есть стэйт машина?

Стейт-машина - это другой термин для конечных автоматов: есть состояние как вершины графа, и есть события как пути между графами. В данной библиотеке ViewState похож на стейт-машину, но реализован на очень низком уровне: для каждого вью придется создавать отдельный класс со своим списком состояний и переходов, которые обрабатываются методом с кучей if-ов.
Это не идёт ни в какое сравнение с ООП реализацией из той библиотеки, про которую писал я. Самый огромный плюс этой библиотеки в том, что переходы описываются очень наглядно и в одном месте:

from(SHOWING_WELCOME).transit(
on(cardPresent).to(WAITING_FOR_PIN).transit(
on(pinProvided).to(...).transit(
...
),
on(cancel).to(RETURNING_CARD).transit(
on(cardExtracted).to(SHOWING_WELCOME)
)
)
);

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

Но данный ViewState может быть уместным в рамках данного вопроса, как обработчик состояния одной единственной активити или фрагмента. Но опять же отсутствие ООП в описании состояний может породить ужасный список условий, если мы будем иметь более-менее сложное поведение.

Поясню немного код, который вставил: если мы находимся в состоянии SHOWING_WELCOME, то при поступлении события cardPresent надо перейти в состояние WAITING_FOR_PIN, если пришло событие cancel, то переходим в состояние RETURNING_CARD. Если мы в состоянии WAITING_FOR_PIN, то при поступлении события pinProvided переходим к .... . Если мы в состоянии RETURNING_CARD и пришло событие cardExtracted, то возвращаемся к SHOWING_WELCOME.

Пример с гитхаба, с данной либой, не работает ((

cry_san: что именно не работает?

https://github.com/Beh01der/EasyFlow-example-AtmEm...

cry_san: в Readme.md самой либы дан достаточно хороший пример работы. А в том примере используется старая либа, и пример уже не актуален.

Тогда понятно. Попробую. Спасибо!