Ребят, подскажите пожалуйста, как лучше поступить в плане архитектуры. У меня есть модуль, который отрисовывает в контейнер некоторую view. Другие модули обращаются к нему через интерактор, который предоставляется через Di. Вот интерактор это домейн слой получается, а отрисовка это уже  слой представления. По сути отрисовкой занимается некоторый UiManager, не привязанный ни к activity и к fragment. Как лучше сделать, чтобы не обращаться через интерактор (домейн слой) к этому UiManager(слой представления)?

Всем привет. У меня есть вопрос по архитектуре бд используя Room.
У меня есть две сущности: song и playlist (связь между ними many-to-many).
Чтобы делать выборку со связью, я сделал PlaylistSongCrossRef и PlaylistWithSongs как показано в документации - https://developer.android.com/training/data-storage/room/relationships#many-to-many)
Теперь у меня возникает вопрос, как правильно создавать playlist'ы, как их обновлять (добавлять\удалять song из плейлиста) и т.д.?
Судя по всему я не могу использовать в своей Dao Insert PlaylistWithSongs(который является relation'ом, а не сущностью).

Если бы я делал без room'a, то у меня было бы три таблицы:
songs, playlists, playlistSongs (но я хз во что там Room разворачивает relation'ы).
У меня есть идея завести @Entity CompositionWithSongs(id, compositionId, songId) и не указывать никаких @Relation, @Embedded (сущности вроде и не могут иметь релейшенов в Room), а просто работать с идентификаторами.

я бы тоже послушал рекомендации.
Но я пока обхожусь тем, что по id получаю доменную сущность и по каскаду удаляю всё связанное с ней. Мне кажется, так быстрее например

3 июля приглашаем на вебинар для Android-разработчиков!

Обсуждать будем StateFlow в разрезе реализации реактивного программирования и возможности фреймворка Firebase A/B Testing (на примере продакшн-проекта).

После вебинара вы сможете задать спикерам вопросы.

🗓 Дата: 3 июля
⏰ Начало: 13:00
🏠 Формат: online

Регистрация: https://epa.ms/android-webinar-3jul. Участие бесплатное.

Зарегистрированным пользователям вебинар будет доступен в записи.

Всем привет. В статье от Яндекса по многомодульности, core модуль разбивается на 3, как на скрине. Все так же разбивают или так только в Яндексе?)

Впервые вижу 🤔

Если же оставлять только core-модуль, то изменения в нем ведь пересоберут все фичи, которые зависят от него. Тоже как-то не очень

статью не читал, но судя по идее, фичемодули зависят от кор апи, а там изменения бывают реже

на 2 разбиваю, api и impl
api редко меняется

посмотрите статью от Касперского на Хабре про многомодульность, гуглится легко

Также есть common-модуль, который объясняется как легкий и с функциональностью, необходимым для всех 3-х модулей. А пример такой функциональности? Навигация?

Читал, статья от Яндекса больше зашла. Наверное, стоит еще раз прочесть

утилы какие нибудь

Также интересует вопрос навигации: правильно ли для фич-модулей создавать интерфейсы навигаторов (например, UsersNavigator c методом openUserDetails), и реализовать его в классе AppNavigator (с роутером из Чичероне, пример), который будет в app-модуле?

что-то типа того и будет
апп должен как-то знать каким образом открыть фиче-экран

а не роутер?)

не в классе AppNavigator, а в родителе той или иной фичи

у меня, например, сейчас есть модуль отвечающий за навигацию
если моя фича должна уметь в навигацию, то я даю ей нужные зависимости

какой еще родитель фичи?)

имеешь в виду, юзать напрямую роутер в фиче-модуле? в таком случае для перехода роутеру понадобится Screen из Чичероне, а скрины имеет смысл поместить в app-модуль, чтобы фиче-модули не знали про другие экраны