DroidScript

Thunkable X: работа с данными

© 2016-2018 Автор материалов - Александр Страшко admin@starport.ru
DroidScript
инструменты для мобильной разработки

Thunkable X: работа с данными

© 2016-2018 Автор материалов - Александр Страшко admin@starport.ru
Thunkable X  
Дата изменения 02.05.2018

Для работы с данными в Thunkable X существует несколько компонентов и блоков, но какие из них лучше использовать в том или другом случае? А разве это так важно? Создаём блок переменной и присоединяем к нему блок со значением, создаём второй.... Да, а если данных очень много?

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

Рассмотрим пример приложения, переводящего текст на разные языки

Переводчик

Рис. 1. Исходный алгоритм.

В глаза сразу бросается большое количество текстовых блоков. Возможно, пару десятков блоков несложно набить, но компонент переводчика Translator поддерживает более 90 языков. Это тоже можно сделать за вечер, но что делать, если где-нибудь ещё потребуются какие-то из этих данных? Вручную копировать их из этих блоков или снова набивать только нужные? Не проще ли один раз набить (или скопировать) данные в Exсel, а затем при помощи нескольких блоков загрузить их в список? Конечно, проще. Для решения этой задачи требуется минут 5-7:

  1. Найти список поддерживаемых языков Yandex Translator на английском языке.
  2. Скопировать его в Excel и организовать в один столбец по алфавиту.
  3. Составить несколько блоков для получения списка.

Получение списка из строки

Рис. 2. Упрощённый алгоритм.

После копирования столбца данных из Excel в текстовой блок примера слова разделены каким-то пробельным символом. Символа перевода строк? Нет, пробелом! Поэтому показанный алгоритм будет верно работать в том случае, если значения полей не содержат пробелов. Если значения полей содержат пробельные символы, то разбивка произойдёт некорректно:

  Переменная 1	Значение 1
  
превратится в список

  Переменная
  1	Значение
  1

Почему "Значение" не было перенесено? Потому что соседние по горизонтали ячейки в Excel разделены символом табуляции. Символ перевода строки преобразуется в пробел по причине того, что поля ввода блоков являются однострочными. Для разделения данных на строки необходимо к данным добавить справа столбец с каким-нибудь уникальным символом и копировать данные в текстовой блок вместе с этим столбцом.

При копировании строк из Excel данные будут разделены символом табуляции. Если в качестве разделителя указать управляющий символ \t, то список получить не удастся, потому что разделителя \t в исходной строке нет. Необходимо скопировать промежуток между словами и вставить его в поле разделителя.

В качестве разделителя можно использовать несколько символов, а не только один.

Рассмотренный пример помогает увидеть, найти и сделать ряд важных выводов.

Одни и те же данные имеют разное визуальное представление

Рассмотрим наш пример. На html-странице они выглядят в виде многоколоночного списка, на листе Excel - в виде столбца таблицы, в текстовом блоке - в виде строки с разделителями, на экране мобильного устройства - в виде списка.

На удобство работы с данными влияет множество факторов, включая их тип, визуальное представление, функциональность редактора, субъективность пользователя и др.

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

Можно в блокноте писать рассказ? Можно, но удобнее и нагляднее это делать в приложении Word, при помощи которого и конечный результат будет заметно лучше. А вот работать с графикой в блокноте невозможно, а в Word - можно, но практичность этого и конечный результат будут заметно уступать работе в графическом редакторе.

Из всего многообразия особым образом выделяется исходный вид данных и обработанный

Под исходным видом данных можно понимать такой их вид, который удобен для дальнейшей работы с ними. В нашем примере список языков изначально находится на html-страницe. Удобно ли это для работы с данными? Нет. Поэтому он был скопирован на лист Excel для более удобной работы (редактирование, сортировка, фильтрация, сохранение и др.).

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

Получается так, что редактор блоков в Thunkable X (и аналогичных IDE) не приспособлен для создания данных в исходном виде и его редактирования? Именно.Упрощённый алгоритм на рис. 2 потребовал для решения задачи заполнения списка на порядок меньше блоков по той причине, что в текстовом блоке используются не исходные данные, предварительно подготовленные. Из этого следует простой вывод о том, что формат данных непосредственно и ощутимо влияет на количество блоков для работы с ним и сложность алгоритмов. В чём же тогда преимущество блоков? В том, например, что их имена синхронизируются автоматически при переименовании. Предположим, блок переменной используется в 10 местах. Если его переименовать в одном из этих мест, то все остальные 9 блоков переименуются автоматически. Если же вместо блока переменной используется её текстовая альтернатива, то при переименовании её придётся вручную переименовать оставшиеся 9. Другое преимущество - наглядность. В сцепке блоков мы видим и имя переменной, и её значение. Если же переменные организовать в виде списка, то короткий однострочный блок не позволит увидеть все значения. Для их просмотра и редактирования придётся использовать внешний редактор.

Визуальное программирование при помощи блоков с одной стороны упрощает работу, а с другой стороны усложняет её и перед пользователями стоит выбор, либо выбрать наглядность за счёт практичности, либо практичность за счёт наглядности.

Рассмотрим пример использования текстовых переменных вместо блоков. Предположим, нужно работать с 10 переменными. Здесь кажется вполне логичным использовать список пар имя переменной=значение:

переменная1=значение1,переменная2=значение2, ... ,переменная10=значение10

Оценим сложность алгоритма для работы с данным форматом. Для поиска переменной придётся использовать цикл и пару временных переменных, в одну из которых будет копироваться строка до символа =, а во вторую - строка после этого символа. Для выборки десятой переменной цикл сделает 10 итераций. А можно ли сделать проще? Можно, если использовать поиск по индексу. Для этого создаём два списка, в одном из которых будут находиться имена переменных, а в другом - их значения. Для работы со значением переменной сначала находим по названию индекс переменной в первом списке, а затем используем этот индекс для получения значения во втором списке. Нужно вести два списка? Нет. В качестве исходных данных используется один список, из которого программным образом получаются два.

На листе Excel в две колонки создаём список переменных и их значение:

Переменная1 Значение1
Переменная2 Значение2
         ...
Переменная10 Значение10

Перед копированием их в текстовой блок выполняем транспонирование таблицы, чтобы имена переменных и их значения шли по строкам:

Переменная1 Переменная2 ... Переменная10
Значение1   Значение2   ... Значение10

Список переменных

Рис. 3. Список переменных.

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

Список переменных

Рис. 4. Список переменных.

Для получения или записи значения переменной сначала производится поиск индекса переменной в списке по её имени, а затем обращение к её значению после увеличения индекса на единицу. Для устранения неоднозначности при совпадении имени переменной и значения можно в качестве имени использовать объектную запись через точку, например, main.maxValue. Это позволит динамически добавлять в список свойства объектов.

Данный способ можно использовать и для хранения структуры объектов: за опцией с именем объекта хранить его данные в формате JSON.

Хранить данные в исходном формате можно и в облаке, но лучше локально. Особенно весело выглядит ситуация, когда компания старается быть "в тренде всех новых писков" и хранит прайс-лист только в облаке, а доступа к сети нет.

Формат JSON выглядит интереснее CSV, а при работе в Thunkable X в ряде случаев без него просто не обойтись, но выбор того или иного формата необходимо производить совместно с данными. В нашем примере использования JSON потребует сначала использовать конвертер данных в него из Excel, а затем создания алгоритма для его парсинга в Thunkable X, так как поддержка объектной структуры данных пока реализована не в полном объёме. Табличный формат Excel тем и интересен, что позволяет сразу копировать данные в текстовые блоки.

Со списком работать несложно, а что насчёт таблицы? Здесь на ум сразу приходит структура списка из списков, но представьте себе объем работы для её создания при помощи блоков. Для представления таблицы не обязательно использовать двумерную структуру данных. Можно обойтись и одномерным списком, в котором хранить строки с разделителями или уже готовые значения. В первом случае для доступа к опции списка сначала по индексу строки выбирается строка с разделителями, которая при помощи блока получения списка из текста с разделителями преобразуется во временный список, из которого по заданному индексу столбца возвращается значение. Во втором случае для выборки данных используется формула, возвращающая индекс опции по заданному номеру строки и столбца:

индекс = номер строки * количество опций в строке + номер столбца

0 1 2 3
4 5 6 7
8 9 10 11

индекс = 2 * 4 + 1 = 9

Какой способ хранения данных выбрать: элемент списка содержит строку с разделителями (все поля записи) или каждый элемент списка является отдельным значением? При поиске данных по одному полю второй вариант будет быстрее - для получения индекса достаточно будет использовать блока "in list find". Но первый вариант имеет преимущество в том, что при помощи него можно осуществлять поиск по нескольким полям записи, а также поиск по вхождению заданной подстроки, тогда как второй вариант работает только по точному совпадению строки запроса с данными элементов списка. Поиск по подстроке актуален, например, при использовании голосового ввода и для длинных строк списка, а поиск по точному совпадению - при коротких строках списка. Проще говоря, поиск по подстроке является мощным, а по целой строке - быстрым.

Вместо блоков переменных можно использовать объект, свойства которого трактуются как имена переменных.

Объект

Рис. 5. Объект.

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

Создание объекта из текста в формате JSON показан ниже.

Объект из строки JSON

Рис. 6. Объект из строки JSON.

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

Что использовать для хранения данных? Здесь нужно руководствоваться структурой данных и функциональностью компонентов для работы с ними.

При желании можно создать свой формат данных или конвертер. Например, формат JSON часто используется в Web API, но не позволяет напрямую использовать его в списке. Рассмотрим преобразование в список следующего примера:

[
{"Название":"Прибор 1","Цена":"100","Остаток":"10"},
{"Название":"Прибор 2","Цена":"200","Остаток":"20"},
{"Название":"Прибор 3","Цена":"300","Остаток":"30"}
]

Это массив объектов в формате JSON. Для преобразования его к списку нужно удалить все лишние символы и разбить на элементы списка. Должно получиться следующее:

"Название":"Прибор 1","Цена":"100","Остаток":"10"
"Название":"Прибор 2","Цена":"200","Остаток":"20"
"Название":"Прибор 3","Цена":"300","Остаток":"30"

Для этого можно либо скопировать JSON-данные в текстовой редактор и привести его к нужному виду, либо в Thunkable X составить алгоритм для автоматизированного преобразования. Первое легче, но при изменении JSON-данных придётся каждый раз копировать их в редактор и преобразовывать к нужному виду вручную. Второе даёт возможность автоматизировать процесс, но при изменении структуры данных придётся править и алгоритм его обработки. Пример преобразования JSON к строке показан ниже.

Пример преобразования JSON-данных

Рис. 7. Пример преобразования JSON-данных.

Thunkable X