Работа с данными в App Inventor

Проблема работы с данными в App Inventor связана с тем, что поля ввода в блоках и на панели свойств являются однострочными. Это наводит на мысль о том, что для создания данных вручную лучше использовать сторонний текстовой редактор.

Редактировать текст можно как на самом устройстве Android, так и на PC, что удобнее. Не все редакторы позволяют сохранять файлы на подключенное к PC устройство Android, но популярные это делать умеют, что избавит от постоянного копирования файлов между PC и Android.

В каком формате создавать данные? Существует два типа контейнеров данных - последовательные и ассоциативные. Для доступа к данным в последовательном контейнере используются числовые индексы, а в ассоциативном - ключи (в строковом формате). Преимущество ассоциативных контейнеров (массивов, списков и др.) состоит в том, что для доступа к данным можно использовать название нужного поля и не требуется учитывать порядок следования данных.

Предположим, в Excel мы создали таблицу с полями Name, Telephone, Address. Если экспортировать её в формат CSV, то на выходе получатся данные в формате с разделителем:

Name1; Telephone1; Address1
Name2; Telephone2; Address2
...
NameN; TelephoneN; AddressN

В этом формате присутствуют только данные, которые косвенным образом указывают на соответствующие им поля. Если последовательность данных изменится (что-то удалили, что-то добавили, что-то поменяли местами), то придётся вносить изменения и в алгоритм их получения. Если же указанную выше таблицу экспортировать в формат xml, то на выходе получим такой формат:

<Record>
<Name>Name1</Name>
<Telephone>Telephone1</Telephone>
<Address>Address1</Address>
</Record>
<Record>
<Name>Name2</Name>
<Telephone>Telephone2</Telephone>
<Address>Address2</Address>
</Record>
...
<Record>
<Name>NameN</Name>
<Telephone>TelephoneN</Telephone>
<Address>AddressN</Address>
</Record>

Объем файла данных увеличился, так как в нём хранятся не только данные, как в примере выше, но и названия полей, что устраняет зависимость алгоритма получения данных от порядка их следования. Значение поля Name будет получено по обращению к тегу <Name> и неважно, стоит ли оно до поля Address, после него или где-то ещё. Алгоритм зависит лишь от вложенности тегов и названий полей. Ассоциативный ключ (в данном случае это имя тега) даёт возможность задать осмысленное название полю. Название поля Telephone сразу говорит о том, что в нём хранится номер телефона, а что хранится в индексе 2? Для этого нужно будет открыть файл данных и найти это поле. А если поле имеет индекс 20, то устанешь его искать в строке.

Формат JSON также является ассоциативным, но он несколько сложнее для восприятия, особенно в строковой записи. Каждый формат данных имеет преимущества и недостатки, из чего и следует их многообразие. Форматы данных с разделителями сложны для восприятия и ручного редактирования, но удобны при использовании в алгоритмах автоматизации.

Обратите внимание на то, что для удобства работы с одними и теми же данными используются разные форматы и разное их визуальное представление. В табличной форме Excel удобно создавать данные, а в формате xml - их хранить и обрабатывать. Данные можно вручную создавать и в формате xml, но это будет не так удобно. Визуальное представление и формат данных кажется чем-то несущественным, но лишь до того момента, пока кто-то в очередной раз не пришлёт таблицу в Word или реквизиты компании в виде скана.

Асоциативные контейнеры сложнее последовательных, но они предоставляют большую гибкость, так как в качестве ключа можно указать строковое представление числа, а при необходимости организовать доступ к данным в них по индексу.

Для обработки данных в формате xml в AI используется метод XMLTextDecode компонента Web, который возвращает список пар, например, при получении строки

<name>Peter</name>

он вернёт пару (name, Peter), значение которой можно получить при помощи блока списка "look up in pairs".

Рис. 1. Декодирование данных в формате xml.

При получении данных в виде

<item>
<width>100</width>
<height>50</height>
</item>

декодер вернёт пару (item,data), где data - список пар, состоящий из элементов (width,100) и (height,50)

На рис. 1 название поля "name" указано в виде строкового литерала, жестко привязывает алгоритм получения данных к названию поля. Если название поля изменится на "fio", то придётся исправлять исходный код проекта и заново собирать apk. Устранить этот недостаток и сделать алгоритм более универсальным можно, если названия полей задавать не ввиде константных строк, а загружать из внешнего файла. То есть, в формате xml можно хранить не только данные из базы, но также настройки для приложения и ресурсы. Остановимся на этом подробнее.

Как правило, настройка внешнего вида и работы приложения осуществляется в самом приложении с использованием виджетов. Но существуют и другие способы, например, загрузка в приложение файла с настройками. Внешний файл настройки удобен тем, что данные в нём можно бысто редактировать, тогда как при использовании диалога настройки в приложении придётся последовательно взаимодействовать с каждой опцией - выбрать размер шрифта в одном поле, задать цвет шрифта в другом, цвет фона в третьем и т.д. Использование тем упрощает этот процесс, но файл настроек позволяет сделать больше - изменить интерфейс или функциональность приложения. То есть, файл настройки можно превратить в сценарий, который будет изменять функциональность приложения без необходимости правки его исходного кода. Для этого приложение должно позволять создавать объекты во время выполнения. В App inventor невозможно создавать объекты динамически, но можно интерфейс приложения AI построить на html, а системную логику - на блоках. Если вас интересует возможность динамического создания объектов, присмотритесь к App Inventor Java Bridge.

Ресурсы приложения - данные, которые необходимы для его работы. Они могут быть внешними и внутренними. Например, пиктограмма приложения - это внешний ресурс, а данные, используемые в коде приложения, - внутренние. К ним относятся надписи на виджетах, строки с сообщениями и текстом в диалогах, числовые параметры для настройки свойств объектов и др. Для чего всё усложнять и выносить эти данные во внешний файл, если можно легко и просто изменять их в дизайнере или редакторе блоков?

Предположим, необходимо сделать англоязычную версию приложения. Если изначально текстовые строки в коде были заданы в виде констант, то придётся произвести большой объём работы для разработки алгоритма смены языка и надписей - создать список текстовых ресурсов, создать большое количество блоков, содержащих англоязычные эквиваленты кириллических строк, каким-то образом их подключить к виджетам и др. А если позже потребуется сделать локализацию ещё для 10 языков, то получится просто неподъёмный объём ручной работы. Но всё можно сделать проще и быстрее, если изначально в проекте вместо текстовых блоков с надписями использовать строковый ресурс, доступный по его тегу из xml файла. Тогда для выполнения локализации нужно будет сделать несколько копий исходного файла, перевести текст в них и создать алгоритм подключения нужного файла при выборе пользователем языка в приложении.

Использование внешних ресурсов и сценариев позволяет сделать приложение более гибким и конфигурируемым, благодаря чего его можно уже рассматривать как платформу, а не как приложение для работы с определённой структурой данных. Предположим, нам нужно сделать записную книжку с полями Имя, Телефон, Адрес. Эти поля можно задать на этапе разработки приложения, что сделает невозможным работу с другой структурой данных, например, Имя, Возраст, Телефон, Адрес. А можно представление данных создавать динамически на этапе работы приложения, что позволит программе работать с любым количество полей, заданных в файле конфигурации. В этом случае у нас будет два файла - файл данных и файл конфигурации, в котором указывается то, какие данные и как нужно обработать и отобразить приложению на экране.

Для более наглядного вывода информации требуется форматирование, что реализуется при помощи компонента WebView, в котором можно использовать HTML-теги и CSS-стили. Преимущество использования данного виджета состоит ещё и в том, что он позволяет выводить информацию динамически в текстовом виде. Если бы AI позволял создавать виджеты динамически, то можно было бы вместо WebView создать пару десятков надписей Label и настроить их внешний вид для отображения данных. Но создание объектов происходит медленнее вывода текста. С другой стороны, гораздо проще программно создать в WebView десяток полей ввода, чем вручную возиться с ними в редакторе блоков AI.

При работе с большим объёмом информации можно использовать один или несколько экранов. В первом случае вся информация размещается на одном экране, а её вывод осуществляется путём управления видимостью виджетов, а во втором случае осуществляется управление экранами (переход между ними). Переключение экранов выполняется медленнее управления видимостью и нужно понять, действительно ли необходимо несколько экранов или можно обойтись одним.

Работа с данными - это обширная тема и здесь мы рассмотрели лишь отдельные моменты. Насколько она актуальна для пользователей App Inventor? Это каждый решает сам. AI - это среда разработки, которая требует от её пользователей большого объёма ручной работы. Но нам не обязательно её делать. Что-то можно и автоматизировать.