Что такое MVP

MVP – это способ разделения ответственности в коде приложения. Model предоставляет данные для Presenter. View выполняет две функции: реагирует на команды от пользователя(или от элементов UI), передавая эти события в Presenter и изменяет gui по требованию Presenter. Presenter выступает как связующее звено между View и Model. Presenter получает события из View, обрабатывает их(используя или не используя Model), и командует View о том, как она должна себя изменить.

У такого подхода к разделению ответственности есть ряд плюсов:

1. Сильно упрощается написание тестов к коду
2. Легко менять какую-то часть, не ломая при этом другую
3. Код разбивается на мелкие кусочки, за счёт чего он становится более понятным и читабельным

В то же время, конечно, есть и минусы:

1. Кода становится больше
2. К этому подходу нужно привыкать
3. На данный момент не сильно распространённый(но известный) подход, поэтому приходится всем рассказывать о нём

Привет, меня зовут Юра. И я, как и многие из вас, программист. Как известно, программисты — это не просто разработчики ПО, но создатели. Но, к сожалению, в повседневной работе сложно создавать что-то новое (особенно, когда ты занят мобильной разработкой). И это часто порождает желание собрать своего Франкенштейна (ну или велосипед, если вам так хочется), хотя бы в свободное время. Например, мне всегда хотелось сделать своего Франкенштейна, который будет выполнять за меня основную рутинную работу в Android-приложении.

И вот у меня недавно, наконец, нашлось свободное время на это дело (прим. автора: здесь можно просто за меня порадоваться)! Почитав разные статьи о том, что сейчас модно, или стало модным ещё много лет назад, я собрал для себя примерный список того, из чего будет состоять мой друг. И вот чему он у меня пока научился:

• Ходить! Он ходит в интернеты, достаёт оттуда данные, и приносит к себе
• Помнить! Если надо, он запомнит то, что взял в интернетах, может даже сперва обработать эти данные
• И вообще — выполнять несколько задач одновременно! Причём, не надо заморачиваться над тем, что вдруг наш монстрик решит, например, покувыркаться

Сколько разных элементов мне пришлось свалить в одну кучу, чтоб мой монстрик, по имени FunLib ожил! Тут собрались такие звёзды, как retrofit, eventbus, jobqueue… Но давайте по-порядку! Итак, кто за что отвечает в моём детище:

И на нашей улице переворачиваются грузовики с печеньками мороженым и мармеладками! Как уже было сказано, вышла новая версия API. И даже вкратце было рассказано, что же там есть новенького. Я, пока, не могу раскрыть всех улучшений, с точки зрения разработчика. Но некоторые особые плюсы разработки приложений, использующих карты, готов выделить.

Первое, и самое, наверное, вкусное — теперь можно во всю использовать fragment’ы, вместо MapView. Для этого достаточно вставить следующий код в разметку:

<fragment
  android:layout_width="match_parent"
  android:layout_height="match_parent"
  class="com.google.android.gms.maps.SupportMapFragment"/>

Во-вторых стало гораздо удобней работать с пинами. Правда, теперь нужно привыкнуть к тому, что они называются маркерами, и будет гораздо удобней. Теперь не нужно городить ItemizedOverlay, и тому подобное. Теперь достаточно просто выполнить метод addMarker(MarkerOptions options) с нужными параметрами, и маркер будет красоваться на указанной позиции.

Третий плюс — стало совсем удобно рисовать на карте объекты, которые без проблем будут зумиться и скролиться вместе с картой, без единой заморочки! Достаточно просто добавить фигуру(метод addPolygon(PolygonOptions options)) или линию(метод addPolyline(PolylineOptions options)) на карту, и всё. Это значит, что теперь без проблем можно закрасить страну, город, район… Свою машину?) Да всё, что угодно!