не проверял

K P A C U B O

програмист штоли?

нет, манки-кодер

Как лучше передавать данные при навигации фрагментов? Через бандл или через какой-нибудь интерактор?
Тут могут быть два случая: первый - это когда у нас уже есть все данные, которые нужно отобразить, а второй - это когда есть, например, только id и потом по этому id нужно еще загрузить информацию.

У любых данных в андроиде должен быть компонент-владелец, который где-то живёт и хранит состояние.
В случае с «каким-нибудь интерактором» звучит как передача через статик/синглтон — такое канает только для кешей/мемоизации, то есть данных, которые не страшно потерять.

В каком случае они могут потеряться? Процесс убьют?

да, пользователь примет звонок или сфоткает цветочек на камеру — и всё

Понял, спасибо

Юзать room🤔 и потом через savedArgs передавать аргументы 🤔

где-то рум, где-то фаерстор, где-то кэш HTTP-клиента

Ребят, привет! Есть проект, в нем несколько архитектур. Собираю все это в bundle и лью на маркет. Анализатором открываю бандл, там все ровно, все папки архитектур присутствуют с либами. Затем качаю с маркета и получается что если sdk > 27, то по размеру вроде норм, но при попытки использовать нативные либы приложение падает. Если <= 27, то качаются абсолютно все возможные архитектуры, но все работает. В чем мб проблема?

собирай руками aab а потом руками сделай экспорт для архитектуры и посмотри apk

Я загружаю из интернета список элементов, у каждого из этих элементов много полей. У меня есть экран со списком (RecyclerView) и в этом списке нужно отображать данные, но, естественно, не все поля, а только их малая часть. По клин вроде как нужно маппить данные, тогда у меня в репозитории будет один список и практически такой же список в адаптере, но с отсутствием некоторых полей у элементов. Если выполняется фильтрация данных, то в любом случае придется копировать, но если фильтрации нет, то получится просто два практически одинаковых списка. Пока не вижу плюсов использования подхода клин со своими моделями на каждом слое, разве что во view не будет доступа к ненужным полям. Что думаете?

Поля модельки айтема должны исходить из того, что нужно для того, что видит пользователь. (заголовок, подзаголовок, цвет какой-нибудь и т.д.)

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

Но с другой стороны, если список большой, то это неэффективное расходование памяти.

Ну, это часто трейдофф, когда пилим архитектуру

Давно интересует одна тема, никак не могу найти полностью удовлетворяющее меня решение.

Допустим, дело обстоит вот так:
у меня есть юзкейс (или метод), скажем, "BackupUserData". Он берёт из базы юзеров и бекапит их по одному. Вот у него есть коллбек onBackupResult, в него возвращается лист юзеров и репорт об успешности / неуспешности операции. Проблема же заключается в том, что если я хочу получать какое-то промежуточное состояние операции в слое представления и / или передавать туда данные по мере необходимости, приходится писать какую-то фигню (в архитектурном смысле).

Я ищу способ оставить целостность логики (одна очерченная бизнес-логикой функция - один юз кейс) и при этом иметь возможность взаимодействовать с этим флоу по мере его исполнения.
Моё ублюдочное решение:
Я передаю лямбды в параметрах и возвращаю какие-то лютые кортежи с лямбдами в коллбек (особенно дико это выглядит если принимать во внимание, что у меня ырыкс, который не должен торчать снаружи либы). Выглядит это нечитаемо и я ощущаю, что можно сделать лучше, но не знаю, каким образом. Был вариант создавать по интерфейсу на каждый входной / выходной параметр. Делать так или не делать? В общем, жду ваши варианты, леди и джентльмены)

ТЕА