В
а если этот список на несколько тыщ элементов? )
Это уже другая проблема )
Мы столкнемся с тем, что как минимум эти тыщ элементов надо будет выгрузить )
Мы столкнемся с тем, что как минимум эти тыщ элементов надо будет выгрузить )
Size: a a a
2021 April 04
ДЩ
А если элементы удаляться в конце ?
пофиг что удаляться, ты берешь длину списка и дистаешь к индексу ~/количество эелементов* процент )
В
Тогда на самом сервере можно реализовать параметры take, skip и при загрузке приложения просто вытащить тот объем данных, в которых находился наш скрол
В
пофиг что удаляться, ты берешь длину списка и дистаешь к индексу ~/количество эелементов* процент )
А, хмм, ну в принципе да, если ввести процент то как-то да и можно
ДЩ
скинь примеры работ)
А
пацан к успеху шел
GK
Добрый день, вопрос по getx. Можно ли как-нибудь при открытии страницы перезапускать контролер по новой, т.е. вызывать onInit()?
GK
Или возможно при переходе на новую страницу вызывать onDelete() принудительно
EK
Уже не создаст
AG
final Stream<List<Stream<Message>>> chanels;
вот такую структуру для сообщений не очень было-бы использовать, как думаете?
тип сообщения летят с id комнаты и их нужно как-то раскидать по раздельным чатам
вот такую структуру для сообщений не очень было-бы использовать, как думаете?
тип сообщения летят с id комнаты и их нужно как-то раскидать по раздельным чатам
SH
Добрый день, вопрос по getx. Можно ли как-нибудь при открытии страницы перезапускать контролер по новой, т.е. вызывать onInit()?
Lazy с параметром fenix: true
SH
Или возможно при переходе на новую страницу вызывать onDelete() принудительно
Если он забинден на эту страницу (с которой уходишь), то так и должно быть
ДЩ
final Stream<List<Stream<Message>>> chanels;
вот такую структуру для сообщений не очень было-бы использовать, как думаете?
тип сообщения летят с id комнаты и их нужно как-то раскидать по раздельным чатам
вот такую структуру для сообщений не очень было-бы использовать, как думаете?
тип сообщения летят с id комнаты и их нужно как-то раскидать по раздельным чатам
каждая комната если подписчик то пусть забирают по своему id, почему бы нет
AG
каждая комната если подписчик то пусть забирают по своему id, почему бы нет
сокет один вообще со стороны клиента
вот думаю как его грамотно реализовать
вот думаю как его грамотно реализовать
AG
и в него летят все сообщения по всем комнатам
ДЩ
если stream широковещательный то норм
ДЩ
broadcast
Ю
Для каждой комнаты отдельный слушатель - это слишком. Скорее один слушатель для всего списка комнат, а потом уже в каждой по сообщениям