Главная страница » Что такое презентер android

Что такое презентер android

  • автор:

Android Architecture Patterns Part 2: Model-View-Presenter

It’s about time we developers start thinking about how we can apply good architecture patterns in our Android apps. To help with this, Google offers Android Architecture Blueprints, where Erik Hellman and I worked together on the MVP & RxJava sample. Let’s have a look at how we applied it and the pros and cons of this approach.

The Model-View-Presenter Pattern

Here are the roles of every component:

  • Model — the data layer. Responsible for handling the business logic and communication with the network and database layers.
  • View — the UI layer. Displays the data and notifies the Presenter about user actions.
  • Presenter — retrieves the data from the Model, applies the UI logic and manages the state of the View, decides what to display and reacts to user input notifications from the View.

Since the View and the Presenter work closely together, they need to have a reference to one another. To make the Presenter unit testable with JUnit, the View is abstracted and an interface for it used. The relationship between the Presenter and its corresponding View is defined in a Contract interface class, making the code more readable and the connection between the two easier to understand.

Model-View-Presenter Architecture Model-View-Presenter class structure

The Model-View-Presenter Pattern & RxJava in Android Architecture Blueprints

The blueprint sample is a ”To Do” application. It lets a user create, read, update and delete “To Do” tasks, as well as apply filters to the displayed list of tasks. RxJava is used to move off the main thread and be able to handle asynchronous operations.


The Model works with the remote and local data sources to get and save the data. This is where the business logic is handled. For example, when requesting the list of Task s, the Model would try to retrieve them from the local data source. If it is empty, it will query the network, save the response in the local data source and then return the list.

The retrieval of tasks is done with the help of RxJava:

The Model receives as parameters in the constructor interfaces of the local and remote data sources, making the Model completely independent from any Android classes and thus easy to unit test with JUnit. For example, to test that getTasks requests data from the local source, we implemented the following test:

The View works with the Presenter to display the data and it notifies the Presenter about the user’s actions. In MVP Activities, Fragments and custom Android views can be Views. Our choice was to use Fragments.

All Views implement the same BaseView interface that allows setting a Presenter.

The View notifies the Presenter that it is ready to be updated by calling the subscribe method of the Presenter in onResume . The View calls presenter.unsubscribe() in onPause to tell the Presenter that it is no longer interested in being updated. If the implementation of the View is an Android custom view, then the subscribe and unsubscribe methods have to be called on onAttachedToWindow and onDetachedFromWindow . User actions, like button clicks, will trigger corresponding methods in the Presenter, this being the one that decides what should happen next.

The Views are tested with Espresso. The statistics screen, for example, needs to display the number of active and completed tasks. The test that checks that this is done correctly first puts some tasks in the TaskRepository ; then launches the StatisticsActivity and checks content of the views:


The Presenter and its corresponding View are created by the Activity. References to the View and to the TaskRepository — the Model — are given to the constructor of the Presenter. In the implementation of the constructor, the Presenter will call the setPresenter method of the View. This can be simplified when using a dependency injection framework that allows the injection of the Presenters in the corresponding views, reducing the coupling of the classes. The implementation of the ToDo-MVP with Dagger is covered in another sample.

All Presenters implement the same BasePresenter interface.

When the subscribe method is called, the Presenter starts requesting the data from the Model, then it applies the UI logic to the received data and sets it to the View. For example, in the StatisticsPresenter , all tasks are requested from the TaskRepository — then the retrieved tasks are used to compute the number of active and completed tasks. These numbers will be used as parameters for the showStatistics(int numberOfActiveTasks, int numberOfCompletedTasks) method of the View.

A unit test to check that indeed the showStatistics method is called with the correct values is easy to implement. We are mocking the TaskRepository and the StatisticsContract.View and give the mocked objects as parameters to the constructor of a StatisticsPresenter object. The test implementation is:

The role of the unsubscribe method is to clear all the subscriptions of the Presenter, thus avoiding memory leaks.

Apart from subscribe and unsubscribe , each Presenter exposes other methods, corresponding to the user actions in the View. For example, the AddEditTaskPresenter , adds methods like createTask , that would be called when the user presses the button that creates a new task. This ensures that all the user actions — and consequently all the UI logic — go through the Presenter and thereby can be unit tested.

Disadvantages of Model-View-Presenter Pattern

The Model-View-Presenter pattern brings with it a very good separation of concerns. While this is for sure a pro, when developing a small app or a prototype, this can seem like an overhead. To decrease the number of interfaces used, some developers remove the Contract interface class, and the interface for the Presenter.

One of the pitfalls of MVP appears when moving the UI logic to the Presenter: this becomes now an all-knowing class, with thousands of lines of code. To solve this, split the code even more and remember to create classes that have only one responsibility and are unit testable.


The Model-View-Controller pattern has two main disadvantages: firstly, the View has a reference to both the Controller and the Model; and secondly, it does not limit the handling of UI logic to a single class, this responsibility being shared between the Controller and the View or the Model. The Model-View-Presenter pattern solves both of these issues by breaking the connection that the View has with the Model and creating only one class that handles everything related to the presentation of the View — the Presenter: a single class that is easy to unit test.

What if we want an event-based architecture, where the View reacts on changes? Stay tuned for the next patterns sampled in the Android Architecture Blueprints to see how this can be implemented. Until then, read about our Model-View-ViewModel pattern implementation in the upday app.

Jobs at upday

Written by Florina Muntenescu
Florina passionately works at upday as a Senior Android Developer.

Model View Presenter(MVP) in Android with a simple demo project.

Model–view–presenter (MVP) is a derivation of the model–view–controller (MVC) architectural pattern which mostly used for building user interfaces. In MVP, the presenter assumes the functionality of the “middle-man”. In MVP, all presentation logic is pushed to the presenter. MVP advocates separating business and persistence logic out of the Activity and Fragment

Differences between MVC and MVP

  • Controllers are behavior based and can share multiple views.
  • View can communicate directly with Model
  • View more separated from Model. The Presenter is the mediator between Model and View.
  • Easier to create unit tests
  • Generally there is a one to one mapping between View and Presenter, with the possibility to use multiple Presenters for complex Views
  • Listen to user action and model updates
  • Updates model and view as well


In an application with a good layered architecture, this model would only be the gateway to the domain layer or business logic. See it as the provider of the data we want to display in the view. Model’s responsibilities include using APIs, caching data, managing databases and so on.

The View, usually implemented by an Activity, will contain a reference to the presenter. The only thing that the view will do is to call a method from the Presenter every time there is an interface action.


The Presenter is responsible to act as the middle man between View and Model. It retrieves data from the Model and returns it formatted to the View. But unlike the typical MVC, it also decides what happens when you interact with the View.

Project Simple Workflow

Here, I try to illustrate the very basic of MVP pattern with simple demo android project which is available in GITHUB. The project has only one screen that have the username and email EditText and one TextView. When the user tries to input username or email, the input data will be shown in the top of the screen in TextView.

Введение в Model View Presenter на Android

Когда мы разрабатываем сложное приложение, мы обычно сталкиваемся с проблемами, которые, возможно, решались ранее и уже имеют довольно хорошие решения. Такие решения часто называют шаблонами. Обычно мы говорим о шаблонах проектирования и архитектурных схемах . Они упрощают разработку, и мы должны использовать их, когда это уместно.

Это руководство должно помочь вам понять важность хорошо спроектированного проекта и почему стандартной архитектуры Android не всегда достаточно. Мы обсудим несколько потенциальных проблем, с которыми вы можете столкнуться при разработке приложений для Android, и я покажу вам, как решить эти проблемы, улучшив тестируемость и надежность приложения с помощью шаблона Model View Presenter (MVP).

В этом уроке мы рассмотрим:

  • ценность применения известных архитектурных шаблонов в программных проектах
  • почему может быть хорошей идеей изменить стандартную архитектуру Android
  • ключевые понятия, лежащие в основе шаблона Model View Presenter (MVP)
  • различия между MVC и MVP
  • как MVP соответствует Android SDK

В первой части этого урока мы сосредоточимся на теории паттерна MVP. Вторая часть этого урока более практична.

1. Архитектура Android

Дизайн проекта должен быть предметом заботы с самого начала. Одной из первых вещей, которые мы должны рассмотреть, является архитектура, которую мы планируем принять, поскольку она будет определять, как различные элементы нашего приложения связаны друг с другом. Он также установит некоторые основные правила, которыми мы будем руководствоваться при разработке.

В целом, фреймворк или SDK ожидают, что что-то будет сделано определенным образом, но это не всегда подходит для проекта. Иногда не существует заранее определенного или правильного способа выполнения действий, оставляя проектные решения на усмотрение разработчика. Android SDK ожидает, что все будет сделано определенным образом, но этого не всегда достаточно или лучший выбор.

Хотя Android предлагает превосходный SDK, его архитектурные паттерны довольно необычны и могут легко помешать вам в процессе разработки, особенно при создании сложных приложений, которые необходимо тестировать и поддерживать в течение длительного времени. К счастью, мы можем выбрать один из нескольких архитектурных решений для решения этой проблемы.

В чем проблема?

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

Инструменты, предлагаемые Android, с макетами, операциями и структурами данных, похоже, направляют нас в сторону паттерна Model View Controller (MVC). MVC – это прочный, устоявшийся шаблон, целью которого является изоляция различных ролей приложения. Это известно как разделение интересов .

Эта архитектура создает три слоя:

  • модель
  • Посмотреть
  • контроллер

Каждый слой отвечает за аспект приложения. Модель реагирует на бизнес-логику , View – это пользовательский интерфейс, а Controller обеспечивает доступ View к Model .

Контроллер модельного вида

Но если мы тщательно проанализируем архитектуру Android, особенно связь между View (действия, фрагменты и т. Д.) И Model (структуры данных), мы можем заключить, что это нельзя считать MVC. Он сильно отличается от MVC и следует своим собственным правилам. Это, безусловно, может помешать вам, когда ваша цель – создать лучшее из возможных приложений.

Если говорить более конкретно, если мы подумаем о симбиотической связи между загрузчиками и операциями или фрагментами, вы поймете, почему мы должны уделять пристальное внимание архитектуре Android. Деятельность или фрагмент отвечает за вызов загрузчика, который должен получить данные и вернуть их родителю. Его существование полностью связано с его родителем, и нет разделения между ролью просмотра (действие / фрагмент) и бизнес-логикой, выполняемой загрузчиком.

Взаимосвязь погрузчика и активности

Как мы можем использовать модульное тестирование в приложении, в котором данные (Loader) так тесно связаны с представлением (Activity или Fragment), если самой сущностью модульного тестирования является тестирование наименьшего возможного фрагмента кода? Если вы работаете в команде и вам нужно что-то изменить в чужом коде, как вы можете найти проблему, если проект не придерживается известного архитектурного паттерна и что-то может быть буквально где угодно?

Каково решение?

Мы можем решить эту проблему путем реализации другого архитектурного паттерна, и, к счастью, Android SDK позволяет нам выбирать между несколькими решениями. Мы можем сузить наш выбор до решений, наиболее подходящих для Android. Шаблон Model View Controller (MVC) – хороший выбор, но еще лучше – тесно связанный шаблон Model View Presenter (MVP) . MVP был разработан с использованием тех же предпосылок, что и MVC, но с более современной парадигмой, которая создает еще лучшее разделение интересов и максимизирует тестируемость приложения.

Учитывая архитектуру Android (или ее отсутствие), мы можем сделать вывод, что:

  • Android не слишком беспокоится о разделении проблем
  • Лучше оставить архитектуру Android такой, какая она есть, что может привести к проблемам в будущем
  • отсутствие надлежащего архитектурного паттерна может сделать юнит-тестирование настоящей агонией
  • Android позволяет выбирать между несколькими альтернативными архитектурными паттернами
  • Model View Presenter (MVP) – одно из лучших решений для Android

2. Модель Viewer Presenter на Android

Как я уже упоминал ранее, разделение интересов – не самая сильная сторона Android. К счастью, шаблон «Представление модели» значительно улучшает это. MVP разделяет приложение на три слоя:

  • модель
  • Посмотреть
  • Ведущий

Каждый из них имеет свои обязанности, и связь между этими уровнями управляется докладчиком. Ведущий работает как посредник между различными частями.

  • Модель содержит бизнес-логику приложения. Он контролирует, как данные могут быть созданы, сохранены и изменены.
  • Представление – это пассивный интерфейс, который отображает данные и направляет действия пользователя в Presenter.
  • Ведущий действует как посредник. Он извлекает данные из модели и показывает их в представлении. Он также обрабатывает действия пользователя, переданные ему представлением.

Различия между MVC и MVP

Шаблон Presenter Model View основан на шаблоне Model View Controller. Так как они разделяют несколько концепций, их трудно различить. Ведущий и Контроллер имеют сходную роль. Они несут ответственность за связь между моделью и представлением. Тем не менее, контроллер не управляет Model и View так строго, как ведущий.

Различия между MVC и MVP

В паттерне MVC слой View несколько интеллектуален и может извлекать данные непосредственно из модели. В шаблоне MVP представление является полностью пассивным, и данные всегда доставляются в представление докладчиком. Контроллеры в MVC также могут совместно использоваться несколькими представлениями. В MVP представление и докладчик имеют взаимно-однозначное отношение, поэтому докладчик привязан к одному представлению.

  • В MVP представление не может получить доступ к модели.
  • Ведущий привязан к одному представлению.
  • Вид полностью пассивен в паттерне MVP.

Эти концептуальные различия делают то, что шаблон MVP гарантирует лучшее разделение задач, а также значительно повышает тестируемость приложения, способствуя большему разделению трех основных уровней.

Деятельность, фрагмент и просмотр объектов

Существует несколько толкований того, как MVP может быть реализован на Android. В целом, однако, действиям и фрагментам назначается роль View, и они отвечают за создание Presenter и Model. Представление также отвечает за поддержание модели и презентатора между изменениями конфигурации, информируя их о возможном уничтожении представления.

Другие объекты View, такие как RecyclerView, также могут считаться частью слоя View в MVP. Между представлением и докладчиком существует взаимно-однозначное отношение, и иногда в сложных ситуациях может потребоваться несколько докладчиков.

Что мы знаем до сих пор

  • Используя архитектурные и дизайнерские шаблоны, мы можем сделать разработку намного проще и прозрачнее.
  • В Android отсутствует хорошо структурированный архитектурный паттерн.
  • Без использования установленных шаблонов проектирования мы можем столкнуться с рядом трудностей, особенно проблем, связанных с ремонтопригодностью и тестируемостью.
  • Шаблон Model View Presenter увеличивает разделение задач и облегчает модульное тестирование.
  • Докладчик обеспечивает связь между представлением и моделью.
  • Представление отображает данные и направляет взаимодействие пользователя с докладчиком.
  • Модель отвечает за бизнес-логику приложения.
  • Роль просмотра в основном предполагается действием или фрагментом.


В следующем уроке мы реализуем шаблон «Представление модели» на Android. Мы проверим концепции, которые мы изучили в этом руководстве, и дополнительно исследуем сложности шаблона и то, что это значит для Android.

В конце этой серии вы сможете внедрить MVP в свои собственные проекты, создать собственную платформу или принять другие известные решения. Я надеюсь увидеть вас в следующем уроке.

Построение MVP архитектуры Android приложения: советы и технологии

mvp architecture Построение MVP архитектуры Android приложения: советы и технологии

Построение правильной архитектуры мобильного приложения имеет первостепенное значение для всего проекта. Уделив должное внимание качеству кода, масштабируемости системы, выбору API сервера и надежных технологий, можно избежать большинства проблем в дальнейшем.

Заложенная программистами архитектура напрямую влияет на то, понадобится ли постоянная поддержка и “ремонт” приложения или же все будет работать (и продолжать работать) как надо. Один из главных практических советов, которые мы ходим тут привести, заключается в эффективном планировании времени.

Случается так, что желание заслужить лояльность заказчика или простой непрофессионализм менеджеров проекта вгоняют команду в жесткие рамки, не давая возможности уделить нужное время для того, чтобы продумать архитектуру приложения.

Прямо противоположный результат не заставит себя ждать: куча багов, недоработок, трат и “перезаливок”. Поэтому необходимо все правильно спланировать (включая оценку объема работ) еще на начальном этапе проекта.

В этой статье мы поделимся эффективными подходами к созданию архитектуры Android приложений, в частности, принципами построения MVP (Model-View-Presenter) архитектуры.

Что такое MVP архитектура

Паттерн Model-View-Presenter является одним из шаблонов, используемых для проектирования архитектуры мобильного приложения. Model-View-Presenter имеет три слоя:

  • Model — представляет собой интерфейс, отвечающий за управление данными (включая кэширование данных и управление базами данных) приложения и “хранение” его бизнес-логики. В Android приложении роль Model часто выполняет REST API или база данных API.
  • Presenter — выступает посредником между Model и View и отвечает за обновление представления, реагируя на взаимодействие пользователей с обновлением модели. Вся логика представления находится в Presenter, который также контролирует Model и общается с View, что позволяет обновлять конкретный View, когда это нужно.
  • View — отвечает только за представление данных в виде, определяемым Presenter. Представление может быть реализовано с помощью любого Android виджета или всего, что может выполнять такие операции как показ ProgressBar, обновление TextView и заполнение RecyclerView.

Преимущества MVP архитектуры в Android приложении

MVP архитектура представляет собой эффективную архитектурную модель для разработки Android приложений. Основные преимущества паттерна Model-View-Presenter следующие:

  • Более простая отладка. Программистам проще делать отладку в приложении, так как MVP использует три разных слоя абстракций. Проводить модульное тестирование также проще, поскольку бизнес-логика полностью отделена от View.
  • Разрешает повторное использование кода. При построении MVP архитектуры разработчики могут многократно применять уже написанный код. Это становится возможным благодаря множеству представителей, которые контролируют Views. Такой подход более надежен по сравнению с использованием только одного presenter.
  • Эффективное разделение функциональностей приложения — под ним понимается отделение бизнес-логики и других частей от классов активности и фрагментов, которые, в свою очередь, лучше обеспечивают разделение функциональностей.

Практические советы по созданию MVP архитектуры

1. Улучшите способность Views к тестированию

Тестирование Views в Android является достаточно непростой задачей ввиду сложности фреймворка. Для улучшения процесса тестирования вам следует реализовать Passive View.

Данный паттерн представляет собой экран и компоненты со специфичным поведением приложения, выведенным в контроллер, что позволяет ему контролировать состояние виджетов. В рассматриваемой ситуации контроллером будет выступать presenter.

Для примера, если вам нужно реализовать фичу регистрации и отправления какой-либо заявки, включающую такие компоненты как форма с именем и паролем пользователи и кнопка “Отправить”/Отправить на рассмотрение” (“Send”/“Submit”), размещать логику валидации в presenter и только в нем, таким образом не усложняя view.

View, в свою очередь, должен содержать имя и пароль, которые он будет отправлять в presenter для проверки. Такой подход позволит значительно упростить процесс тестирования ваших Views.

2. Сделайте Presenter независимым от фреймворка

Следующий шаг в улучшении тестирования заключается в том, чтобы сделать Presenter независимым от фреймворка. Убедитесь, что он не зависит от Android классов. Если вы создаете ваше приложение на Java, то для написания Presenter используйте только ее зависимости.

Вы отделяете Presenter от деталей реализации (Android framework), благодаря чему можете писать тесты для Presenter без применения Robolectric (платформа для unit-тестирования Android приложений на JVM), а также быстрее запускать тесты на вашей локальной JVM без эмулятора.

3. Не создавайте обратные вызовы в интерфейсе Presenter

Presenter не должен содержать методы типа Action-lifecycle (onCreate (…), onStart (), onResume () и их двойные методы), так как они значительно усложняют его жизненный цикл активности.

Пользуйтесь случаем упростить жизненный цикл. Так, вместо вызова метода с тем же именем в обратном вызове жизненного цикла у вас есть возможность вызвать действие presenter. Например, (в конце Activity.onCreate (…) вы можете вызвать load () и т.д.).

4. Управляйте удаленными и локальными источниками данных в Model

Путем управления удаленными и локальными источниками данных в Model вы можете увеличить скорость работы вашего приложения. Например, вам нужно сделать так, чтобы приложение работало даже при отключении соединения с данными (в режиме офлайн).

Для этого вам следует провести выборку данных и хранить кеш таким образом, чтобы он мог быть запрошен при входе пользователя в систему. Чтобы выполнить данную задачу, можно создать три разных класса Model в форме удаленного источника данных, локального источника данных и репозитория данных.

Разместите логику, отвечающую за взаимодействие с presenter, в репозитории данных (data repository). Локальный класс хранения данных (local data storage class) может работать с кэшированными данными, тогда как класс удаленного источника данных (remote data source class) будет обрабатывать все удаленные вызовы API и ответы.

5. Используйте Dagger2 и RxJava для минимизации избыточности кода

Для того, чтобы свести избыточность кода к нулю и сделать Presenter независимым от жизненного цикла View, используйте такие библиотеки как Dagger2 и RxJava. Применение RxJava или ее аналогов позволит упростить базу кода.

В свою очередь, использование Dagger2 (библиотека внедрения зависимостей) упростит поведение компонентов путем введения зависимости между ними. Теперь рассмотрим внедрение зависимостей на примере его реализации при помощи Kotlin (о самом языке и его преимуществах мы поговорим позднее).

Сначала нужно добавить зависимости библиотеки Dagger2 в файл модуля build.gradle. Поскольку Dagger2 включает в себя обработчик аннотаций, следует применить плагин kotlin-apt к модулю.

apply plugin: ‘com.android.application’
apply plugin: ‘kotlin-android’
apply plugin: ‘kotlin-kapt’
apply plugin: ‘kotlin-android-extensions’

// …

dependencies <
// …

// Dagger 2
implementation «com.google.dagger:dagger:2.14.1»
kapt «com.google.dagger:dagger-compiler:2.14.1»
compileOnly «org.glassfish:javax.annotation:3.1.1»

6. Используйте правильные соглашения об именовании методов

Правильные соглашения об именовании методов, которые вы используете в своей базе кода, позволяют эффективно распределить обязанности. Как правило, в Presenter у вас есть две разные категории методов — действия (activities) и пользовательские события (user events).

Пользовательские события представляют собой действия, которые запускаются пользователем. Действия — это методы, которые будут содержать логику, с которой будет обновляться представление (View).

Например, load () даст presenter команду загрузить другую страницу в то время как пользователь скроллит страницы приложения.

То есть при взаимодействии с Presenter View будет понимать, когда проводить самообновление, когда пользователь прокручивает страницу до конца. Таким образом, имена должны подходить к действиям, которые должны быть запущены.

7. Напишите контракт, описывающий взаимодействие между View и Presenter

Если вам нужно реализовать новую функцию, будет разумным начать с написания контракта, который детально описывает взаимодействие View и Presenter.

Хорошим практическим примером является решение, предлагаемое Google (в репозитории Android Architecture). Оно состоит из интерфейса с внутренними интерфейсами, один для view и второй для presenter:

public interface SearchRepositoriesContract <
interface View <
void addResults(List<Repository> repos);
void clearResults();
void showContentLoading();
void hideContentLoading();
void showListLoading();
void hideListLoading();
void showContentError();
void hideContentError();
void showListError();
void showEmptyResultsView();
void hideEmptyResultsView();
interface Presenter extends BasePresenter<View> <
void load();
void loadMore();
void queryChanged(String query);
void repositoryClick(Repository repo);

Почему стоит использовать Kotlin для MVP архитектуры

Kotlin представляет собой статически типизированный язык программирования, который работает поверх JVM (Java Virtual Machine) полностью совместим с Java, что позволяет программистам использовать два языка в одном проекте. В прошлом году Kotlin был признан официальным языком для разработки Android приложений.

Kotlin создавался для решения нескольких задач, что вполне удалось. Во-первых, он наследует много преимуществ и характеристик Java, при этом убирая многие ее недостатки. Во-вторых, у него есть потенциал полностью заменить Java в будущем.

Несмотря на то что первая версия Kotlin была выпущена сравнительно недавно (в феврале 2016), на данный момент язык очень популярен, а его использование такими компаниями как Uber, Netflix, Coursera и Pinterest только подогревает к нему интерес.

По сравнению с Java, разработка мобильных приложений на Kotlin более простая. Код более читабельный и лаконичный, что заметно даже в самом простом примере:

Java code:

if (getActivity() instanceof LoginActivity)

((LoginActivity) getActivity ()). register ();

Kotlin code:

if (activity is LoginActivity)

activity. register ()

Одной из главных особенностей языка являются extension функции для стандартных Java коллекций. Благодаря ним уменьшается количество кода и снижается риск потенциальных ошибок, а работа с данными становится проще.

Также разработчикам легче осуществить последующую модификацию кода. Другая “полезность” Kotlin — его делегаты, которые способствуют использованию композиции на 100%.

Помимо указанных особенностей данного языка программирования, существуют и многие другие. Более того, JetBrains (российская компания, разработавшая Kotlin) постоянно работает над его улучшением, выпуская обновления и новые версии.

Подводя итоги, MVP архитектура имеет много преимуществ для разработки Android приложений. В статье мы постарались привести практические советы, которые помогут вам при ее построении. Надеемся, они будут вам полезны.)

Также спешим сообщить, что Smartum Pro расширяет команду разработчиков мобильных приложений и приглашает вас стать частью нашего дружного коллектива.

На данный момент у нас открыты вакансии Java и Android разработчиков, с которыми вы можете ознакомиться, перейдя по указанным ссылкам. Ждем ваше резюме!

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *