EK
Спасибо
Size: a a a
2020 July 23
A
Посоветуйте хорошие курсы/литературу по юнит и UI тестированию
E
Посоветуйте хорошие курсы/литературу по юнит и UI тестированию
причем тут чат архитектуры?
имхо, сюда уже просто за все приходят
имхо, сюда уже просто за все приходят
DS
А кто нибудь пробовал возвращать результат через вызовы targetFragment?.viewModel ?
AD
А кто нибудь пробовал возвращать результат через вызовы targetFragment?.viewModel ?
лучше не надо так делать
I
Народ, подкинте пожалуйста примеры библиотек с исходниками, где есть встраивание функционала с помощь фргаментов. Т.е. как в Yandex или Google MapKit я могу вставить в разметку или транзакцией фрагмент, где-то в Application провести инициализацию и он будет самостоятельно работать. Особенно интересует как реализована навигация, т.е. чтобы библиотека сама внутри фрагмента могла делать переходы между подфрагментами. Хочется посмотреть архитектурные подходы, но пока ничего похожего не нашел.
A
причем тут чат архитектуры?
имхо, сюда уже просто за все приходят
имхо, сюда уже просто за все приходят
Согласен
2020 July 24
☠🇷
Господа, есть у кого под рукой проектик Compose+MVICore+Hilt?
YT
где лучше всего хранить общие строковые константы (BASE_URL,SHARED_PREF_KEY) в приложении ?
ES
Ysim Tokido
где лучше всего хранить общие строковые константы (BASE_URL,SHARED_PREF_KEY) в приложении ?
Я думаю в классах её предназначения
ES
Ysim Tokido
где лучше всего хранить общие строковые константы (BASE_URL,SHARED_PREF_KEY) в приложении ?
Ну или второй вариант, создать какой нибудь Config и туда писать
YT
А если в ресурсах strings или BuildConfig gradle или это плохая практика ?
OP
Ysim Tokido
А если в ресурсах strings или BuildConfig gradle или это плохая практика ?
в ресурсах - нужен будет контекст для парсинга, а в логике получения URL это странно. в градле по идее норм, но там тоже вытаскивать это надо и непонятен профит. Лучше действительно иметь одельный класс Constants/Config и в него уже тыкаться
YT
В чем заключается преимущество многомодульности для presentation layer когда скажем login,profile,cart,shop etc.-лежат в отдельных модулях нежели просто в пакетах но в одном модуле ? Использование разных библиотек ?- можно это решить через gradle build types ?
NM
Ysim Tokido
В чем заключается преимущество многомодульности для presentation layer когда скажем login,profile,cart,shop etc.-лежат в отдельных модулях нежели просто в пакетах но в одном модуле ? Использование разных библиотек ?- можно это решить через gradle build types ?
Какой-то криво построенный вопрос
Смысл бить на модули есть либо по фичам, либо по фича+слой
А-ля
feature1-domain
feature1-presentation
feature1-data
Всё зависит от размера команды и её упоротости)
А разбитие всего по слоям, а внутри по фича-пакетам, имхо, максимально неудобное во всех аспектах
Смысл бить на модули есть либо по фичам, либо по фича+слой
А-ля
feature1-domain
feature1-presentation
feature1-data
Всё зависит от размера команды и её упоротости)
А разбитие всего по слоям, а внутри по фича-пакетам, имхо, максимально неудобное во всех аспектах
YT
ну вот я и об это и спрашиваю ,когда отдельная фича (слоя presentation ) в своем модуле
YT
Какой-то криво построенный вопрос
Смысл бить на модули есть либо по фичам, либо по фича+слой
А-ля
feature1-domain
feature1-presentation
feature1-data
Всё зависит от размера команды и её упоротости)
А разбитие всего по слоям, а внутри по фича-пакетам, имхо, максимально неудобное во всех аспектах
Смысл бить на модули есть либо по фичам, либо по фича+слой
А-ля
feature1-domain
feature1-presentation
feature1-data
Всё зависит от размера команды и её упоротости)
А разбитие всего по слоям, а внутри по фича-пакетам, имхо, максимально неудобное во всех аспектах
В чем неудобность заключается?
NM
Ysim Tokido
В чем неудобность заключается?
Если ты про последнее предложение то
Суть разбиения на модули это изоляция одного от другого, разбиение зависимостей (не беру во внимание вещи а-ля ускорение билд тайма)
То в примере с 3-мя модулями presentation, domain, data например у нас фичи будуть знать друг о друге в рамках своего слоя, что в принципе недопустимо и в больших командах приведёт у большой запутанности
Если у нас все разбито на фичи внутри которых уже слои по пакетам это уже решение куда лучше, разработчики конкретной фичи (если их 2+) будут влиять только на неё и вполне могут между собой работать над данноц фичей
Но если фичи растут и становятся слишком крупными, тогда можно задумываться о разбиение фичи на слой-модули, где каждый из разработчиков будет отдавать другому только интерфейс для взаимодействия со своим слоем и каждый из них работает изолированно
Суть разбиения на модули это изоляция одного от другого, разбиение зависимостей (не беру во внимание вещи а-ля ускорение билд тайма)
То в примере с 3-мя модулями presentation, domain, data например у нас фичи будуть знать друг о друге в рамках своего слоя, что в принципе недопустимо и в больших командах приведёт у большой запутанности
Если у нас все разбито на фичи внутри которых уже слои по пакетам это уже решение куда лучше, разработчики конкретной фичи (если их 2+) будут влиять только на неё и вполне могут между собой работать над данноц фичей
Но если фичи растут и становятся слишком крупными, тогда можно задумываться о разбиение фичи на слой-модули, где каждый из разработчиков будет отдавать другому только интерфейс для взаимодействия со своим слоем и каждый из них работает изолированно
YT
Спасибо ,насколько я понял если на проекте сам в этом нет необходимости особой разделять на модули presentation layers
NM
Ysim Tokido
Спасибо ,насколько я понял если на проекте сам в этом нет необходимости особой разделять на модули presentation layers
Достаточно разбить на фича-модули