Структура Android проекта – альтернативный путь

[C_arter]

Тоже использую такой подход. Удобно.

Есть только однa досадная проблемка: Android Studio не понимает контекст.
Например, вы хотите вынести из src/main/res-screen/chat/layout/mylayout.xml размеры (dimen.xml) или строки (strings.xml) в src/main/res-screen/chat/values, а средства Android Studio вам не позволят этого сделать, все будет выноситься в src/main/res/values/.

Нужно это делать «руками».

[afeozzz]

становится трудно ориентироваться и переходить к нужному файлу.

Имхо нужен просто адекватный нейминг и cmd + shift + O

[geekmetwice]

Это называется «комплекс бога» — заставлять людей следовать правилам, составленным по личному усмотрению. Студота, набранная в гугл, по молодости не понимает, что мир вертится далеко не вокруг их кресла.
Именно из-за этого безобразного поделия и его диктаторских структур я не пишу ведропрограммы — жаль время и нервы. Хотя рынок — громадный.

[Bringoff]

заставлять людей следовать правилам, составленным по личному усмотрению

Эм. Может, я чего-то не знаю, но по чьему усмотрению надо было им разрабатывать sdk и тулзы для ОС, которой они же и владеют?

[Blumfontein]

имхо, большой проект на модули (Library) делить надо.

[xotta6bl4]

Делю на Main, UseCase, Storage, Network, Model, Tools. От 50 xml-файлов в одной папке не спасает.

[Blumfontein]

По экранам пробовали делить? Например, настройки и профиль отдельно, лента новостей и статья отдельно (для бложика пример).

[xotta6bl4]

40 экранов — 40 модулей? Нет, спасибо. А если группировать, то по какому принципу? Плюс есть подозрение, что кольцевые зависимости между модулями неизбежны в таком случае.

[Blumfontein]

Зачем же 1 к 1. Группируйте экраны по назначению. Экран списка статей и экран самой статьи, например, близки по назначению и можно оформить в отдельный модуль.

>> Плюс есть подозрение, что кольцевые зависимости между модулями неизбежны в таком случае.

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

[xotta6bl4]

В том то и дело, что группировка будет основываться не на назначении, а на screen-flow и при изменении оного может возникнуть необходимость переносить экраны из группы в группу. Также при большой связности экранов может возникнуть ситуация, при который мы получим неделимую (без возникновения циклических зависимостей) группу, в которую входят 50 (60/70/80/90) % экранов. Практический смысл от такого деления уменьшается с ростом неделимой группы.

Мой итог: данный подход применим к приложениям с слабой связностью экранов.

[Bringoff]

Для разделения экранов достаточно пакетов. Зачем плодить миллион модулей? Что, по идее, должно замедлить сборку, к тому же.

[Blumfontein]

>> Для разделения экранов достаточно пакетов. Зачем плодить миллион модулей?

Чтобы нельзя было шлепнуть import того, чего не должно быть. Модульный подход заставляет писать менее связный код.

>> Что, по идее, должно замедлить сборку, к тому же.

Совершенно необязательно. Под каждый модуль можно с помощью flavor тонко настроить dev-окружение, когда компилится только сам модуль и его зависимости. В итоге сборка даже быстрее для дева.

[Bringoff]

А вы можете предъявить хотя бы один проект с таким подходом, чтобы можно было оценить преимущества? А то пока профитов не видно, а вот головной боли полно. По-любому с экранов одного модуля как-то можно перейти в другой, значит, все равно цепочки зависимостей, значит, билдиться все равно будет все.

[xotta6bl4]

Например, есть у меня такая цепочка зависимостей:
Model -> Network -> UseCase -> UI

Я скомпилил проект, мне что-то нужно изменить. Например, нужно реализовать in-memory cache для результатов запросов к API. Я модифицирую UseCase и собираю проект. Мой сборщик (в данном случае, Gradle) смотрит, что модули Model, Network, UI не изменились и не компилит их. В итоге я трачу время на только на компиляцию модуля UseCase и сборку apk-шки.

[danikula]

А ещё для тех же целей можно использовать folding-plugin для Android Studio.