Size: a a a

Android Architecture

2017 January 27

AB

Alexander Bilchuk in Android Architecture
(еще очень от команды тестирования зависит)
источник

AP

Alexey Pushkarev in Android Architecture
Zahar Zolotarev
фух) дочитал)
и у меня созрел вопрос: Как вы натягиваете любимую архитектуру на легаси код в котором нужно делать новый функционал?
Очевидные варианты:
1) Старый код по возможности не трогается, новый пишется с применение новый архитектуры
2) Сначала переписываете рефакторинг старого кода, потом только новый функционал.
3) Свой вариант?)
1), когда есть время старый код рефакторю на новое
источник

AP

Alexey Pushkarev in Android Architecture
Alexander Bilchuk
(еще очень от команды тестирования зависит)
О, Александр из LinguaLeo 😏👍
источник

AB

Alexander Bilchuk in Android Architecture
:[ :)
источник

M

Marty in Android Architecture
Sergey
ответьте опытные разработчики:
RecyclerAdapter в презентере создавать или во view ?
щас вот так (в презентере):

public void createAdapter() {
       mRecyclerAdapter = new RecyclerAdapter(CarOfferList);
       view.attachRecycleAdapter(mRecyclerAdapter );    <--callback во view
   }
я бы сказал так:
презентер готовит и передаёт вью данные, и презентер не должен знать каким образом вью будет их отображать (возможно вообще ничего не делать)
т.е. вью может выводить данные в RecyclerView, потом тз поменяется на viewpager, потом поменяется на просто вывод сплошным текстом в TextView
а RecyclerAdapter это такое жёсткое уточнение и ограничение на работу вью
источник

EM

Eugene Matsyuk in Android Architecture
Alexey Pushkarev
О, Александр из LinguaLeo 😏👍
Мы вместе с Сашей работали в LinguaLeo =)
источник

EM

Eugene Matsyuk in Android Architecture
Alexander Bilchuk
Все зависит от бизнес-задачач. По поему опыту: либо 1й вариант, либо начинать потихоньку переписывать сверху-вниз (начиная с рефакторинга вьюшек). Лучше всего - когда есть задача доработать какаие-то экраны, параллельно с этим можно сделать мини-рефакторинг этой части (скажем разделить монстроподобный активити на View-Presenter). Потом уже бизнес логику из презентера выносить в интеракторы/менеджеры, и т.д. Что-то более жесткое делать может обернуться тем, что все сломается и заказчик будет несколько недоволен.
Zahar Выше писали про это)
Я бы начал с низа, наоборот) Сначала отделяем получение данных, потом бизнес-логику и т.д.
@sandrb Саш, почему сверху думаешь?)
источник

PS

Pavel Sukhoterin in Android Architecture
а правда что лингволео работает на реакте?)
источник

EM

Eugene Matsyuk in Android Architecture
Pavel Sukhoterin
а правда что лингволео работает на реакте?)
шо???
источник

AP

Alexey Pushkarev in Android Architecture
Eugene Matsyuk
Мы вместе с Сашей работали в LinguaLeo =)
👍а я все думал зачем скроллбар в дравер меню?)))
источник

PS

Pavel Sukhoterin in Android Architecture
источник

PS

Pavel Sukhoterin in Android Architecture
я не слушал, но в описании
источник

EM

Eugene Matsyuk in Android Architecture
а, ну может где-то и применяется
но точно не в андроиде
источник

EM

Eugene Matsyuk in Android Architecture
Sergey
ответьте опытные разработчики:
RecyclerAdapter в презентере создавать или во view ?
щас вот так (в презентере):

public void createAdapter() {
       mRecyclerAdapter = new RecyclerAdapter(CarOfferList);
       view.attachRecycleAdapter(mRecyclerAdapter );    <--callback во view
   }
Вьюшка это
Пробовал и так, и так. Место адаптеру во вьюхе
источник

EM

Eugene Matsyuk in Android Architecture
источник

AB

Alexander Bilchuk in Android Architecture
Pavel Sukhoterin
а правда что лингволео работает на реакте?)
без понятия - мы оттуда переметнулись в 2015ом
источник

AB

Alexander Bilchuk in Android Architecture
Eugene Matsyuk
Zahar Выше писали про это)
Я бы начал с низа, наоборот) Сначала отделяем получение данных, потом бизнес-логику и т.д.
@sandrb Саш, почему сверху думаешь?)
Можно и снизу - но тогда нужно быть очень уверенным в тестировщиках. Плюс  руководтво должно дать на это время напрямую. Сам по себе рефакторинг для конечного пользователя никакого value не несет. А вот совместить рефакторинг и доделку UI (там попросили кнопки добавить, новые проверки и т.д.). Плюс, если прямо код совсем не очень - то при переделке низов придется сразу переделывать UI (либо добавлять временные промежуточные уровни, прокси, бриджи), что может повлияться на стабильность всего приложения.
источник

AB

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

AB

Alexander Bilchuk in Android Architecture
Но, как писал выше, решение с какой стороны переписывать должно быть основано на бизнес-задачах. Универсального решения нет)
источник

AB

Alexander Bilchuk in Android Architecture
Если прямо нужно выкинуть и сделать полностью новый экран и новую бизнес логику к нему, и на это дается достаточно времени - то более правильно (на мой взгляд) будет вести разработку "от основания" - от низов :) То есть "как положено"
источник