Сейчас пробую по заветам Рыжиков, вообще не продумывать архитектуру.
А сделать как можно проще и покрыть e2e тестами (абстрагируя для этого внешние сервисы).

И потом буду ждать deep insight 🌚

===

@indrih17 Я кстати побенчмаркал сборку #gradle в docker windows и docker linux (live cd)

Получилось: (время clean сборки, с удаленно папкой ~/.gradle/caches )

linux:
- 2:52
- 2:53
- 2:52

windows:
- 2:46
- 2:58
- 2:40

(PS но возможно на linux это из-за медленной файловой системы devicemapper тк aufs не заработал)

linux:
- 2:52
- 2:53
- 2:52

windows:
- 2:46
- 2:58
- 2:40

Хм, понятно. Надо будет тоже потом побенчмаркать.)

@angmarr ты можешь припомнить либу, которая генерировала бы код не для каждого модуля в папочке build, а в общей папке, и код был бы доступен любому модулю?

О, бля, у меня было такое андроид-приложение. То, в котором класс вьюхи больше 3к строк держал. Проект древний, архитектуры были не в моде. Только е2е тестов не было (никаких не было).
Дип инсайт так и не пришёл. Но проект до сих пор не рассыпался вроде даже.

Я вот не помню, чтобы кто-то так делал. И если б ты без андроид-плагина это делал, я бы ещё подумал, какой можно совет дать, но в свете того, что ты там с агп интегрируешься, я не полез читать джавадоки к его методам даже.

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

> с апг интегрируешься
С чем?🌚

Android Gradle Plugin

Он öбнутый, хотя они и стараются исправиться.)))

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

А лол, впервые встречаю такое сокращение.)

Ещё можно наделать дополнительных конфигураций и перелинковать их, но я пока такую штуку красиво не научился фигачить( А с явными связями выглядит так себе.

Не понял, это как?

В гредле есть, грубо говоря, два вида конфигураций -- один вид ты можешь зарезолвить, тем самым забрав из него что-то (к примеру, implementation, api -- это как раз такие), с помощью второго вида ты можешь что-то провайдить наружу из модуля (к примеру, в AGP есть конфигурации, которые провайдят манифест бинарный, аарки и многое другое). Ты можешь в текущем модуле указать зависимости на кастомную конфигурацию из другого модуля, забрать оттуда некоторые данные, выполнить над текущим модулем и данными из зависимостей некоторые операции, и высунуть наружу данные уже для текущего модуля. Тогда на модулях-апишках в гредле можно было бы построить дерево, по которому был бы построен граф навигации по проекту, а уже реализации друг от друга не зависели бы, как ты и хочешь.

Впервые о таком слышу, спасибо. А не подскажешь куда гуглить?

У меня на этой приблуде сделаны метаданные для библиотек в инкрементале. У нас кодген в два этапа -- сначала парсится код и строится модель с нужными данными, она в жисон катается, а потом уже по жисону генерится код. Пришлось разбить, чтобы можно было порезолвить супертипы для классов вьюх. Подавляющее большинство наследуется от View/ViewGroup, и эти частные случаи схендлены руками, но есть, к примеру, вьюхи в паре либ из андроидх (не помню точно, какие), которые наследуются от супертипов из материала, а они уже наследуются от базовых системных классов. В итоге для каждого модуля есть жисоны, и те либы подтягивают жисон для материала. И у кодгена есть уже полная картина.

Конкретно эту тему официальная дока неплохо покрывает.
https://docs.gradle.org/current/userguide/declaring_dependencies.html
Но придётся покурить несколько раз, одного не хватит.

Можешь после чтения доки также в проекте с AGP прологировать существующие конфигурации (имя, canBeResolved, canBeConsumed). Прикидываешь, как это помогает линковать проекты, и становится чуть лучше понятно, зачем эта фича нужна.