Как стать автором
Обновить

Комментарии 2

Еще добавим один минус: тестируемость.

А теперь найдем решение, которое лишено приведенных недостатков:

Разобьем приложение на несколько модулей:
1. Модуль с интерфейсами пратформозависимых сервисов
2. N модулей с реализациями интерфейсов + тесты для каждой из платформы.
3. Главное приложение с N флаворами (аналогично тому, как это сделано у вас), где в dependencies прописываем требуемые реализации для каждого из флаворов (prodCompile project(":android_services"))

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

Оставлю открытым вопрос по инициализации зависимостей. Эту проблему можно решить так же как у вас: одинаково называть реализации интерфейсов в разных модулях. Либо как-то более интересно:)
Да, это очень хорошее замечание. Понимание того, что в gradle-модули можно выносить не только какие-то общие библиотеки, но и разделять ими свой же проект на разные имплементации (платформозависимые или mock/real) или на разные слои, такие как view-модуль, domain-модуль, data-модуль, дает еще больше гибкости. Gradle-модули сами по себе уже мощный инструмент, который заслуживает одельного туториала :)
Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.