@Bringoff9 мар 2016 в 08:06

Расширяемый код Android-приложений с MVP

7 мин

52K

Проектирование и рефакторинг * Разработка мобильных приложений * Android *

Перевод

+11

Комментарии 9

@iamironz 9 мар 2016 в 08:27

Статья, в принципе, Америки не открывает, но лишний раз дает пощечину, чтобы не делать странных хаков в коде.
P.S.: тэги на ссылках не мешало бы поправить.

@nnesterov 9 мар 2016 в 10:01

А если (в случае с переворотом\пересозданием активити) фоновая операция закончится уже после того, как первая активити отвязалась, но до того, как вторая активити привязалась. Результат загрузки пропадет?

@senneco 9 мар 2016 в 14:09

Если посмотреть в исходники, то можно увидеть, что каждый раз, когда к Presenter биндится View, вызывается абстрактный метод updateView(). Автор предлагает в нём менять состояние View. Проблема такого решения в том, что если View окажется сложной и сможет одновременно отображать 2 состояния(например, progress + empty view или данные), то этот метод будет очень раздут. К слову, хотелось бы рассказать, что мы в Moxy решили эту проблему тем, что храним очередь команд для View, и когда View аттачится к Presenter, мы накатываем на неё эту очередь команд.

@megatron 9 мар 2016 в 11:01

Презентер всегда должен резолвить интерфейс, иначе это не MVP. Без интерфейса невозможно мокировать для тестов.
Не очень понятно, почему модель и вью в презентере сделаны через дженерики. Это ошибка. Сложные модели придется оборачивать, чтобы туда запихать.
Наличие в презентере AsyncTaskа тоже сомнительно. Но даже если закрыть на это глаза, явный косяк все равно есть — в onPostExecute вызывается CounterDatabase.getInstance().getAllCounters(), что точно не имеет права находиться в UI потоке.
Ну а больше всего меня бесит наличие классов MainView и CounterView. В андроиде под вью понимается UI-йный компонент. Пойди потом разбери в презентере, что такое bindView или updateView.

@Arturka 10 мар 2016 в 06:52

Презентер всегда должен резолвить интерфейс, иначе это не MVP. Без интерфейса невозможно мокировать для тестов.

Почему это? Во-первых, презентер редко используется как объект, который необходимо мокать, так как он обычно является простой логической обёрткой без андроидных классов. Ну и если надо мокать презентер, то мокито никто не отменял. Я лично вообще не вижу смысла в интерфейсах для презентера.

что точно не имеет права находиться в UI потоке.

Не такое однозначное мнение. Чтение из БД небольшого объёма данных не окажет значимого влияния на перфоманс. А вот асинктаск как раз проблема более серьезная.

Ну а больше всего меня бесит наличие классов MainView и CounterView. В андроиде под вью понимается UI-йный компонент.

А как называть, если паттерн Model-View-Presenter?

@senneco 10 мар 2016 в 07:15

Не понимаю, где вы видите здесь проблемы в использовании асинк тасок? Работает она, да работает. И даже дополнительно решает проблему обновления вью с главного потока. Если не хочется тащить rx, или велосипедить, то самый подходящий инструмент.

В остальном — всё так :)

@Bringoff 10 мар 2016 в 07:28

А вот асинктаск как раз проблема более серьезная.

Я понимаю, что хаять AsyncTask сейчас модно, но есть 2 момента:

Это пример. Для примера AsyncTask наиболее наглядный и простой.
Если посмотреть на комменарий к AsyncTask-у, то увидим:

It's OK for this class not to be static and to keep a reference to the Presenter, as this is retained during orientation changes and is lightweight (has no activity/view reference)

То есть. За что не любят асинхтаски — за то, что они содержат неявную ссылку на активити и при повороте экрана из-за этого бежит память, плюс оторваны от жизненного цикла. Здесь же презентер сохраняет свой стейт при перевороте, а у асинхтаска нету ссылки на view, так что обе проблемы отпадают. А без них это очень неплохая обертка над Thread-ом.

@konopko 9 ноя 2017 в 19:19

Всё круто только не билдится com.android.tools:common

@konopko 9 ноя 2017 в 19:34

Затупил немного, с guava всё хорошо)

Зарегистрируйтесь на Хабре, чтобы оставить комментарий