Как делать Android MVP-инди-пет-проект

Когда надо заделать Android-приложение с нуля, как минимально жизнеспособный продукт (MVP) или для индивидуального проекта (инди, пет), главная цель – быстро выпустить рабочий прототип, протестировать гипотезы на первых пользователях, выйти на рынок и получить обратную связь. В отличие от долгоживущих энтерпрайзов, масштабируемость и поддерживаемость мвп не так важна, а цена ошибок не высока.

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

• Многомодульность. Хватит одного модуля :app. Никто не запрещает раскладывать классы по папкам и переиспользовать. Конфигурация Gradle в моменте усложняет проект и увеличивает сроки разработки, особенно с >= 2 модулями на каждую фичу.

• Чистая архитектура. Кажется, мы дожили до времен, когда даже на уважаемых конференциях дядю боба с его луковицей выписывают из повестки. Сложная и многослойная архитектура часто не дает реальных преимуществ, а лишь привносит лишние церемонии на свое техобслуживание. Доходит до того, что разработчики пишут плагин для IDE, который им генерирует 20 классов на фичу.

• DI. Вместо использования фреймворков, таких, как Hilt, можно создавать экземпляры классов вручную. Или использовать сервис локатор. Это быстрее и проще, хоть и менее масштабируемо.

• Интерфейсы. Используются для обеспечения слабых связей между компонентами и упрощения тестирования. Часто можно увидеть Interactor и его реализацию InteractorImpl. Если мы контролируем весь код, жесткая связь между классами не будет проблемой. Методы можно вызывать напрямую из класса, который обрабатывает логику.

• KMP. Лучше начинать с нативного Android-приложения. Мультиплатформа постоянно подкидывает проблем, несмотря на обещанную стабильность. Вагон времени уходит на прописывание expect-actual.

• Миграция БД. Можно не делать, если база данных просто дублирует сетевой слой. Для Room вызывается fallbackToDestructiveMigration(), получаем дроп всех таблиц при увеличении номера версии.

• Строки. На начальном этапе можно не поддреживать интернационализацию и хардкодить текстовые строки прямо в UI приложения. Текст будет часто меняться, а добавление строк в strings.xml отбирать много времени.

• Собственная библиотека компонентов, стилей и шрифтов. Достаточно Material Components и шрифта Open Sans.

• Линтеры. Detekt и Lint анализируют код на предмет ошибок, стиля и соблюдения стандартов. Эти инструменты выдают множество предупреждений и замедляют процесс разработки. Она превращается в похождения в файлик со стилем для отключения очередной проверки. Линтеры полезны, когда основная функциональность будет готова. Пока этот момент не наступил, нужно в build.gradle прописать abortOnError = false.

• Самописные виджеты. Под любую штуку надо брать готовое решение с гитхаба. Нужен колорпикер или календарь – затянул зависимость. Позже можно переписать виджет под проект.

• Костыли. Все что другим запрещено – нам разрешено. Можно использовать GlobalScope, runBlocking, делать статические ссылки на Context. Это очень быстро и удобно.

• Преждевременные оптимизации. Рекомпозиции, энергосбережение, бенчмарки, кэши и буферизации. Современный смартфон почти наверняка не оценит этих усилий. Приложение и так будет работать нормально.

• Время запуска приложения. Использование AppStartup и ленивой инициализации, минимизация Application.onCreate и Activity.onCreate. Пользователю пофиг, запускается приложение 200 миллисекунд или 1.5 секунды, есть сплэш-скрин или нет его.

• Размер APK. R8, сплит по ABI, векторная графика, no-op библиотеки и транзитивные зависимости. Пользователю пофиг, весит приложение 20 мегабайт или 200.