Комментарии 15
Тоже использую такой подход. Удобно.
Есть только одн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/.
Нужно это делать «руками».
Есть только одн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/.
Нужно это делать «руками».
становится трудно ориентироваться и переходить к нужному файлу.Имхо нужен просто адекватный нейминг и cmd + shift + O
Это называется «комплекс бога» — заставлять людей следовать правилам, составленным по личному усмотрению. Студота, набранная в гугл, по молодости не понимает, что мир вертится далеко не вокруг их кресла.
Именно из-за этого безобразного поделия и его диктаторских структур я не пишу ведропрограммы — жаль время и нервы. Хотя рынок — громадный.
Именно из-за этого безобразного поделия и его диктаторских структур я не пишу ведропрограммы — жаль время и нервы. Хотя рынок — громадный.
имхо, большой проект на модули (Library) делить надо.
Делю на Main, UseCase, Storage, Network, Model, Tools. От 50 xml-файлов в одной папке не спасает.
По экранам пробовали делить? Например, настройки и профиль отдельно, лента новостей и статья отдельно (для бложика пример).
40 экранов — 40 модулей? Нет, спасибо. А если группировать, то по какому принципу? Плюс есть подозрение, что кольцевые зависимости между модулями неизбежны в таком случае.
Зачем же 1 к 1. Группируйте экраны по назначению. Экран списка статей и экран самой статьи, например, близки по назначению и можно оформить в отдельный модуль.
>> Плюс есть подозрение, что кольцевые зависимости между модулями неизбежны в таком случае.
Совершенно разные по назначению экраны при правильной архитектуре не должны иметь кольцевых зависимостей.
>> Плюс есть подозрение, что кольцевые зависимости между модулями неизбежны в таком случае.
Совершенно разные по назначению экраны при правильной архитектуре не должны иметь кольцевых зависимостей.
В том то и дело, что группировка будет основываться не на назначении, а на screen-flow и при изменении оного может возникнуть необходимость переносить экраны из группы в группу. Также при большой связности экранов может возникнуть ситуация, при который мы получим неделимую (без возникновения циклических зависимостей) группу, в которую входят 50 (60/70/80/90) % экранов. Практический смысл от такого деления уменьшается с ростом неделимой группы.
Мой итог: данный подход применим к приложениям с слабой связностью экранов.
Мой итог: данный подход применим к приложениям с слабой связностью экранов.
Для разделения экранов достаточно пакетов. Зачем плодить миллион модулей? Что, по идее, должно замедлить сборку, к тому же.
>> Для разделения экранов достаточно пакетов. Зачем плодить миллион модулей?
Чтобы нельзя было шлепнуть import того, чего не должно быть. Модульный подход заставляет писать менее связный код.
>> Что, по идее, должно замедлить сборку, к тому же.
Совершенно необязательно. Под каждый модуль можно с помощью flavor тонко настроить dev-окружение, когда компилится только сам модуль и его зависимости. В итоге сборка даже быстрее для дева.
Чтобы нельзя было шлепнуть import того, чего не должно быть. Модульный подход заставляет писать менее связный код.
>> Что, по идее, должно замедлить сборку, к тому же.
Совершенно необязательно. Под каждый модуль можно с помощью flavor тонко настроить dev-окружение, когда компилится только сам модуль и его зависимости. В итоге сборка даже быстрее для дева.
А вы можете предъявить хотя бы один проект с таким подходом, чтобы можно было оценить преимущества? А то пока профитов не видно, а вот головной боли полно. По-любому с экранов одного модуля как-то можно перейти в другой, значит, все равно цепочки зависимостей, значит, билдиться все равно будет все.
Например, есть у меня такая цепочка зависимостей:
Model -> Network -> UseCase -> UI
Я скомпилил проект, мне что-то нужно изменить. Например, нужно реализовать in-memory cache для результатов запросов к API. Я модифицирую UseCase и собираю проект. Мой сборщик (в данном случае, Gradle) смотрит, что модули Model, Network, UI не изменились и не компилит их. В итоге я трачу время на только на компиляцию модуля UseCase и сборку apk-шки.
Model -> Network -> UseCase -> UI
Я скомпилил проект, мне что-то нужно изменить. Например, нужно реализовать in-memory cache для результатов запросов к API. Я модифицирую UseCase и собираю проект. Мой сборщик (в данном случае, Gradle) смотрит, что модули Model, Network, UI не изменились и не компилит их. В итоге я трачу время на только на компиляцию модуля UseCase и сборку apk-шки.
А ещё для тех же целей можно использовать folding-plugin для Android Studio.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Структура Android проекта – альтернативный путь