Структуры данных

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

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

Обычно рассмотрение темы начинается со структур данных, но в концептуальном плане важнее для начала разобраться с видами структур данных:

• линейная
• табличная
• иерархическая
• сетевая

Линейная структура - это cтруктура, в которой каждый её элемент однозначно определяется одним параметром. Примером такой структуры является список.

В табличной структуре адрес каждого элемента определяется двумя параметрами - строкой и столбцом, как в Excel.

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

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

Для хранения линейных и табличных структур данных принято использовать формат строки с разделителями CSV и JSON, для иерархической - JSON.

На практике пользователи чаще всего имеют дело с табличными данными, но это не повод всегда и везде использовать только её.

Достаточно часто можно видеть ошибку, касающуюся выбора структуры данных исходя из своего понимания и умения работать с той или иной базой данных или форматом данных. Например, для начала выбирается Firebasе, потому что хочется запаролить доступ к данным. Через нескольких безуспешных попыток получить данных из Firebase, пользователь решает, что это слишком сложно и лучше использовать Air Table. Скопировать данные из Excel в Air Table несложно, но и здесь могут возникнуть сложности, если данные не являются регулярной структурой. И некоторые пользователи не находят ничего лучшего, как написать на форуме о том, что база не работает. Всё это похоже на то, как дворник вначале выбирает инструмент, которым он будет сегодня работать, а после идёт получать задание. Конечно, ломом тоже можно собирать листву или расчищать снег, но практичнее сначала получить задачу и только после её анализа выбрать наиболее подходящий из имеющегося инструмент для её решения, а не наоборот. Если навыка работы с тем или иным инструментом не хватает, то вначале практичнее поработать над его улучшением, а не бросаться в разработку приложения века.

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

После выбора вида структуры данных можно перейти к её локальному тестированию. На этом этапе совершается другая распространённая ошибка - попытка сразу работать с базой данных. В большой долей вероятности это приведёт к пробуксовке проекта из-за невозможности быстро определить её источник. Либо проблема в исходной структуре данных, либо что-то не так при работе с базой данных, канале передачи данных, web-сервером, багах системы или ошибки в своих блоках. К другой из распространённых ошибок относится попытка решить задачу путём поиска какого-то конкретного и частного решения, с применением того или иного инструмента. Решите её вначале на абстрактном уровне без привязки к конкретики. Данные не обязаны поступать из Firebase и храниться именно в Firebase.

Для локальной работы с данными их нужно где-то хранить. Здесь можно использовать табличный компонент Local DB, но более универсальным и простым вариантом является использование текстового блока.

Текстовые блоки в Thunkable X являются однострочными, по причине чего большинство управляющих символов преобразуются в пробел, что нужно учитывать при копировании данных из других источников. Если нужно скопировать данные из Excel, то в самый правый пустой столбец данных добавьте уникальный символ разделителя, например, "|". Тогда при вставке данных в текстовой блок появится возможность отделить поля символом табуляции, а строки при помощи строки " | " (табуляция, | и пробел).

Для сохранения иерархических данных также используется текстовой блок, данные из которого затем преобразуется в объекты при помощи бока get object from JSON.

Строка (в текстовом блоке) может использоваться в качестве хранилища данных, но для работы с ними она подходит далеко не во всех случаях и здесь на сцену выходят структуры данных.

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

В Thunkable X можно использовать следующие структуры данных:

• Массив
• Список
• Стек
• Очередь
• Map (список пар ключ - значение)

Для реализации данных структур можно использовать массив, строку с разделителями и объект. Обратите внимание на то, что под массивом в данном случае понимается динамический массив, являющийся подвидом объекта, а под списком понимается строка с разделителями. Ссылок и указателей в Thukable X нет.

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

• Множество
• Хеш-таблица
• Дерево

Массив позволяет хранить данные разных типов - значения простых типов и объекты - числа, символы, строки, логические значения и др. Блоки для работы с ними находятся в категории Lists и с ними всё более или менее понятно.

Списки реализуются на основе строки с разделителями, например:

"Вася,Петя,Женя,Саша,Вова,Лена,Игорь,Даша"

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

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

Структуру Map можно реализовать при помощи глобальных переменных и объектов. Из-за крайне низкой скорости работы первый вариант лучше не использовать.

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

Каждая структура данных имеет свои сильные и слабые стороны, с которыми детальнее можно познакомиться в рамках раздела "структуры данных и алгоритмы" после изучения базового курса.

При работе с объектами часто возникает вопрос, как сохранять выбранный объект для дальнейшей работы с ним? Самым безопасным способом является сохранение индекса выбранного объекта для получения по нему объекта из списка. Если выбранный объект сохраняется в глобальной переменной, то в этом случае сохраняется копия объекта, а если в переменной из параметра функции - ссылка на объект. В некоторых случаях передать объект блоку не получится. Его придётся преобразовать в строку JSON.

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