Android. Программирование для профессионалов. 4-е издание

20sp
3dp
name="AppTheme"
parent="
Theme.AppCompat.Light.DarkActionBar
">
name="colorPrimary">@color/colorPrimary
name="colorPrimaryDark">@color/colorPrimaryDark

name="colorAccent">@color/colorAccent
Другие архитектуры: зачем они нужны?
Во всех приложениях, написанных вами до сих пор,
используется простая версия MVC. И до сих пор — если мы
хорошо справились со своим делом — все приложения
выглядели вполне логично. Зачем что-то менять? В чем
проблема?
Архитектура MVC в том виде, в каком она применяется в
книге, хорошо подходит для небольших простых приложений. В
нее легко добавляются новые функции, и она позволяет легко
представить взаимодействие между частями приложения. MVC
закладывает надежную основу для разработки, позволяет
быстро построить работоспособное приложение и эффективно
работает на ранних стадиях работы над проектом.
Проблемы начинаются тогда, когда размеры вашей
программы выходят за рамки примеров, приведенных в книге,
как это происходит практически во всех программах. Большие
фрагменты и activity трудно расширять, и в логике их работы
трудно разобраться. На реализацию новых возможностей и
исправление ошибок уходит больше времени. На какой-то
стадии контроллеры необходимо разделить на меньшие, более
удобные части.
Как это сделать? Определите различные операции,
выполняемые большим классом контроллера, и выделите

---

каждую операцию в отдельный класс. Вместо одного большого
класса появятся экземпляры нескольких классов, которые будут
совместно выполнять общую работу.
Как определить эти разные задания? Ответ на этот вопрос
лежит в определении архитектуры. Такие описания, как
«Модель — Представление — Контроллер» (MVC) и «Модель —
Представление 
— 
МодельПредставления» 
(MVVM),
используются в качестве ответов на высоком уровне. Однако в
конечном итоге на этот вопрос всегда отвечаете только вы, и
итоговая архитектура определяется только вами.
Приложение BeatBox построено на базе архитектуры MVVM.
Нам архитектура MVVM очень нравится, потому что она
отлично справляется с вынесением большого объема рутинного
кода контроллера в файл макета, где вы сразу видите, какие
части интерфейса являются динамическими. В то же время
содержательный динамический код контроллера выносится в
класс модели представления, что упрощает его тестирование и
проверку работоспособности.
Величина 
модели 
представления 
всегда 
должна
определяться здравым смыслом. Если ваша модель
представления будет слишком большой, ее можно разбить на
несколько частей. Ваша архитектура принадлежит только вам, и
никому другому.