Api не должен знать про свой impl. В этом его смысл. У Вас получается, что при пересборке impl пересоберётся его api и все модули, которые зависят от этого api. Ради того, чтобы этого избежать, мы как раз и выделяли модуль api.

По поводу строк - вопрос спорный. Можно пойти такими путями:
1. У каждой фичи свои строки.
+: быстрая пересборка,
-: дубликаты строк в фичах, сложности в отправке на переводы.

2. Единый модуль строк, о котором все знают.
+: все строки в одном месте - легко отправить на перевод, строки могут использоваться в разных фичах (не нужно дублировать).
-: при изменении строк пересоберутся все модули.

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

Я думаю, этот вопрос следует ещё решать с локализаторами. Как им будет удобнее работать.

Ребят всем привет.
Вопрос: как сделать разные конфигурации для сборки приложения? Типа dev-сборка будет содержать одни урлы для retrofit'a допустим,а для prod-версии другие

buildConfigFields

Здорово. А как происходит выбор конфига при сборке?

Если погуглишь то ты в градле указываешь для debug и release buildConfigField "String", "ServerUrl", "Какой-то хост"
А при создании ретрофита ему подкидываешь BuildConfig.ServerUrl

В итоге при билде у тебя в класс BuildConfig попадает та версия ServerUrl для которой делается сборка

почему архитектурный паттерн MVC не зашел в мир android разработки?

по сути Model - это чисто бизнес логика и агрегация состояния view и каких то данных

View - это фрагмент или активити

Controller - это сущность которая занимается обработкой пользовательского ввода

если я все правильно понял

это если брать определения из этерпрайз мира (я почему то вообще не нашел норм определения для приложений под android)

даже примеров не нашел

то есть отличие от MVP в том что:
1. у нас появилась сущность Controller которая делегирует пользовательский ввод нашей Model
2. за место Presenter у нас Model, который является бизнес логикой
3. получается что источник данных находится в самом Model
4. Model предоставляет данные view через паттерн наблюдатель

По идее C из MVC это что близкое к P из MVP.
То есть пункт 2 тут как бы не верен.

А не прижилось из за того что в андроиде View и Controller это Fragment/Activity, и от этого эти классы разрастались, пропадало разделение ответственности, вся логика оседала в них, а ещё у них есть свой жизненный цикл, который наглухо обрывал все запросы при смене конфигурации что приводило к их собственно потере.

В итоге мы получали вместо ModelViewController - MassiveViewController, который ещё и терял в процессе работы состояние

Вроде если я не ошибся не прижился паттерн по этим причинам

тогда MVC это тоже самое что и MVP

да и я озвучил определение из энтерпрайза, а это совершенно другая платформа и другой sdk

Ну потоки данных там все же немного разные объективно https://m.habr.com/ru/post/171925/