Size: a a a

Android Architecture

2017 January 27

AP

Alexey Pushkarev in Android Architecture
Andrey T
Дома хочется чем то другим позаниматься)
а если не хочется?)
источник

AT

Andrey T in Android Architecture
Сколько отраслей интересных вокруг
источник

EM

Eugene Matsyuk in Android Architecture
@sandrb может рассказать, как нам дали "все переписать" =))
источник

AT

Andrey T in Android Architecture
Посмотреть iOS, Web, Deep learning
источник

A

Artur in Android Architecture
Eugene Matsyuk
Да, хороший вопрос, на самом деле.
В истории со списком я хранил и в адаптере и в презентере. Но это было скорее обусловлено тем, что пользователь мог выйти с экрана, а получать новые сообщения должен был. Поэтому я весь скоуп оставлял в живых. И когда появлялась вьюшка, то выдавал ей актуальный список.
Дифф то никакой не нужно искать. Вы же все проводите через презентер, и там всегда самая актуальная информация. А потом уже презентер выдает команды вьюшке, в том числе и отдает новые сообщения. А вьюшка их уже в адаптер и список.

Хотя можно адаптер и в презентер хранить. Но тогда получается, что мы скрытно управляем вьюшкой еще и через адаптер. Из-за этого очень легко можно запутаться. Ну и Single Responsobility как бы страдает
Презентер должен знать, в какие позиции вставляются элементы, чтобы вызвать нужные notify. Отсюда и необходимость в diff, как я это вижу. Что, если обновляются те строки, на которые сейчас смотрит пользователь? Или вы просто всегда вызывали notifyDataSetChanged?
источник

AP

Alexey Pushkarev in Android Architecture
Eugene Matsyuk
Это практически нереально, что вам дадут просто переписать.
Я даже не припомню таких случаев. Бизнес просто не даст. А еще он хочет постоянно новые фичи. Да, они понимают, что нужно отрефакторить приложение, но сделать это нужно параллельно с новыми фичами.
Это жизнь
ну, тинькофф например уже 3-ю версию основного приложения сейчас тянет.
источник

EM

Eugene Matsyuk in Android Architecture
была постоянная балансировка с тех.долгом и бизнесом)
источник

AP

Alexey Pushkarev in Android Architecture
а до этого у них полностью переделывался дизайн, и наверняка с нуля писалось
источник

AB

Alexander Bilchuk in Android Architecture
Eugene Matsyuk
@sandrb может рассказать, как нам дали "все переписать" =))
я не рискну - сбт'эшные ассасины же бдят =)
источник

EM

Eugene Matsyuk in Android Architecture
Artur
Презентер должен знать, в какие позиции вставляются элементы, чтобы вызвать нужные notify. Отсюда и необходимость в diff, как я это вижу. Что, если обновляются те строки, на которые сейчас смотрит пользователь? Или вы просто всегда вызывали notifyDataSetChanged?
Так вьюшка сообщает презентеру о каком-либо событии (например, пользователь нажал на  удалении элемента), а презентер у себя обновляет список и говорит вьюшке удалить такую-то строчку
источник

A

Artur in Android Architecture
Eugene Matsyuk
Так вьюшка сообщает презентеру о каком-либо событии (например, пользователь нажал на  удалении элемента), а презентер у себя обновляет список и говорит вьюшке удалить такую-то строчку
Это понятно.

Презентер через репо из бд закинул во вью 20 элементов.
Пользователь проскроллил до 10.
В это время с сервера прилетают сообщения, которые нужно вставить во вью с 10 по 14 (итого во вью 25 элементов), а элементы вью 17 и 19 (по индексам вью) обновились. Причём, пользователь видит вьюшки с 10 по 20 на даный момент.

Можно просто стереть всё вставить всё. Можно делать аккуратнее с notify.
источник

А

Андрей in Android Architecture
А DiffUtils для RecuclerView не юзаете?
источник

D

Dmitriy in Android Architecture
Artur
Презентер должен знать, в какие позиции вставляются элементы, чтобы вызвать нужные notify. Отсюда и необходимость в diff, как я это вижу. Что, если обновляются те строки, на которые сейчас смотрит пользователь? Или вы просто всегда вызывали notifyDataSetChanged?
а DiffUtils не подойдет для задачи?
источник

EM

Eugene Matsyuk in Android Architecture
Artur
Это понятно.

Презентер через репо из бд закинул во вью 20 элементов.
Пользователь проскроллил до 10.
В это время с сервера прилетают сообщения, которые нужно вставить во вью с 10 по 14 (итого во вью 25 элементов), а элементы вью 17 и 19 (по индексам вью) обновились. Причём, пользователь видит вьюшки с 10 по 20 на даный момент.

Можно просто стереть всё вставить всё. Можно делать аккуратнее с notify.
ну так 20 пришло, 20 и закинули в адаптер. В чем проблема то?
источник

A

Artur in Android Architecture
Вот об этом тоже думал, но пока не прикрутил. Получается, презентер будет должен отдавать всегда полный список? Не "добавь 10 элементов, что пришли с сервера", а вот тут 300 элементов из бд и сервера, вы там разбирайтесь?
источник

A

Artur in Android Architecture
Eugene Matsyuk
ну так 20 пришло, 20 и закинули в адаптер. В чем проблема то?
Как сообщить адаптеру, что именно изменилось? Просто notifyDataSetChanged? Что, если я хочу указать конкретные элементы, которые обновились?
Список динамический, часть элементов уже есть (закгружена из БД), часть прилетает позже. Эти части могут иметь пересечения.
источник

EM

Eugene Matsyuk in Android Architecture
Artur
Как сообщить адаптеру, что именно изменилось? Просто notifyDataSetChanged? Что, если я хочу указать конкретные элементы, которые обновились?
Список динамический, часть элементов уже есть (закгружена из БД), часть прилетает позже. Эти части могут иметь пересечения.
То есть, если с БД прилетает 300 элементов, и все сразу же отображать не хочется, то как быть в таком случае, верно?
источник

A

Artur in Android Architecture
Eugene Matsyuk
То есть, если с БД прилетает 300 элементов, и все сразу же отображать не хочется, то как быть в таком случае, верно?
Да. Плюс, в какой-то момент могут прилететь данные с сервера. Но не все 300, а 20. А потом ещё 20. И часть из этих 20 совпадает с тем, что было в БД, а часть - нет. А 5 сообщений в БД вообще не было и их нужно вставить согласно сортировке и уведомить вью (а ещё и найти им место сперва)
источник

EM

Eugene Matsyuk in Android Architecture
Ага, понял вас.
Ну тут нужно подумать =)
источник

A

Artur in Android Architecture
=)
источник