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

[iamironz]

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

[nnesterov]

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

[senneco]

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

[megatron]

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

[Arturka]

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

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

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

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

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

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

[senneco]

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

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

[Bringoff]

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

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

1. Это пример. Для примера AsyncTask наиболее наглядный и простой.
2. Если посмотреть на комменарий к 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]

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

[konopko]

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