Представлюсь, Малюгин Платон Android Lead в Dejavoo Systems. Эта история про нашу "боль" с которой мы боремся уже год и эволюцию нашей архитектуры. Основной профиль кассовые терминалы для ритейлеров и ресторанов, поэтому многое завязано на особенности индустрии.
В любом случаи изменения архитектуры для приложения, не только усложняет его, но увеличивает количество документации и требует поддержки. Поэтому стоит подумать, а нужно ли на это делать сейчас? Достаточно накопленного опыта и количество блокирующих задач?
Почему сейчас? Можно же дальше страдать и как можно меньше трогать этот экран, раз работает, зачем ломать то, что работает сейчас? Все просто, накопилось большое количество блокирующих задач, для которых требуется переделать текущую структуру заказа, на более сложную, но гибкую. Без переделок не обойтись.
Описание проблемы
Используем одну Activity для заказа, которая поддерживает версию для планшета и для телефона. Нам проще работать с диалогами (у нас диалоги это Activity), а их очень много на этом экране и дублировать не хотелось бы.
Вот так выглядит версия для планшета:
Версию для телефонов собираем из тех же элементов, но с другим навигатором.
Опишу из чего состоит состоит экран:
- Items фрагмент
- Departments фрагмент
- Line Items и Amount фрагмент
- Order Parameters это отдельная вьюшка
Количество управляемых параметров больше 50, под каждое у нас отдельный метод который дергается на одном из фрагментов, вьюшек и активностей, наш OrderPresenter все растет и растет.
Текущая архитектура
Изначально допустил ошибку и поместил заказ в презентер, только сохранение или изменение вызывает Use case, который обновляет кэш и БД. Нам важно чтобы операции выполнялись последовательно. Например, у заказа есть депозит, при превышении его нужно показать пользователю, что сумма превышена и предложить увеличить депозит.
Выполнение в главном потоке гарантируют, что операции выполняется последовательно, конечно все выполняет довольно быстро, больше всего времени занимает уведомление всех остальных фрагментов, так как главный поток, проседает общая производительность. Пришлось добавлять костыли, например сумма заказа пересчитывается в отдельном потоке (через Use case).
Подытожим:
- В презентере много логики, которой не должно быть
- Много выполняется в главном потоке, хотя стоит вынести в отдельный поток
- Уведомляем только об изменении заказа и каждом объекту, нужно самому обработать что изменилось, так что логика может дублироваться
- В презентере, не получится просто добавить дополнительный запроса к кэше и к БД
- Презентер отвечающий на заказ, на экране заказа, становится "массивным" презентром
- Работаем напрямую с явными структурами, а не через абстракции
Обновление архитектуры
"Все переделать" пугающие слово, особенно когда нужно больше 2-х месяцев. Но это катастрофа:
- Не делаем новые бизнес задачи
- Можно "перегореть" (чистая психология)
- Сделаем такое, что потребуется переделать
- Поддерживать обе версии, пока окончательно не перейдем
В любом случаи нужно понимать, что бизнес важнее разработки, по сути разработка помогает их заработать, но всегда потребности, которые нужно решить как можно быстрее.
Поэтому можно увеличивать длительность разработки, но не блокировать текущий процесс и вносить правки частями, но которые будут реально работать. После обсуждения договорились поделить на этапы:
- Спроектировать архитектуру и добавить абстракции для полноценной работы
- Адаптировать новую архитектуру под структуру старого заказа
- Добавить поддержку структуру нового заказа
После обсуждений появились общие требования
- Все можно поделить на небольшие куски и поделить в команде
- Каждый новый релиз (у нас цикл релиза 2 недели) получал новые изменения, которые используются
- Должны быть написаны тесты
- Все вычисления должны производится отдельном потоке
- Получение уведомлений в главном потоке
- Желательно не менять UI
- Убрать зависимость от Rx и скрыть под абстракциями
- Упростить работу с зависимостями
Что придумали
Каждая операция добавляет команду в последовательную очередь, команда "дергает" репозиторий, репозиторий дергает диспетчеры, диспетчер может сформировать и отправить уведомление (диспетчеры так же могут работать с данными и тд), либо проигнорировать. Каждый объект подписываются только на свои уведомления и тем самым мы можем ограничить их количество и работать уже с готовыми данными.
Теперь, если пользователь будет "долбить" по экрану очень быстро. то мы сможем все операции обработать, хоть с небольшой задержкой (хотя для глаза это будет менее заметно, чем "зависание" экрана)
Краткая UML схема репозитория:
Итог
Возможно мы придумали велосипед, но архитектура, на мой взгляд, упрощает работу и позволят поддерживать более сложные кейсы. Продолжаем над ней работать.
