Intro
Все мы знаем, как выглядит структура Android проекта – поместить все изображения в этот каталог, все файлы разметки в тот каталог. Но… во время разработки проекта количество файлов растет очень быстро и становится трудно ориентироваться и переходить к нужному файлу.
Структура типичного Android проектаКаталог ресурсов для экрана
В случае если экран содержит большое количество файлов разметки, изображений, размеров – имеет смысл создать отдельные каталоги ресурсов для каждого экрана.
Структура — каталог ресурсов для каждого экранаКак вы можете видеть на скрине сверху, мы имеем два корневых каталога внутри каталога main:
- res-main содержит все общие ресурсы, которые используются на более, чем одном экране.
- res-screen содержит каталоги ресурсов для каждого экрана, например, about, chat, event details, event list, home, login
Давайте заглянем внутрь папки ресурсов для экрана chat.
Сам чат состоит из нескольких xml layouts файлов, поэтому мы создали каталог chat layout и поместили туда эти файлы. Также имеется множество .png изображений, которые используются только на экране чата, поэтому мы поместили все эти изображения в подкаталоги drawable-hdpi, drawable-xhdpi, drawable-xxhdpi и drawable-xxxhdpi каталога chat.
Когда настанет время реализовать альбомную ориентацию или версию чата для планшета, мы создадим каталоги layout-land и layout-sw720dp внутри каталога ресурсов для экрана chat.
Как объявить каталог ресурсов для экрана?
Откройте файл app.gradle и объявите sourceSets внутри секции android. Более подробно об объединении ресурсов написано тут.
sourceSets {
main {
res.srcDirs = [
'src/main/res-main',
'src/main/res-screen/about',
'src/main/res-screen/chat',
'src/main/res-screen/event-detail',
'src/main/res-screen/event-list',
'src/main/res-screen/home',
'src/main/res-screen/login',
]
}
}
Примечание: это работает только в режиме просмотра Project.
Заключение
Если вы работаете над большим проектом и хотите классифицировать ваши каталоги, легко определять какой файл разметки, изображение, значение и т.д. принадлежит какому экрану, используйте каталоги ресурсов для каждого экрана.
Комментарии (12)
afeozzz
23.06.2016 17:35+4становится трудно ориентироваться и переходить к нужному файлу.
Имхо нужен просто адекватный нейминг и cmd + shift + O
geekmetwice
24.06.2016 00:07-4Это называется «комплекс бога» — заставлять людей следовать правилам, составленным по личному усмотрению. Студота, набранная в гугл, по молодости не понимает, что мир вертится далеко не вокруг их кресла.
Именно из-за этого безобразного поделия и его диктаторских структур я не пишу ведропрограммы — жаль время и нервы. Хотя рынок — громадный.
Bringoff
27.06.2016 08:17заставлять людей следовать правилам, составленным по личному усмотрению
Эм. Может, я чего-то не знаю, но по чьему усмотрению надо было им разрабатывать sdk и тулзы для ОС, которой они же и владеют?
Blumfontein
24.06.2016 09:23имхо, большой проект на модули (Library) делить надо.
xotta6bl4
28.06.2016 10:40Делю на Main, UseCase, Storage, Network, Model, Tools. От 50 xml-файлов в одной папке не спасает.
Blumfontein
28.06.2016 11:33По экранам пробовали делить? Например, настройки и профиль отдельно, лента новостей и статья отдельно (для бложика пример).
xotta6bl4
28.06.2016 11:4640 экранов — 40 модулей? Нет, спасибо. А если группировать, то по какому принципу? Плюс есть подозрение, что кольцевые зависимости между модулями неизбежны в таком случае.
Blumfontein
28.06.2016 12:03Зачем же 1 к 1. Группируйте экраны по назначению. Экран списка статей и экран самой статьи, например, близки по назначению и можно оформить в отдельный модуль.
>> Плюс есть подозрение, что кольцевые зависимости между модулями неизбежны в таком случае.
Совершенно разные по назначению экраны при правильной архитектуре не должны иметь кольцевых зависимостей.xotta6bl4
28.06.2016 12:58В том то и дело, что группировка будет основываться не на назначении, а на screen-flow и при изменении оного может возникнуть необходимость переносить экраны из группы в группу. Также при большой связности экранов может возникнуть ситуация, при который мы получим неделимую (без возникновения циклических зависимостей) группу, в которую входят 50 (60/70/80/90) % экранов. Практический смысл от такого деления уменьшается с ростом неделимой группы.
Мой итог: данный подход применим к приложениям с слабой связностью экранов.
Bringoff
29.06.2016 12:01Для разделения экранов достаточно пакетов. Зачем плодить миллион модулей? Что, по идее, должно замедлить сборку, к тому же.
Blumfontein
29.06.2016 12:57>> Для разделения экранов достаточно пакетов. Зачем плодить миллион модулей?
Чтобы нельзя было шлепнуть import того, чего не должно быть. Модульный подход заставляет писать менее связный код.
>> Что, по идее, должно замедлить сборку, к тому же.
Совершенно необязательно. Под каждый модуль можно с помощью flavor тонко настроить dev-окружение, когда компилится только сам модуль и его зависимости. В итоге сборка даже быстрее для дева.
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/.
Нужно это делать «руками».