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