В рейтинге участвует:

групп:

каналов:

Виртуальный сервер на SSD - недорого!

Аренда выделенных и виртуальных серверов (VDS/VPS), хостинг, аренда IP-адресов, администрирование, круглосуточная поддержка

qwarta.ru подробнее

Резервное копирование с проверкой на вирусы!!!

Удобный сервис создания резервных копий на любой сервер сети интернет. Отслеживайте изменения, проверяйте на вирусы. Надежно защитите свой бизнес!

go.backupland.com

Выбираете сервер? Любая конфигурация на заказ!

Аренда физических серверов любых конфигураций под любые запросы - 1С бухгалтерия, игровые сервера, нагруженные проекты, интернет-магазины!

qwarta.ru подробнее

Size: a a a

Android arch. components

394 membersпожаловаться на группу
2019 March 17

ST

Sasha Tainyuk in Android arch. components
Kopusha
ну, как бы VM активити и есть тот source of truth, который переживает VM фрагментов... Пример, Onboarding flow какой-то. На первом экране ввел адрес, на другом телефон, потом сфоткался и тд. Все это фрагменты. По ходу дела ты эту инфу где-то в активити VM собираешь, чтоб в конце сохранить/создать аккаунт.
На кой ляд так делать? Отдельный фрагмент для номера телефона, потом отдельно аватар. В чем прикол?
источник
16:40пожаловаться#1

K

Kopusha in Android arch. components
че ты приебался к номеру телефона, ну рили. За деревьями леса не видишь. Я пример на ходу придумал, ну представь, что там вместо номера телефона, каждый шаг это пиздецки нагруженный фрагмент с кучей логики и запросами. И вот всем этим шагам надо куда-то в общее место складывать.
источник
16:42пожаловаться#2

K

Kopusha in Android arch. components
по ссылке совет от гугла "SharedViewModel", но в реальности у фрагмента еще свой "viewmodel" и вот ты ими как-то жонглируешь.
источник
16:44пожаловаться#3

ST

Sasha Tainyuk in Android arch. components
Kopusha
че ты приебался к номеру телефона, ну рили. За деревьями леса не видишь. Я пример на ходу придумал, ну представь, что там вместо номера телефона, каждый шаг это пиздецки нагруженный фрагмент с кучей логики и запросами. И вот всем этим шагам надо куда-то в общее место складывать.
Да даже если во фрагменте куча всего, то результат вообще сохранить на диск лучше, а не во вм, которая может сдохнуть. Вот же радости будет когда минут 10 вбивал какие-то данные - случайно вышел и андроид все грохнул.  Потому что-то там сожрало всю память.
источник
16:47пожаловаться#4

K

Kopusha in Android arch. components
поэтому я упомянул, что это временные данные. Они должны пережить поворот экрана там или если быстро переключился между приложениями. А если он завтра в приложение вернется и ты ему какой-то длиннющий флоу где-то в середине покажешь, то это тупо.
источник
16:50пожаловаться#5

K

Kopusha in Android arch. components
Т.е. данные должны жить ровно пока жива какая-то flow root VM.
источник
16:50пожаловаться#6

K

Kopusha in Android arch. components
я все больше ловлю себя на мысли, что это scopes в даггере. Но там эти кастомные аннотации лепить придется..
источник
16:55пожаловаться#7

ST

Sasha Tainyuk in Android arch. components
Kopusha
поэтому я упомянул, что это временные данные. Они должны пережить поворот экрана там или если быстро переключился между приложениями. А если он завтра в приложение вернется и ты ему какой-то длиннющий флоу где-то в середине покажешь, то это тупо.
Берешь рум, вот тебе и решение без всяких костылей. )
источник
17:01пожаловаться#8

ST

Sasha Tainyuk in Android arch. components
Если что, то я inMemory вариант имел ввиду
источник
17:05пожаловаться#9

ST

Sasha Tainyuk in Android arch. components
Имхо конечно, но шарить вью модель между фрагментами имеет смысл наверное только, когда у тебя на экране одновременно 2 и более фрагментов. А так, хз, как-то  костыльно и не имеющие особого смысла. Хотя может и чего то не догоняю)
источник
17:18пожаловаться#10

ES

Eugene Shapovalov in Android arch. components
В скоупе достаточно хранить объект, в который записываются данные, и который можно сохранить/восстановить в Activity.
источник
17:25пожаловаться#11

NB

Nikita Bulygin in Android arch. components
Не нужно шарить данные через ViewModel активити, это плохое решение и плохо что Гугл его показывает в туториале по VM. Имхо, лучше во VM держать данные относящиеся только к данному экрану, результат взаимодействия( типо ввел номер телефона нажал далее) лучше хранить выше. Как выше сказали ин мемори рум подойдёт.
источник
19:13пожаловаться#12

a

and in Android arch. components
Yura Gromyk
Всем привет, ребята
У меня вопрос насчёт активити в приложении. Много из вас юзает сингл-активити? Мне просто кажется, что лучше дать отдельное активити авторизации и сплэшу, чтобы как-то всё было более разделено чтоли. Поделитесь, пожалуйста, вашими подходами к этому, ибо раньше завертал всё в активити, но со временем понял, что это далеко не наилучшее решение
Глянь, как это в Телеграме реализовано (одна активити, свой lifecycle для фрагментов, которые не фрагменты, а набор вьюсов, свой actionbar на базе простого framelayout). Дёшево и сердито, короче. https://github.com/DrKLO/Telegram/blob/master/TMessagesProj/src/main/java/org/telegram/ui/LaunchActivity.java
GitHub
DrKLO/Telegram
Telegram for Android source. Contribute to DrKLO/Telegram development by creating an account on GitHub.
источник
19:14пожаловаться#13

NM

Nikita Minin in Android arch. components
Kopusha
ну, как бы VM активити и есть тот source of truth, который переживает VM фрагментов... Пример, Onboarding flow какой-то. На первом экране ввел адрес, на другом телефон, потом сфоткался и тд. Все это фрагменты. По ходу дела ты эту инфу где-то в активити VM собираешь, чтоб в конце сохранить/создать аккаунт.
Я в таком кейсе провайдил в каждый фрагмент одну общую вью модель через viewmodelProviders.of(fragment.getActivity). Не скажу про это  со стороны архитектурной философии. Но задачу это решало чисто и на 100%
источник
19:39пожаловаться#14

K

Kopusha in Android arch. components
@nminin спасибо, мы как раз обсуждаем, как этого не делать 🙂.
источник
19:55пожаловаться#15

М

Михаил in Android arch. components
Kopusha
@nminin спасибо, мы как раз обсуждаем, как этого не делать 🙂.
Либо флоу скоуп, либо иметь в холдере данных метод clear ()
источник
20:13пожаловаться#16

М

Михаил in Android arch. components
Я бы второе выбрал
источник
20:13пожаловаться#17
2019 March 18

YG

Yura Gromyk in Android arch. components
Aleksandr Yurkovskiy
Это относится к теме чата?
Или Я чего-то не понимаю?
Почему же нет? Разве это не вопрос, который может привести к nav. component с jetpack? Тот же Cicerone здесь обсуждался
источник
01:23пожаловаться#18

YG

Yura Gromyk in Android arch. components
Yura Gromyk
Всем привет, ребята
У меня вопрос насчёт активити в приложении. Много из вас юзает сингл-активити? Мне просто кажется, что лучше дать отдельное активити авторизации и сплэшу, чтобы как-то всё было более разделено чтоли. Поделитесь, пожалуйста, вашими подходами к этому, ибо раньше завертал всё в активити, но со временем понял, что это далеко не наилучшее решение
Всем спасибо за ответы👍
источник
01:23пожаловаться#19

K

Kopusha in Android arch. components
Михаил
Либо флоу скоуп, либо иметь в холдере данных метод clear ()
👍
источник
02:03пожаловаться#20