Или делать минапи 21 и не беспокоиться вдвойне

Как это не беспокоится я из за этого не разрешаю в проект тащить лишние либы.

Dagger что то от гугла(карты аналитика реклама). Саппорт. И вот уже 65к методов

А дальше поздно пить Боржоми

Sergey а proguard?

Ну так ппогуард только для прод билда

Proguard в дебаге лишнее время сборки

а, дебаг.. ну там да, мин21

а как тестировщикам тестить на апи ниже 21, да и самому проверять работоспособность ?

я вот так стал делать и иногда приходится понижать чтобы проверить

Вы у себя везде строки в презентерах используете? Затем тестируете презентер чрез Robolectric?

Мм, кодом можете показать)

Некоторое время приходилось быть фул-стек девелопером и посать под веб. Так на таких фреймворках как Knockout и Angular познакомился с MVVM подходом. Очень понравилось. Поэтому когда гугл начал делать databinding в андроиде, то очень обрадовался. Даже начал пилить свой пет-проект, чтобы на нем опробовать как mvvm бедет работать на андроиде. К сожалению, все оказалось не так хорошо, как я надеялся.

Из общих проблем с MVP:
1. ЖЦ активити/фрагмента. ВьюМодел должна его переживать. Тут все просто - работают те же приемы, что и для презентера.
2. Андроидовский контекст внутри ВьюМодели. Тут опять же все те же холиварные вопросы что и для презентера.

Собственные проблемы MVVM в андроиде:
1. Навигация. В MVP простой способ навигации - это презентеру дернуть нужный метод у вьюшки. В MVVM, поскольку ВьюМодел о вьюшке вообще ничего не знает, то добавление такой сущности как Роутер/Навигатор становятся просто необходимостью.
2. Невозможно подписаться на изменения конкретных полей ВьюМодели. В чем неудобство:
а) Внутри самой вьюмодели. Допутим у нас есть два поля для ввода текста и кнопка отправки. Кнопка должна быть активной, если поля не пустые. У меня есть bindable свойсто, отвечающее за активность кнопки, но нету возможности сказать андроиду, чтобы он это свойсто перечитывал при изменении содержимого текстовых полей. Вместо этого я в сетерах bindable свойств, отвечающих за содержание текстовых полей должен указывать что поменялись не только они, но и свойство доступности кнопки (методы notifyPropertyChanged(BR.propertyName)).
b) Во вьюшке. Уже не так неудобно как в предыдущем варианте, но все же. Допустим у ВьюМодели есть свойство с текстом ошибки. Когда оно меняется, вьюшка должна показать тост с ее содержимым. Опять же, я не могу подписаться только на изменения ошибки. Я должен подписаться на саму вьюмодел, и мне в слушатель будут приходить все изменения, а я сам уже должен проверять это то свойство, что меня интересует, или нет? (И при уничтожении вьюшки нужно не забывать отписываться, иначе потечет память).
3. Изменения некоторых свойств могут происходить неявно. Сопровождение и тестирование такого кода усложняется. Хотя это уже больше не проблема самого MVVM, а того, как его используют.

После обсуждений у себя в команде, рассмотрений за и против, остановились на связке MVP + DataBinding. И то, с биндингом тоже нужно акуратно. А то у нас, например, есть любители такого на нем наворотить, что код, который можно было бы протестировать толко junit-ом, становится невозможно тестировать без Espresso.

По-разному.
Robolectric для подмены андроидовских классов

А я у себя заметил другое, что когда Context приходит в презентер (пытается придти), то значит презентер начинает заниматься не своим делом. Нужен ли Context презентере вообще чтобы выполнять свои задачи? Скорее всего слой представления будет лучше спроектирован, если будете пататься избежать зависимости от Context в презентере. Даже если тестирование не учитывать.

Кто-то пихает контекст в презентер? 0_о

(За чатом не слежу особо)

ну а что, часто в презентере есть зависимости на фреймворк, ну иногда это бывает удобно, например текст дефолтный показать какой нибудь getView().showErrorMessage(ContextCompat.getString(context, R.string.default_error));

но я это не пропагандирую, пример просто)

Создать enum с ошибками в View =)

Ну или интдеф, кому что