Приложение построено на базе архитектуры, называемой «Модель-Представление-Контроллер», или сокращенно MVC (Model-View-Controller). Согласно канонам MVC, каждый объект приложения должен быть объектом модели, объектом представления или объектом контроллера.
o Объект модели содержит данные приложения и «бизнес-логику». Классы модели обычно проектируются для моделирования сущностей, с которыми имеет дело приложение — пользователь, продукт в магазине, фотография на сервере, вопрос «да/нет» и т. д. Объекты модели ничего не знают о пользовательском интерфейсе; их единственной целью является хранение и управление данными. В приложениях Android классы моделей обычно создаются разработчиком для конкретной задачи. Все объекты модели в приложении составляют его уровень модели.
o Объекты представлений умеют отображать себя на экране и реагировать на ввод пользователя — например, касания. Простейшее правило: если вы видите что-то на экране — значит, это представление. Android предоставляет широкий набор настраиваемых классов представлений. Разработчик также может создавать собственные классы представлений. Объекты представления в приложении образуют уровень представления.
o Объекты контроллеров связывают объекты представления и модели; они содержат «логику приложения». Контроллеры реагируют на различные события, инициируемые объектами представлений, и управляют потоками данных между объектами модели и уровнем представления. В Android контроллер обычно представляется субклассом Activity, Fragment или Service.
На рис. 9 показана передача управления между объектами в ответ на пользовательское событие — такое, как нажатие кнопки. Стоит обратить внимание на то, что объекты модели и представлений не взаимодействуют друг с другом напрямую; в любом взаимодействии участвуют «посредники» - контроллеры, получающие сообщения от одних объектов и передающие инструкции другим.
Рис. 9. Взаимодействия MVC при получении ввода от пользователя
На рис. 10 изображена диаграмма приложения, иллюстрирующая связи между объектами.
Рис. 10. Диаграмма приложения
1) Уровень модели.
Класс Card, в котором содержится информация о карте. С каждой картой связаны: идентификационный номер, само слово, изображение, стандартный звук. Также в карте для каждого языка содержаться сведения о записанных пользователем звуках – имена файлов, в которых они хранятся, и какой звук должен воспроизводиться: стандартный или записанный.
Класс CardLab хранит сведения о картах. Класс Settings хранит сведения о настройках. Класс SingletonAudioPlayer используется для воспроизведения звуковых файлов. В классе FlashCardsJSONSerializer содержатся методы сохранения и загрузки настроек и пользовательских звуков.
Классы CardLab, Settings, SingletonAudioPlayer являются синглетными (singleton) классами. Такие классы допускают создание только одного экземпляра. Экземпляр синглетного класса существует до тех пор, пока приложение остается в памяти, так что при хранении списка в синглетном объекте данные остаются доступными, что бы ни происходило с активностями, фрагментами и их жизненными циклами.
2) Уровень контроллера представлен двумя активностями и фрагментами.
Код приложения написан на базе фрагментов, так как они обладают рядом преимуществ по сравнению с активностями, включая гибкость при построении и представлении пользовательских интерфейсов.
3) Уровень представления состоит из виджетов, заполненных по
содержимому файлов макетов. Макет определяет набор объектов пользовательского интерфейса и их расположение на экране. Макет формируется из определений, написанных на языке XML. Каждое определение используется для создания объекта, выводимого на экране (например, кнопки или текста). На рис. 11 в качестве примера показано содержимое файла dialog_slideshow_settings.xml и пользовательский интерфейс, определяемый разметкой в нем.
Рис. 11. Файл dialog_slideshow_settings.xml и интерфейс, определяемый им.