Знаете ли вы полную аббревиатуру state machine
Что проверяют
Формально это вопрос на эрудицию: state machine обычно сокращают как FSM, finite state machine, по-русски конечный автомат. На деле интервьюеру интереснее, умеете ли вы применять идею в Android-коде, поэтому следом почти всегда просят описать состояния какого-нибудь экрана и переходы между ними.
Как отвечать
Сначала коротко про определение. Конечный автомат задаётся конечным набором состояний, набором событий и функцией переходов: из состояния A по событию E система попадает в состояние B. В каждый момент состояние ровно одно, а недопустимые переходы просто не описаны. Можно упомянуть разновидности: у автомата Мура выход зависит только от состояния, у автомата Мили ещё и от входного события.
Потом переходите к Android:
- состояние экрана:
sealed interface UiStateс вариантамиLoading,Content(items),Error(message),Empty. Комбинация «загрузка и ошибка одновременно» становится невыразимой; - переходы: чистая функция вида
reduce(state, event): State, аwhenпоsealed-типу компилятор проверяет на полноту; - хранение:
ViewModelдержитMutableStateFlow<UiState>, UI подписывается черезcollectAsStateWithLifecycle()в Compose илиrepeatOnLifecycleво View-системе; - MVI: по сути тот же автомат, где интенты служат событиями, а редьюсер функцией переходов;
- где ещё встречается: плеер (idle, buffering, playing, paused), статусы сообщения в чате, многошаговые формы, жизненный цикл самой
Activity.
Главный аргумент за автомат: поведение можно описать таблицей и покрыть юнит-тестами без эмулятора, по одному тесту на переход.
Где спотыкаются
Отвечают только расшифровкой и замолкают. Для разработчика этого мало, ждут пример из кода.
Моделируют состояние набором флагов isLoading, isError, isEmpty. Из трёх булевых получается восемь комбинаций, половина из которых бессмысленна, и однажды UI покажет спиннер поверх ошибки.
Размазывают переходы по коллбэкам и обработчикам кликов. Тогда автомат существует только в голове автора, и новый переход ломает старые сценарии.