CC BY
14
УДК 004.421
Шульгин Е.М. студент магистратуры 2 курса факультет «информационных технологий» Российский технологический университет
Россия, г. Москва
АРХИТЕКТУРНЫЙ ПАТТЕРН MODEL-VIEW-PRESENTER В
РАЗРАБОТКЕ ПОД МОБИЛЬНУЮ ПЛАТФОРМУ ANDROID
Аннотация:
Статья посвящена описанию результатов исследования архитектурных решений в области разработки приложений под мобильную операционную систему Android.
В статье рассматриваются основы приложений на базе мобильной операционной системы Android, а также архитектурные паттерны, применяемые при их разработке. Детально рассматривается паттерн Model-View-Presenter, выявляются его положительные качества и описывается общий подход к проектированию приложений на его основе. Также описывается процесс проектирования приложения на основе данного паттерна.
Ключевые слова: Программное обеспечение, интерфейс прикладного программирования, принципы проектирования, архитектура мобильных приложений, модель-представление-контроллер, модель-представление-презентер.
Shulgin E.M. master's degree student 2 course, faculty of information technology Russian University of technology Moscow, Russia
ARCHITECTURE PATTERN MODEL-VIEW-PRESENTER IN DEVELOPING FOR THE ANDROID MOBILE PLATFORM
Annotation:
The article describes the results of the research of architectural solutions in the field of application development for the mobile operating system Android.
The article discusses the basics of applications based on the Android mobile operating system, as well as the architectural patterns used in their development. The model-View-Presenter pattern is considered in detail, its positive qualities are revealed and the general approach to application design on its basis is described. The process of application design based on this pattern is also described.
Keywords: Software, application programming interface, design principles, mobile application architecture, model-view-controller, model-view-presenter.
ВВЕДЕНИЕ
Android — это портативная операционная система для коммуникаторов, планшетных компьютеров, электронных книжек, цифровых проигрывателей, наручных часов, нетбуков и смартбуков, основанная на ядре Linux, впервые выпущенная в сентябре 2008 года. На данный момент эта система установлена на большинстве продаваемых мобильных устройств в мире. Приложения под Android состоят из четырех основных компонентов:
Операция (Activity) представляет собой один экран с пользовательским интерфейсом. Например, в приложении для работы с электронной почтой одна операция может служить для отображения списка новых сообщений, другая - для составления сообщения и третья операция - для чтения сообщений. Несмотря на то, что операции совместно формируют связное взаимодействие пользователя с приложением по работе с электронной почтой, каждая из них не зависит от других операций. Любые из этих операций могут быть запущены другим приложением (если это позволяет приложение по работе с электронной почтой). Например, приложение для камеры может запустить операцию в приложении по работе с электронной почтой, которая составляет новое сообщение, чтобы пользователь мог отослать фотографию.
Служба (Service) представляет собой компонент, который работает в фоновом режиме и выполняет длительные операции, связанные с работой удаленных процессов. Служба не имеет пользовательского интерфейса. Например, она может воспроизводить музыку в фоновом режиме, пока пользователь работает в другом приложении, или же она может получать данные по сети, не блокируя взаимодействие пользователя с операцией. Служба может быть запущена другим компонентом, который затем будут взаимодействовать с ней, - например операцией.
Поставщик контента (Content provider) управляет общим набором данных приложения. Данные можно хранить в файловой системе, базе данных SQLite, в Интернете или любом другом постоянном месте хранения, к которому у вашего приложения имеется доступ. Посредством поставщика контента другие приложения могут запрашивать или даже изменять данные (если поставщик контента позволяет делать это). Например, в системе Android есть поставщик контента, который управляет информацией контактов пользователя. Любое приложение, получившее соответствующие разрешения, может запросить часть этого поставщика контента для чтения и записи сведений об определенном человеке.
Поставщики контента также используются для чтения и записи данных, доступ к которым внешним компонентам приложение не предоставляет.
Приемник широковещательных сообщений (Broadcast receiver) представляет собой компонент, который реагирует на объявления распространяемые по всей системе. Многие из этих объявлений рассылает
система — например объявление о том, что экран выключился, аккумулятор разряжен или был сделан фотоснимок. Объявления также могут рассылаться приложениями, — например, чтобы сообщить другим приложениям о том, что какие-то данные были загружены на устройство и теперь готовы для использования. Несмотря на то, что приемники широковещательных сообщений не имеют пользовательского интерфейса, они могут создавать уведомления в строке состояния, чтобы предупредить пользователя о событии "рассылка объявления". Однако чаще всего они являются просто "шлюзом" для других компонентов и предназначены для выполнения минимального объема работы. Например, они могут инициировать выполнение службой определенных действий при возникновении события.
Разработка под операционную систему Android долгое время являла собой программирование без использования каких-либо архитектурных решений. Это связано с тем, что самой компанией Google, разработавшей данную операционную систему, в свое время не было предложено никаких готовых архитектурных решений, библиотек и даже рекомендаций по правильному проектированию приложений. Всвязи с этим, с течением времени в среде андроид-разработчиков появлялись различные архитектурные идеи и подходы, из которых укоренились так называемые Model-View-Controller, Model-View-Presenter и Clean Architecture.
В ходе статьи будут рассмотрены каждые из них, а также детально остановлюсь на паттерне Model-View-Presenter, самом широко-используемом и применимом в среде android-разработчиков.
ЧАСТЬ 1. АРХИТЕКТУРНЫЕ ПОДХОДЫ В ANDROID
РАЗРАБОТКЕ
Model - View - Controller
Существование данного паттерна в андроид-разработке обусловлено попыткой его использования разработчиками, пришедшими в мир Android из Web-разработки.
Сам паттерн предлагает разделение приложения на 3 сущности, взаимодействующие друг с другом - View, Controller и Model.
Здесь модель получает и отдает данные, изменяя представление.
Представление отображает актуальное состояние модели.
Контроллер, получая запросы от представления, оповещает модель о необходимости изменения.
/
\
MODEL
CONTROLLER
Рисунок 1. Визуальное представление паттерна MVC.
Разделение на слои помогает разработчику следовать принципам SOLID - делает код менее связным, более поддерживаемым и тестируемым. SOLID включает в себя 5 основных принципов проектирования и ООП:
• S - SRP - Принцип единственной ответственности. Код базируется только на узкоспециализированных классах
• O - OCP - Принцип открытости/закрытости. Классы должны быть открыты для расширения, но закрыты для изменения
• L - LSP - Принцип подстановки Барбары Лисков. Объекты в программе должны быть заменяемыми на экземпляры их подтипов без изменения правильности выполнения программы
• I - ISP - Принцип разделения интерфейса. Следует избегать массивных интерфейсов, разделяя их на несколько частей.
• D - DIP - Принцип инверсии зависимостей. Следует программировать на уровне интерфейсов, а не конкретных реализаций.
В Android - разработке использования паттерна MVC весьма затруднительно. Это связано с различными попытками его внедрения под платформу и в нарушении принципа единственной ответственности слоя отображения - от всегда зависит от модели и должен сам реагировать на ее изменения.
Model - View - Presenter
Данный паттерн, как и MVC, предлагает разделение приложения на 3 сущности: Model, View и Presenter. Здесь представление все также отвечает за представление данных и получение данных от пользователя и модель реализует бизнес-логику и работу с данными. Отличие заключается в презентере, который является связующим звеном между представлением и моделью. Именно презентеру делегируется работа с данными пользователя, которую ему предоставляет представление, и именно он решает, что отображать представлению, в зависимости от модели данных.
VIEW
\
MODEL
PRESENTER
Рисунок 2. Визуальное представление паттерна MVP.
Паттерн MVP получил широкое распространение при разработке Android - приложений. Он позволяет разрабатывать слой представления максимально пассивным, что значительно улучшает процесс тестирования всех слоев приложения.
Clean Architecture
В основе данного паттерна лежит идея о дополнительном разделении слоев и вынесении безнес-логики в отдельный для нее слой, называемый "интерактором" или "юз-кейсом". Изначально данный подход презентовался известным американским программистом Робертом Мартином (Robert Martin) для общего назначения в сфере разработки программного обеспечения, но нашел широкий отклик в более узком кругу андроид-разработчиков. На рис. 3 изображена оригинальная схема из статьи Роберта Мартина «The Clean Architecture».
Рисунок 3. Визуальное представление паттерна Clean Architecture. Рассмотрим подробнее схему, представленную на рисунке 3. Как видим, архитектура состоит из четырех слоев, а стрелка указывает направление зависимости, что формирует следующее важное правило: ни один внутренний слой не должен ничего знать о внешнем. Здесь внешним
слоем считается слой представления данных, затем следует слой работы и управления представлением, затем слой сценариев взаимодействия и слой бизнес-объектов. При разработке андроид-приложений данный подход немного изменился и упростился, сохранив в себе три слоя - данных, бизнес-логики и представления. При этом для обеспечения независимости всех слоев, каждый из них оперирует своей моделью данных. На рисунках 4,5 изображены оригинальные схемы из статьи «Architecting Android...The clean way?» Fernando Cejas.
Presentation T Domain
Layer - Layer
i I
о
Mods! View ' 3 Regular Java
Presenter Objects
Data Layer
Рисунок 4. Визуальное представление паттерна Clean Architecture, адаптированного под мобильную разработку на платформе Android.
Как видно из рисунка 4, слой представления базируется на вышеупомянутом подходе Model-View-Presenter, что доказывает важность и универсальность данного подхода. Стоит также отметить, что, как правило, слой данных базируется на так-называемом паттерне "репозиторий", сущности, отвечающей за предоставление данных в одном и только одном виде (в англ. яз. называемом "stick of thruth").
Рисунок 4. Визуальное представление паттерна Repository.
Выводы
В ходе части 1 статьи были рассмотрены три архитектурных подхода, используемых при проектировании Android-приложений, описаны их основные идеи и подходы. Наиболее интересным и располагающим к рассмотрению для меня является паттерн Model-View-Presenter, т.к он может использоваться как отдельно, так и внутри более сложной концепции Clean
Architecture, по-сути, являясь универсальным инструментом в разработке Android-приложений.
ЧАСТЬ 2. АРХИТЕКТУРНЫЙ ПОДХОД MODEL-VIEW-
PRESENTER
Основная идея MVP заключается в разделении логики и UI-части приложения так, чтобы их можно было тестировать по отдельности и этот паттерн используется в Android в первую очередь. Рассмотри части паттерна подробнее.
Model. Есть два подхода к пониманию этой сущности. Кто-то оперирует понятием Model в смысле всего слоя данных в приложении: это и бизнес-объекты, содержащие логику, и способ их получения (Repository), и какие-то менеджеры и другие элементы, относящиеся к данным. Такой подход уместен, если говорить, что ваша система использует исключительно паттерн MVP и больше никаких элементов. Но мы решили сохранить слой данных в том виде, в котором он был изложен в принципах "чистой" архитектуры, поэтому под Model мы будем понимать обычные классы объектов, которые используются при взаимодействии View с делегатом. Плюс такого подхода заключается в том, что мы разделяем сущности, что может упрощать понимание. На конечный результат использование разных терминологий никак не влияет, но это нужно учитывать при изучении других источников.
View. View отображает данные, получаемые либо от Model, либо от делегата, что зависит от конкретного паттерна. View - эта та часть системы, которая видна пользователю, и которая взаимодействует с ним. При этом View не должна содержать логику, а передавать результаты взаимодействия делегату, который будет управлять этой View.
Presenter. Во-первых, Presenter управляет только одной View и взаимодействует с ней через специальный интерфейс. Во-вторых, View управляется только с помощью Presenter-а, не отслеживает изменение Model. Presenter получает все данные из Model, обрабатывает их в соответствии с требуемой логикой и управляет View.
Рисунок 5. UML-диаграмма архитектурного подхода Model-View-
Presenter.
Обычно экземпляр View создаёт экземпляр Presenter, передавая ему ссылку на себя. При этом Presenter работает с View в абстрактном виде, через его интерфейс. Когда вызывается событие View, оно вызывает конкретный метод Presenter, не имеющего возвращаемого значения. Presenter получает необходимые для работы метода данные о состоянии пользовательского интерфейса через интерфейс View и через него же передаёт в View данные из Модели и другие результаты своей работы. При этом с моделью он также работает через интерфейс модели, запрашивая у нее данные и получая результат для View. Сущность модели может отличаться в зависимоти от слоев. Например, из внешнего хранилища слой данных получил объект, но для того, чтобы отобразить информацию пользователю этот объект следует модифицировать. Тогда изначальный объект изменяется в слое данных, в Presenter попадает объект, готовы для отображения.
Чтобы рассмотреть данный архитектурный паттерн, необходимо разработать приложение, работающие с данными и показывающее информацию пользователю. В качестве такого приложения было принято решение разработать галерею случайных людей. Приложение должно получать данные из сети, используя соответствующее API, а также уметь отображать процесс загрузки и ошибки. Список людей должен содержать информацию о тридцати случайных личностях, их фото, имя, фамилию и адрес электронной почты.
Рисунок 6. UML-диаграмма архитектуры разрабатываемого
приложения.
На рисунке 6 представлена UML-диаграмма архитектуры приложения. Видно, что классы разделены на слои, согласно паттерну Model-View-Presenter.
В слое View содержаться необходимые интерфейсы, обеспечивающие контракт по отображению данных в приложении. Класс UsersListFragment является входной точкой и наследуется от одного из компонентов андроид-приложения. Он также содержит необходимые интерфейсы, так как несет обязанность за отображение данных.
Слой Presenter в данном случае представляется одним классом, но несет самую большую роль: он диктует, какие данные получать из слоя модели и отображать слою представления. Со слоем представления он общается через интерфейс IUsersListView, а со слоем данных - через IUsersListRepository, следуя правилам SOLID.
Слоем данных оперирует вышеупомянутая сущность Repository. Она отвечает за то, откуда брать данные, а также поставляет их в верхний слой. В данном приложении данные будут загружаться по сети интернет.
Разработка приложения
Первый этап в разработке - подготовка программной среды. При проектировании android-приложений самой популярной и востребованной средой является IDE "Android Studio", разработанная на основе известной IntelliJ IDEA от команды из компании JetBrains.
M
Create Android Project
P цып: tlJuM MrtU geprsLeaAppifcsbur
ProjiCCE luCÉUun
III P.ppLr»1inr,
P jrbuqn nw
Inchjfr m * (гы^^М^Пг,
Рисунок 7. Создание проекта. После создания проекта (рис. 7) была разделила его структура на две категории - presentation и data. В категории presentation будут расположены слои Presenter и View, в категории data - Model._
► О data
► El presentation
KApp
Рисунок 8. Категории проекта.
Далее следует продолжение формирования архитектурного каркаса приложения, следуя паттерну Model-View-Presenter - в категорию presentation добавляются подкатегории base и usersList. В категории base созданы два интерфейса ErrorView и LoadingView - при дальнейшем росте проекта они могут понадобиться и для иных задач._
9 rr*lti«|l . .. ■.■.-' n.dlili □ 1 ri. Tyripjl L Ксй 1 ÏM.pitH iJr. .!.j: f
* ■ i ru» * an. V ЕИиш-i! * ft mm Аждолрщ * EfeLllll ® & ПТПШПШТИ1 ■ a luur r h-nrVbn щ iMrt-nVÉB» » bl'Un!!« |ШЫ0Мт ■~i Am * Ни . ■ Ml m 1 — 1 Щ t( Щ ErrII-TV1 1 E '..Il bMNE'ftf'l 1 -..M ',I,IFFJ-„JI| t
* Цгш, 1 1
1,. IVÎPÎ" VTII*
« ' ID 1 JLJLI'iU'L,'-, 1 '
'..M L l-l^Lbûrl Llin : i till hldcLbadiiig 11
Рисунок 9. Общие интерфейсы слоя представления. В категории usersList созданы классы, отвечающие за реализацию
конкретной поставленной задачи - отображению списка людей. Сюда попадают специфичные для android-приложений классы (UsersListAdapter, Ц5ег5Ьл51Ргайтеп1), а также класс презентера и необходимый интерфейс.
▼ I ^ usersLîst
в !U sers ListView
. UsersListAdapter
- UsersListFragment
. U s ers List Près en ter
Рисунок 10. Классы слоя представления для реализации отображения
списка людей.
В категории data созданы интерфейс репозитория, через который presenter сможет получать данные, а также его реализацию, представленную на рис. 11. _ _ _ _
pacKaqi .ru.giraroig.ШЦузI^JUJJltPJTа import 10.reactivex*Single interface IUsersListRepository {
■■ getysôrsO: Single^List-^User»
¡Lin crtepr>;ita-|i Kt
£3 E Ш a. ru.ar>dro^... ища ЙЁ LI - iiltport —
Class UserslistRepository @Inject rcnstructor(
privatt val rcsratfiOataStiurce: IRemoteDataSource ) : ILtsersListRepository {
overncfe fun getllsersl): Single<Li&t<User>j { r-f='. reoioteDataSctgi ■ .getByRetrofitO .map { ii
parseResponselit)
}
1
P r- vat fun pa rseftsspo rise (response: Result); List<User> { return response.users
}
}
Рисунок 11. Классы слоя данных. Как было указано выше, основной логикой обладает слой Presenter. Именно он решает, когда отобразить процесс загрузки данных, ошибки или списка пользователей (рис. 12).
; i 10.reactive*.disposables^CompositeDispcsable import rii. android, my application, data. IUsersListRepository Import ru.android.myeppUcation.presentation,common. schedulersIoToMain
class UsersListPresenter (
private yal repository: IUsersListRepository ): MvpPresenter<lUsersListView>() {
pr ivate yal disposable - CompositeDisposable!)
override fun onFirstViewAttach() { supe . onFirstViewAttacM) start!)
>
fun start!) {
vi estate. showLoading!)
val observable = repository, getlisers!} .schedulersIoToMaini) »subscribe!
{ 11 fcist<User>|
viewstate.hideLoading!) view5i:ate.setData(xt)
},
{ i/j(?wSfate.showError() >
)
dj sppsabLe.add(observable)
>
fun stop!) {
disposable.cieart>
}
>
Рисунок 12. Реализация слоя Presenter. После успешного проектирования и создания приложения его исходный код компилируется и запускается на реальном устройстве.
Рисунок 13. Демонстрация процесса загрузки данных спроектированного приложения.
• Л 1*
My Application Мочу
ft
А
□-■пЬег □ impEDn
■ 11Ь* ! ы I гдаалйнм fiçAv ш
gurarvce çjerurd
роят E t. ре пяШмшяр!* еож
B4mmVfUll
игяпгр гщуечгчИ гтжп
cflyian scpMçi
lm^'il- 1и|1^^тгл<ч11г глпт
hclrT'i rajala
• ч*Ат l i ùft/л^лхт tpit. с ùm
£ mkHuel siasil*ï
О □
Рисунок 14. Демонстрация отображения случайных людей в спроектированном приложении.
Выводы
В части 2 статьи был подробно рассмотрен архитектурных подход Model-View-Presenter, выявлены его положительные качества и описан общий подход к проектированию приложений на его основе. Также было
спроектировано приложение, отображающие список случайных людей, в основу которого лег данный паттерн. На примере было показано разделение слоев в приложении и следование принципам SOLID. Проектировании android-приложений со следованием паттерну Model-View-Presenter улучшает его дальнейшую поддержку, делает структуру и код более ясным для восприятия, а также, за счет избавления от сильных зависимостей в коде и следованию правила программирования на уровне интерфейсов - более тестируемым.
ЗАКЛЮЧЕНИЕ
В статье были рассмотрены основы приложений на базе мобильной операционной системы Android, а также архитектурные паттерны, применяемые при их разработке.
Детально был рассмотрен паттерн Model-View-Presenter, выявлены его положительные качества и описан общий подход к проектированию приложений на его основе.
Также было спроектировано приложение, отображающие список случайных людей, в основу которого лег данный паттерн.
Использованные источники:
1. Дон Гриффитс, Дэвид Гриффитс - "Head First: Программирование для Android"- «Питер», 2016г - 704c.
2. Б. Харди, Б. Филлипс - Android - Программирование для профессионалов - «Питер», 2016. - 637 с.
3. Информационный сайт "Developer.Android". Режим доступа: https://developer.android.com/index.html (Проверено 22.06.2018)
4. Информационный сайт "Source.Android" Режим доступа: https://source.android.com/security/ (Проверено 22.06.2018)
