S
та не там через cicerone по идее грохнулся весь стек и заменил стартовый
А, ну тогда норм должно быть.
Size: a a a
2020 August 20
AA
ох уж этот увлекательный мир программирования на андройде) всем спасибо за дискуссию и советы) всем добра)
S
Заглянул в код либы. Либа ничего не персистит. Значит если данные не были заперсистены, то на восстановлении прилложения они в шине ни откуда не появятся. В общем-то обычная либа, но задача персиста все так же остается на плечах пользователя либы 💁
YW
Заглянул в код либы. Либа ничего не персистит. Значит если данные не были заперсистены, то на восстановлении прилложения они в шине ни откуда не появятся. В общем-то обычная либа, но задача персиста все так же остается на плечах пользователя либы 💁
Да это даже не либа а подход на основе rx сабжектов
S
Да это даже не либа а подход на основе rx сабжектов
А, я подумал ты кинул ссылку на либу шины, которая персистит данные )
O
скажите в MVVM использую android navigation jetpack - вопрос такой переходы между фрагментами лучше вызывать в фрагментах ИЛИ можно прокинуть в viewModel и там делать переходы??? ПЕреходы между фрагментами - это чья ответственность?
YW
А, я подумал ты кинул ссылку на либу шины, которая персистит данные )
Там в начале еventbus разбирают, потом уже примеры как сделать. Такое же на рх
YW
А, я подумал ты кинул ссылку на либу шины, которая персистит данные )
Ну и библиотеки типа Moxy и ViewModel из jetpack сохраняет стейт, то есть они восстанавливают твою шину в нужном виде
S
Там в начале еventbus разбирают, потом уже примеры как сделать. Такое же на рх
А, принцип шины мне знаком, просто не очень нравиться идея одной глобальной шины.
Выглядит как лапша. Редакс тем же не нравится )
Выглядит как лапша. Редакс тем же не нравится )
YW
А, принцип шины мне знаком, просто не очень нравиться идея одной глобальной шины.
Выглядит как лапша. Редакс тем же не нравится )
Выглядит как лапша. Редакс тем же не нравится )
Ну это уже как нравится, можно разбить их начасти и будет у тебя много маленьких шин на каждое уникальное события
S
Ну и библиотеки типа Moxy и ViewModel из jetpack сохраняет стейт, то есть они восстанавливают твою шину в нужном виде
Moxy близко не смотрел, а ViewModel хранит только пока процесс жив. По-сути ViewModel за спиной имеет фрагмент с
Так что в качестве персиста на восстановлении приложения тоже не работает...
retainInstance.Так что в качестве персиста на восстановлении приложения тоже не работает...
S
Ну это уже как нравится, можно разбить их начасти и будет у тебя много маленьких шин на каждое уникальное события
Вот такое, и в ограниченном количестве (только по необходимости) я только за, чтобы по всем слоям данные между экранами не гонять )
A
скажите в MVVM использую android navigation jetpack - вопрос такой переходы между фрагментами лучше вызывать в фрагментах ИЛИ можно прокинуть в viewModel и там делать переходы??? ПЕреходы между фрагментами - это чья ответственность?
ну навигация это про изменения UI, как твой взгляд видит удобство так и управляй переходами
видел изощеренные способы навконтроллер пихать в презентер или инжектить айдишник навконтроллера и там как-то доставать через ссылки на родительские фрагменты
если прям хочется управлять переходами из презентера - делай просто заглушки во фрагментах и вызывай их из презентера\вьюмодел
я над таким не особо заморачиваюсь
видел изощеренные способы навконтроллер пихать в презентер или инжектить айдишник навконтроллера и там как-то доставать через ссылки на родительские фрагменты
если прям хочется управлять переходами из презентера - делай просто заглушки во фрагментах и вызывай их из презентера\вьюмодел
я над таким не особо заморачиваюсь
O
ну навигация это про изменения UI, как твой взгляд видит удобство так и управляй переходами
видел изощеренные способы навконтроллер пихать в презентер или инжектить айдишник навконтроллера и там как-то доставать через ссылки на родительские фрагменты
если прям хочется управлять переходами из презентера - делай просто заглушки во фрагментах и вызывай их из презентера\вьюмодел
я над таким не особо заморачиваюсь
видел изощеренные способы навконтроллер пихать в презентер или инжектить айдишник навконтроллера и там как-то доставать через ссылки на родительские фрагменты
если прям хочется управлять переходами из презентера - делай просто заглушки во фрагментах и вызывай их из презентера\вьюмодел
я над таким не особо заморачиваюсь
Ок
YW
Вот такое, и в ограниченном количестве (только по необходимости) я только за, чтобы по всем слоям данные между экранами не гонять )
Плюсую тоже такой подход использую, но встречал и противников этого подхода, типа в глобальном стейте прощу управлять обработкой
S
скажите в MVVM использую android navigation jetpack - вопрос такой переходы между фрагментами лучше вызывать в фрагментах ИЛИ можно прокинуть в viewModel и там делать переходы??? ПЕреходы между фрагментами - это чья ответственность?
Я логику навигации в ViewModel держу, только чтобы под юнит тесты подвести.
А сами конкретныые вызовы платформы уже происходят в фрагменте/активити по указанию из MVVM
А сами конкретныые вызовы платформы уже происходят в фрагменте/активити по указанию из MVVM
VS
Moxy близко не смотрел, а ViewModel хранит только пока процесс жив. По-сути ViewModel за спиной имеет фрагмент с
Так что в качестве персиста на восстановлении приложения тоже не работает...
retainInstance.Так что в качестве персиста на восстановлении приложения тоже не работает...
Так это уже не работает, view model другим способом уже сохраняется и переживает смену конфигурации
S
Так это уже не работает, view model другим способом уже сохраняется и переживает смену конфигурации
А смерть процесса?
VS
Смерть процесса нет, но у него уже есть способы восстановления состояния при смерти
S
Смерть процесса нет, но у него уже есть способы восстановления состояния при смерти
Хм, видимо упустил где-то, пока в RN ковырялся 🤔