Приветствую! Коллеги подсказали: у нас параметризация значения RAM в зависимости от того, что есть на ранере, который запускает сборку. Налету подкидываются ограничения по RAM для Kotlin и Gradle
У нас в kubernetes. По поводу того, пробовали ли на виртуальных машинах, не уверен. Уточню у коллег из ответственной команды и сделаю апдейт этого комментария
Оставили как есть. У нас api модули шарят только domain сущности и навигацию, т.е. там нет зависимостей на android и, соответственно, нет необходимости в android lint
Отдельно компоненты не отключали - изначально целились в получение максимального эффекта именно от полного перехода
Всё же не вижу удобным способ добавления аргументов сразу в транзакцию. Такой подход не выглядит расширяемым и будет сильно загрязнять код. Гораздо удобнее инкапсулировать это "старым" способом через companion object в фрагменте
По поводу бойлерплейта при инфлейте разметки - если мы используем view binding, что встречается почти всегда, то от бойлерплейта мы получается все равно не уйдём
Полезная статья. Главное сильно не увлекаться вынесением общего кода между фичами, бывает сложно на начальном этапе выделить корректную абстракцию. И то, что кажется похожим и общим сейчас, может иметь тенденцию к расхождению по разным сторонам в будущем. Общий код != правильная абстракция, и иногда бывает даже лучше продублировать некоторые вещи, чем закинуть всё в Core модуль.
Приветствую! Коллеги подсказали: у нас параметризация значения RAM в зависимости от того, что есть на ранере, который запускает сборку. Налету подкидываются ограничения по RAM для Kotlin и Gradle
У нас в kubernetes. По поводу того, пробовали ли на виртуальных машинах, не уверен. Уточню у коллег из ответственной команды и сделаю апдейт этого комментария
Оставили как есть. У нас api модули шарят только domain сущности и навигацию, т.е. там нет зависимостей на android и, соответственно, нет необходимости в android lint
Отдельно компоненты не отключали - изначально целились в получение максимального эффекта именно от полного перехода
Спасибо за статью, получилось интересно!
Всё же не вижу удобным способ добавления аргументов сразу в транзакцию. Такой подход не выглядит расширяемым и будет сильно загрязнять код. Гораздо удобнее инкапсулировать это "старым" способом через companion object в фрагменте
По поводу бойлерплейта при инфлейте разметки - если мы используем view binding, что встречается почти всегда, то от бойлерплейта мы получается все равно не уйдём
Полезная статья. Главное сильно не увлекаться вынесением общего кода между фичами, бывает сложно на начальном этапе выделить корректную абстракцию. И то, что кажется похожим и общим сейчас, может иметь тенденцию к расхождению по разным сторонам в будущем. Общий код != правильная абстракция, и иногда бывает даже лучше продублировать некоторые вещи, чем закинуть всё в Core модуль.
Последнюю задачку можно взять похитрее)
�
Отличный материал, к которому можно не раз обратиться в будущем, спасибо!