Введение
Общее описание
Структура приложения
Уроки
Описание библиотеки
Приложения

Общее описание

Основные принципы.

1. Библиотека используется в клиентской части архитектуры клиент-сервер. Поэтому предполагается, что на сервере реализуется вся необходимая (бизнес) логика.

2. Основой системы являются экраны, которые реализуются в виде Activity или Fragment.

3. Логика работы и визуализации экранов реализуется набором компонентов. Компоненты, в свою очередь, реализуют функционал соответствующих элементов андроида (RecyclerView, ViewPager, Spinner, и др.) Работа компонентов основана на патерне MVP. Связывание элементов (binding) представления и модели осуществляется по их наименованию (имени, id, ...).

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

5. Простота в понимании, понижение требований к уровню квалификации разработчика, повышение производительности.

Основная идея

Рассмотрим простой пример. В activity изображенной на рисунке имеется fragment (обведен красной линией).

Разметка указанного фрагмента простая имеется лишь RecyclerView с id recycler. Разметка для элементов списка находится в файле item.xml. Данные находятся по адресу URL = http://examples.delta.branderstudio.com/depro/news/list. Названия (id) полей в разметке совпадает с соответствующими названиями в данных.

Программирование функционала этого фрагмента может основываться на различных технологиях (шаблонах). Используем одну из распространенных (MVP).

Для этого нам нужно создать следующие классы:

Item – описывает все переменные, которые приходят с сервера и соответствующие геттеры и сеттеры.

Adapter – наследник RecyclerView.Adapter. Ему в конструкторе передаются данные, полученные от сервера типа List<Item>. Также имеется три, в общем несложных, метода: getItemCount – указывает количество элементов списка; onCreateViewHolder – инфлатит View из файла item.xml и создает на его основе MyHolder; onBindViewHolder - читает нужный элемент в списке и заносит данные в MyHolder (в результате они отображаются на экране). Кроме того имеется класс MyHolder в котором описываются все переменные в которые будут заноситься данные.

Presenter - содержит метод чтения данных с сервера с использованием технологий RxJava и Retrofit. Он реально и обращается к серверу по заданному URL. Полученные данные с использованием интерфейса iView передаются во фрагмент (класс MyFragment).

iView – интерфейс для взаимодействия презентера и MyFragment.

MyFragment – наследник класса Fragment. В нем и происходит объединение взаимодействия всех остальных классов. В частности он создает пустой список данных (типа List<Item>.) и адаптер, которому передает этот список. Обращается к презентеру для ввода данных и, после их получения, обновляет список, после чего дает команду адаптеру отобразить новые данные.

В совокупности эти пять файлов содержат сто и более строк кода. Да, код не сложный и в основном рутинный. Однако количество кода - есть количество кода. При этом код для аналогичного фрагмента с другими данными будет отличаться только URL, ресурсом RecyclerView и item.xml.

Поэтому у некоторых программистов возникает фантастическая мечта - иметь метод, которому будут переданы только уникальные данные, а остальное он сам доделает. Например, такой:

recycler(URL, R.id.recycler, R.layout.item);

И вот именно эту фантастическую мечту и реализует библиотека декларативного программирования. Например, для описания списка с использованием библиотеки нужно написать всего:

component(TC.RECYCLER, model(URL), view(R.id.recycler, R.layout.item_news))

Здесь component – название метода для описания различных компонентов; TC.RECYCLER – тип компонента (в данном случае указывает на использование RecyclerView); model(URL) – указывает, что данные для компонента находятся по адресу указанному в URL; view указывает id элемента разметки и лайаут с разметкой элементов списка.

Как видим, различие в количестве кода существенное.

Также следует отметить, что использование библиотеки позволяет понизить требования к квалификации программиста.

Экраны и компоненты

Основными элементами декларативного программирования являются экраны, которые могут реализовываться в виде активити или фрагмента.

В простейшем случае активити задается следующим образом:

activity(имя активити, id лайоута связанного с этим активити)

Пример:

activity(“splash”, R.layout.activity_splash)

Фрагмент задается аналогично.

Пример:

fragment(“auth_phone”, R.layout.fragment_auth_phone)

Допускается использование пользовательских экранов (описано в разделе "Экраны").

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

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

    .component(TC.RECYCLER,
        model(API.CATEGORIES),
        view(R.id.recycler, R.layout.item_home),
        navigator(start( 0, CATEGORY)));

Здесь TC.RECYCLER – тип компонента, который определяет способ обработки и представления данных. Имеются различные типы, например: PAGER_F, MAP, SPINNER и другие. По их названиям понятно как отображаются компоненты.

В компоненте модель задается параметром model(API.CATEGORIES) – указывает источник данных, параметр API.CATEGORIES – строка с адресом (URLом). Метод model имеет больше параметров, которые будут описаны ниже.

Представление (вид) задается параметром view(R.id.recycler, R.layout.item_home) . Его параметры, в свою очередь, задают id ресайклера и id соответствующего item лайоута.

Параметр navigator описывает реакцию на действия пользователя. В нашем случае он указывает, что при клике на itemView будет вызван экран CATEGORY.

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

Для некоторых компонентов имеется упрощенная нотация, например: componentMap, componentYoutube и пр.

Модель также имеет различные модификации, например, можно задавать методы: GET, POST, GET_DB, POST_DB, UPDATE_DB и др. В моделе можно указывать параметры для запросов, последействия (для запросов с методами POST) и другие параметры.

Представление также имеет несколько модификаций задания параметров view. И, естественно, имеется большой набор действий для навигатора.

Экраны, компоненты, а также элементы model и view могут иметь дополнительный функционал. Например, при описании активити можно указать способ анимации выхода:

fragment(CATEGORY, R.layout.fragment_category).animate(AS.RL);

Навигация в DePro

Кроме отображения данных библиотека обеспечивает и реакцию на действия пользователя и на изменения данных. Для этого служит navigator(handler(...), handler(...), handler(...) ...). Здесь handler() - обработчик, который описывает отдельное действие. Для некотрых обработчиков вместо обезличеного метода handler используются специальные названия, например, back(R.id.view) - указывает, что при клике на элемент разметки back(R.id.requisition) будет осуществлен возврат на предудущий экран. Более побробно навигатор описан в разделе "Навигация в DePro"

Разметка XML

В XML разметке используются стандартные элементы: LinearLayout, RelativeLayout, TextView, ImageView, RecyclerView и так далее.

В разметке XML можно использовать дополнительные к стандартным элементы. Например, ComponEditText, EditTextMask, Gallery и др. Они расширяют функционал стандартных элементов и, как правило, наследуются от них. Они описаны ниже в разделе “Дополнительные элементы”.

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

Биндинг происходит по совпадению наименований полей данных и наименований id элементов разметки (или наименований alias).

Если в данных имеются поля типа класс (в java обращение к таким переменным осуществляется через точку cl1.cl2.cl3), то название id элементов разметки также должно иметь такой же вид.

Данные

От сервера (интернет) данные приходят в формате json (см. Официальная домашняя страница формата на русском языке). Особенности работа с срвером в библиотеке ДеПро описана “Взаимодействие с сервером”. Данные могут приходить в форме записи - коллекция (множество) неупорядоченных пар ключ/значение заключенная в в фигурные скобки “{ }”, либо в форме массива - упорядоченного множества значений заключенных в квадратные скобки “[ ]”. Эти данные преобразуются во внутренний формат записей и списка (ArrayList) записей с которыми и работают компоненты.

Допускается передавать с сервера данные в формате:

{“data”:данные в указанных выше формах (запись или массив), “error”:запись с сообщением об ошибке}

Сообщения об ошибках с сервера поступают с любым кодом кроме 200. В этом случае сообщение оформляется в виде записи, либо в форме {“error”:запись с сообщением об ошибке}

Структура “запись с сообщением об ошибке” не регламентируется. Эти данные связываются с экраном (или вьюшкой на экране) диалога об ошибке. Далее (в разделе Структура приложения) будет описано как задавать экран или вьюшку диалога об ошибке.

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

Остальные источники данных передают и хранят их во внутреннем формате.

ВНИМАНИЕ.

Так как связывание данных осуществляется по совпадению названия поля в записи с названием id элемента разметки, то при отсутствии поля в записи в представлении значение элемента разметки не будет изменено. Поэтому в записи должны быть поля для всех элементов разметки, которые нужно отображать. Если значение отсутствует, то нужно передавать пустое значение (“”, null, 0 и т.д.). Это важно для таких виджетов у которых представления используются для разных наборов данных. Например, RecyclerView.

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

Сообщения

Имеется два типа сообщения: 1) Сообщения системы и 2) Сообщения данных.

Сообщения системы выводятся в логи. Тег задается при формировании параметров приложения. По умолчанию сообщения сети выводятся с тегом SMPL_NET, а общие сообщения системы с тегом SMPL_APP. Например, "Не найден RecyclerView в (имя экрана)" возможная причина - id указанный в DeclareScreens не соответствует id в разметке.

Перечень сообщений приведен в приложении.

Сообщения об ошибках данных выводятся в отдельный диалоговый экран или View в разметке экрана. Более подробная информация о диалоговых окнах приведена в разделе"Диалоги".

Лучше пакета DePro может быть только искусственный интеллект
Задать вопрос
Отправить вопрос