Size: a a a

Android Architecture

2017 January 27

EM

Eugene Matsyuk in Android Architecture
Саше можно доверять в этом вопросе. Он был тимлидом в LinguaLeo, а потом в СберТехе. Так что, кто как ни он, знает как лавировать между бизнесом и тех.долгом))
источник

EM

Eugene Matsyuk in Android Architecture
Про рефакторинг снизу я больше имел в виду выкорчевывание с UI сначала работы с данными, потом бизнес-логики и т.д.
источник

AB

Alexander Bilchuk in Android Architecture
например, был жестокий и перегруженный CursorLoader прямо в Acitivity и мы аккуратненько перенесли это (по уровням данных и бизнес-логики) и оформили в виде RX?
источник

AB

Alexander Bilchuk in Android Architecture
тоже отличненько, думаю) правда, как мне кажется, потом вынесенные части тоже надо будет как-то рефакторить (не все же сразу красиво получится). Но и про вариант "сверху" можно сказать тоже самое)
источник

AB

Alexander Bilchuk in Android Architecture
все зависит от исходного кода и его запущенности) правильный вариант ответа - этот тот, при котором ничего не развалится при приемо-сдаточных испытаниях и после них)
источник

A

Artur in Android Architecture
Eugene Matsyuk
Вьюшка это
Пробовал и так, и так. Место адаптеру во вьюхе
Кейс. Данные приходят с сервера и кешируются в бд. Данные подгружается в бесконечную ленту страница за страницей.
Обычно данные сначала появляются из бд, отображаются во вью. В какой-то момент прилетают новые и нужно найти разницу между теми данными, что уже во вью и теми, что пришли из репозитория, затем уведомить адаптер, что именно поменялось (notifyItemChanged/inserted).

Стоит ли хранить 2 списка данных - в презентере и в адаптере? Как иначе презентер сможет найти diff? Не думаю, что этим должна заниматься view - это же уже логика отображения...
источник

G

Gerc in Android Architecture
источник

EM

Eugene Matsyuk in Android Architecture
Artur
Кейс. Данные приходят с сервера и кешируются в бд. Данные подгружается в бесконечную ленту страница за страницей.
Обычно данные сначала появляются из бд, отображаются во вью. В какой-то момент прилетают новые и нужно найти разницу между теми данными, что уже во вью и теми, что пришли из репозитория, затем уведомить адаптер, что именно поменялось (notifyItemChanged/inserted).

Стоит ли хранить 2 списка данных - в презентере и в адаптере? Как иначе презентер сможет найти diff? Не думаю, что этим должна заниматься view - это же уже логика отображения...
Да, хороший вопрос, на самом деле.
В истории со списком я хранил и в адаптере и в презентере. Но это было скорее обусловлено тем, что пользователь мог выйти с экрана, а получать новые сообщения должен был. Поэтому я весь скоуп оставлял в живых. И когда появлялась вьюшка, то выдавал ей актуальный список.
Дифф то никакой не нужно искать. Вы же все проводите через презентер, и там всегда самая актуальная информация. А потом уже презентер выдает команды вьюшке, в том числе и отдает новые сообщения. А вьюшка их уже в адаптер и список.

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

AP

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

AP

Alexey Pushkarev in Android Architecture
оставить кого-то на поддержку старого, тем временем другие разработчики пишут новое и потом постепенно юзеров мигрируем
источник

AP

Alexey Pushkarev in Android Architecture
это если хочется дизайн в корне сменить
источник

AT

Andrey T in Android Architecture
Alexey Pushkarev
а иногда проще написать приложение заново, чем переделывать всю архитектуру
Просто если приложение писали несколько лет нифига не проще
источник

AT

Andrey T in Android Architecture
И я говорю про рефакторинг без изменения UI
источник

AP

Alexey Pushkarev in Android Architecture
Andrey T
Просто если приложение писали несколько лет нифига не проще
ну, если писать новое, то можно из старого взять какие-то решения.
источник

AP

Alexey Pushkarev in Android Architecture
Зато новое можно писать сразу с более чистого подхода к архитектуре
источник

AP

Alexey Pushkarev in Android Architecture
но, на это конечно нужно одобрение менеджеров и прочих
источник

AT

Andrey T in Android Architecture
Alexey Pushkarev
но, на это конечно нужно одобрение менеджеров и прочих
Да, но донести до это сложно, с другой строны оно и понятно, фига деньги тратить если оно вроде и так работает, просто тут нужно взвешивать за и против, и понимать пользу твоего рефакторинга для бизнеса.
источник

AP

Alexey Pushkarev in Android Architecture
Andrey T
Да, но донести до это сложно, с другой строны оно и понятно, фига деньги тратить если оно вроде и так работает, просто тут нужно взвешивать за и против, и понимать пользу твоего рефакторинга для бизнеса.
можно дома рефакторить в свободное время, если сильно хочется и не лень ))))
источник

AT

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

EM

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