Поделиться через

Инфраструктура привязки данных и тем — MRTK3

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

Понятие привязки данных

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

Популярные инфраструктуры привязки данных:

  • Delphi
  • Windows Presentation Framework (WPF .NET)
  • Windows Forms
  • Angular
  • Backbond
  • Привязка JavaFX

Блок-схема привязки данных Windows Presentation Framework

Databinding Windows Presentation Framework (WPF) Подробнее см. в общих сведениях о привязке данных — WPF.NET

Эквивалентная блок-схема MRTK

Эквивалентная блок-схема MRTK

Цели проектирования

  • Кросс-платформенность — развертывание где угодно.
  • Поддержка любой организационной структуры и происхождения источников данных.
  • Простая интеграция с существующими и новыми базами кода.
  • Удобство как для дизайнеров, так и для разработчиков.
  • Возможность включить или отключить в любой момент жизненного цикла приложения.
  • Поддержка реальных корпоративных сценариев — внутренних баз данных, сложных шаблонов заготовок пользовательского интерфейса.
  • Совместимость с существующими компонентами пользовательского интерфейса, не относящимися к MRTK, и новыми визуальными элементами.
  • Привязка любого типа данных, включая спрайты, изображения, материалы, анимации и аудиоклипы.
  • Простота расширения возможностей без изменения существующей базы кода.
  • Эффективное использование ЦП, ОЗУ, сборка мусора и время кадра.
  • Простая интеграция с разнообразными локальными или внутренними источниками данных.
  • Любое одновременное сочетание источников данных: внедренных, времени выполнения и внутренних.
  • Эффективная обработка коллекций любого размера для представления списков.
  • Объединение тем и привязки данных для динамических элементов данных.
  • Открытая проверка и обработка переменных данных перед представлением.
  • Минимальная зависимость от других функций MRTK.
  • Совместимость с MRTK версии 2 и MRTK3.
  • Создание и (или) применение фирменной символики к стандартным активам с минимальными усилиями.

Основные возможности

  • Открытые источники данных поддерживают любую стратегию для сохраняемых, удаленных данных или ОЗУ.
  • Открытые потребители данных поддерживают любые требования пользовательского интерфейса к привязке и темам.
  • Автоматическое обнаружение источников и потребителей данных упрощает подключение.
  • Возможность автоматической настройки из профиля привязки.
  • Несвязанная модель и представление данных поддерживают шаблоны MVC и MVVM.
  • Виртуализированные коллекции с навигацией по страницам и прокруткой.
  • Предиктивная предварительная выборка элементов коллекции для плавной навигации по списку.
  • Объекты коллекции можно объединить в пул и повторно использовать для снижения нагрузки на сборку мусора.
  • Возможно сопоставлять различия между данными и просматривать пространства имен путей к ключам.

Текущие возможности

1. Визуализация переменных данных с помощью потребителей данных.

Поддерживается в текущей версии:

  • Текст TextMeshPro и TextMesh
  • Таблицы стилей текста (для тем и специальных возможностей)
  • Текстура спрайта
  • Логический триггер
  • Текстура объекта Quad
  • Значки шрифтов
  • Коллекции — списки произвольного размера, которые содержат заготовки, заполненные переменными данными.
  • Любой другой потребитель, поддерживающий интерфейс IDataConsumer (напрямую или через производные базовых классов)

2. Получение переменных данных из различных источников

  • Текст JSON (напрямую или через получение URL-адреса)
  • Словарь элементов переменных данных
  • Структурированные данные на основе объектов и узлов
  • Отражение любого объекта C#
  • Программно измененные данные
  • Любой другой метод, поддерживающий интерфейс IDataSource

3. Инструмент размещения элементов списка для управления визуальным отображением списка.

4. Разбиение списка на страницы, прокрутка и виртуализация.

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

5. Группировка заготовок списка в пул

  • Заготовки повторно используются и заново заполняются данными для сокращения времени сборки мусора и создания экземпляров.

6. Динамическое применение тем к элементам во время выполнения.

Запланированные возможности

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

1. Конвейеры манипулятора данных.

  • Преобразование между значениями на стороне данных и стороне представления
  • Локализация (простая интеграция с локализацией Unity)
  • Форматирование
  • Проверка

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

3. Больше потребителей данных.

  • Установка любого открытого свойства в компоненте
  • Установка/снятие флажка
  • Задание значения ползунка
  • Установка переключателя в группе
  • Свойства отдельных материалов, такие как установка цвета

4. Темы.

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

Терминология

  • Источник данных — любой поставщик данных, будь то созданный во время выполнения, локально сохраненный или полученный с сервера.
  • Поставщик источника данных — простой MonoBehaviour, обеспечивающий доступ к источнику данных, который не может быть предоставлен в графе сцены Unity.
  • Тип источника данных — уникальное имя, назначенное источнику данных, чтобы потребители данных могли указать нужные источники по имени.
  • Потребитель данных — любой потребитель данных, настроенный реагировать на изменения данных. Как правило (но не обязательно), это визуальный элемент. Например, его целью может быть активация действий на основе изменений значений данных.
  • Контроллер данных — механизм вызова действия с текущим связанным значением, предоставленным в качестве параметра.
  • Путь к ключу — селектор данных, ссылающийся на конкретный объект в источнике данных. В настоящее время формат пути к ключу построен по типу методов доступа к данным JSON для расшифровки любого вложенного сочетания карт, списков и атомарных элементов.
  • Локальный путь к ключу — путь к ключу потребителя данных, который можно окончательно внедрить в заготовку с возможностью повторного использования. С помощью разрешения сущностей коллекции и сопоставителей путей к ключу он автоматически преобразуется в полностью разрешенный путь к ключу для определенного элемента в коллекции. Если локальный путь не связан с коллекцией, он может быть сопоставлен напрямую с единицей данных в источнике данных или сначала пройти преобразование через сопоставитель путей к ключу.

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

  • Сопоставитель путей к ключу — необязательный сопоставитель пространства имен между локальными ключами и именами полей источника данных (например, link <—> URL).

  • Тема — источник данных, предоставляющий набор различных ресурсов и стилей, необходимых для достижения определенной визуальной эстетики.

  • Инструмент размещения элементов — компаньон DataConsumerCollection, отвечающий за размещение видимых элементов в сцене.

  • Пул объектов данных — группа экземпляров резервных заготовок, готовых к заполнению данными для навигации по списку с низким уровнем сборки мусора.

  • Виртуализация списков — возможность заполнять, представлять и перемещаться по спискам произвольного размера.

  • Прогнозная предварительная выборка — предварительная выборка данных и заполнение заготовок коллекции для элементов, которые вскоре могут быть отображены с помощью прокрутки или перемещения по страницам.

  • Предиктивная предварительная выборка — предварительная выборка данных и заполнение заготовок коллекции для элементов, которые вскоре могут быть отображены с помощью прокрутки или перемещения по страницам.

Основные понятия

Источник данных

Источник данных — это любой управляемый набор данных произвольного типа и сложности, которые можно использовать для заполнения представлений данных через потребителей данных. Данные, управляемые источником данных, могут быть статическими или динамическими. Любые изменения элементов данных будут сообщаться всем потребителям данных, зарегистрированным для получения уведомлений об изменениях.

Поставщик источника данных

Простой интерфейс с одним методом для получения источника данных. Он предназначен для автоматического обнаружения компонента сценария MonoBehavior в иерархии игровых объектов компонентами потребителя данных, но без необходимости реализовать источник данных непосредственно в самом игровом объекте. Это полезно, если существующий MonoBehaviour должен быть производным от другого класса и множественное наследование предотвращает наследование от DataSourceGOBase. Это также позволяет избавить больше кода от зависимостей Unity.

Отдельный поставщик источника данных

MonoBehaviour DataSourceProviderSingleton позволяет указать источник данных, который может быть автоматически обнаружен, даже если он не находится в той же иерархии GameObject, что и потребители данных (DataConsumers), которые хотят его прослушивать. Просто поместите DataSourceProviderSingletonв любое место сцены и заполните свойство Data Sources любыми источниками данных, которые должны быть обнаружены потребителями данных. Кроме того, потребители данных будут искать соответствующий источник данных и у родителей, что означает, что можно поместить источник данных, предоставляющий нужные данные, в любом месте родительской цепочки этих потребителей.

Путь к ключу (строка)

Путь к ключу — это механизм уникальной идентификации любого элемента информации в источнике данных.

Хотя путь к ключу может быть любым идентификатором, уникальным для каждого элемента данных, текущие реализации используют логическое удобочитаемое описание, указывающее навигационную позицию интересующих данных относительно всего структурированного набора данных. Он смоделирован на основе понятий списков, словарей и примитивов в Javascript. Пути к ключам — это синтаксически правильные инструкции Javascript для доступа к данным, которые могут быть представлены в JSON. Преимущество такого подхода заключается в том, что он хорошо подходит для JSON и XML. Это два самых распространенных способа передачи информации из серверных служб.

Примеры путей к ключам:

  • Температура
  • contacts[10].firstName
  • контакты
  • contacts[10].addresses[3].city
  • [10].title
  • kingdom.animal.mammal.aardvark.diet.foodtypes.termites

Учитывая, что путь к ключу является произвольной строкой без обязательной таксономии, фактические описания данных могут указывать данные для получения любым способом. XPath XML является примером возможной схемы путей к ключам, которая будет работать с источниками данных. Если пути к ключам, предоставленные потребителем данных, согласованы с путями, ожидаемыми источником данных, все будет работать. Кроме того, можно реализовать сопоставители путей к ключам для преобразования между различными схемами.

Разрешение пути к ключу

Разрешение пути к ключу означает объединение двух путей:

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

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

Так как "полностью разрешенный" путь к ключу всегда создается и используется источником данных (DataSource) и никогда (или практически никогда) не изменяется классом DataConsumer или другим внешним компонентом, он может иметь любую структуру, которая имеет смысл для DataSource. Например, если существует заготовка для отображения записи из списка фотографий с названием, датой съемки и другими атрибутами, локальный путь к ключу в заготовке может выглядеть следующим образом:

  • "photo_url"
  • "title"
  • "date_taken"
  • "description"

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

  • "f3cb1906-d8b3-489d-9f74-725e5542b55d/photo_url"
  • "f3cb1906-d8b3-489d-9f74-725e5542b55d/title"
  • "f3cb1906-d8b3-489d-9f74-725e5542b55d/date_taken"
  • "f3cb1906-d8b3-489d-9f74-725e5542b55d/description"

Сопоставитель путей к ключам (IDataKeyPathMapper)

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

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

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

Потребитель данных (IDataConsumer)

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

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

Потребители данных коллекции

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

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

Инструмент размещения элементов коллекции

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

Темы

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

Блок-схема и поток данных

Поток данных создания тем MRTK

Темы в МРТК

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

Создание тем MRTK3

Создание тем MRTK3 в сочетании с привязкой данных

Привязка данных и темы могут одновременно воздействовать на один элемент пользовательского интерфейса. Для любого отдельного элемента пользовательского интерфейса можно одновременно указать тему и привязать данные. Типичный сценарий в этой ситуации заключается в том, что единица данных, поступающая из источника данных, используется для получения правильного пути к ключу темы. Затем этот путь к ключу используется для извлечения объекта из источника данных темы, как правило, профиля ScriptableObject, но потенциально любого источника данных, который может разрешить путь к ключу.

Чтобы упростить настройку тем и привязки данных, можно создать профили привязки, обрабатываемые конфигуратором привязки BindingConfigurator во время создания экземпляра.

  • BindingConfigurator обрабатывает профиль привязки, чтобы определить ресурсы в заготовке, для которых должны быть определена тема, и связывает путями к ключам как элементы с привязкой данных, так и элементы с настроенной темой. Затем он добавляет соответствующие элементы DataConsumers для привязки этих визуальных элементов к правильным селекторам путей к ключам, которые будут использоваться для ссылки на определенные данные в одном или нескольких элементах DataSources, которые обычно не принадлежат к самой заготовке.
  • Данные темы предоставляются элементом DataSource, содержащим данные для каждого пути к ключу, определенного в профиле привязки.
  • Вспомогательный сценарий ThemeProviderупрощает использование объектов с поддержкой сценариев в качестве DataSource для тем.
  • Стандартная тема пользовательского интерфейса предоставляется MRTK_UX_ThemeProfile скриптом ScriptableObject , привязанным к объекту DataSourceReflection в объекте ThemeProvider.

Диаграмма потока DataSource профиля темы

Внедренный источник данных

Внедренный источник данных используется в двух ситуациях:

  1. Если каждый экземпляр заготовки может иметь разные параметры темы и требует собственный отдельный источник данных.
  2. Если все экземпляры этой заготовки управляются одним общим сохраненным профилем темы (например, объектом ScriptableObject) который можно предоставить через внедренный источник данных, чтобы внешние зависимости не устанавливались.

DataSourceReflection

DataSourceReflection может превратить любую структуру или класс C# в DataSource, используя отражение для сопоставления путей к ключам с полями и свойствами, вложенными классами, массивами, списками и словарями. Его можно связать с Unity ScriptableObject или любой другой структурой или классом C#, где существуют данные тем. Экземпляр объекта, содержащего данные, может быть внедрен и изменен во время выполнения.

  1. Scriptable Object (объект с поддержкой сценариев) — полезен для статических тем, совместно используемых во многих заготовках.
  2. Непостоянная структура или класс C# — полезны для динамических изменений во время выполнения темы.

DataSourceJson

Если данные существуют в виде текста json, DataSourceJson управляет сопоставлением путей к ключам с json DOM. Двоичные ресурсы можно получить из класса Unity Resources, StreamingAssets или даже из полученного URL-адреса.

DataSourceDictionary

Это простое решение для быстрого создания прототипов и для случаев, когда достаточно использовать плоский список. Поддерживаются все ресурсы тем, включая текст, ресурсы Unity (например, материалы, спрайты, изображения), класс Resources, StreamingAssets или даже внешние ресурсы, доступные по URL-адресу.

Другой

Любой пользовательский источник данных, реализующий простой интерфейс IDataSource или производный от DataSourceBase или DataSourceGOBase, может использоваться для удовлетворения нужд пользователя.

UXComponents для тем

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

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

Примечание к таблицам стилей (StyleSheets) для TextMeshPro. В настоящее время невозможно использовать StyleSheets для стилизации TextMeshPro Normal. Можно использовать любой другой стиль, включенный в Style Sheet (таблица стилей) TextMeshPro по умолчанию. В примерах для обхода этого ограничения используется стиль Body.

DataSourceThemeProvider

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

ThemeSelector

MonoBehaviour ThemeSelector позволяет указать и легко переключаться между несколькими профилями ScriptableObject. Примером этого может быть упрощенное переключение между темной и светлой темой. Добавьте объекты ScriptableObject в класс Theme Profiles, как правило, во время разработки. Затем во время выполнения измените свойство Current Theme, чтобы изменить тему.

Потребители данных для тем

Настройка тем осуществляется потребителями данных, особенно теми, которые наследуются от DataConsumerThemeBase<T>, DataConsumerTextStyle и пользовательских классов DataConsumer, которые любой разработчик может реализовать для улучшения поддержки тем.

Базовый класс DataConsumerThemeBase<T> предоставляет логику для использования целого числа или ключевой единицы данных из первичного источника данных, чтобы затем найти нужное конечное значение из базы данных-получателя темы. Это достигается путем сопоставления входных данных с путем к ключу темы, а затем с помощью этого пути к ключу темы получается окончательное значение. Это позволяет привязать любой элемент как к данным, так и к теме одновременно. Например, представьте, что поле состояния в базе данных с состояниями New, Started и Done представлено значениями 0, 1 и 2. Каждое из них может быть представлено значком спрайта. Для привязки данных для поиска нужного спрайта используется значение от 0 до 2. При использовании темы и привязки данных профиль темы указывает на правильный список из 3 спрайтов в профиле темы, а затем значение от 0 до 2 используется для выбора правильного спрайта из этого списка. Это позволяет использовать разные стили этих значков для каждой темы.

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

Переключение тем во время выполнения осуществляется путем замены данных в источнике данных темы новым набором, изложенным в той же топологии объектной модели данных. DataSourceReflection можно использовать с объектами ScriptableObject, где каждый профиль представляет тему. Для всех основных элементов управления пользовательским интерфейсом MRTK профиль темы — это ScriptableObject с именем MRTK_UXComponents_ThemeProfile. Вспомогательный сценарий ThemeProvider.cs упрощает использование этого или любого профиля ScriptableObject в качестве источника данных.

Способ применения темы к динамическим данным в большинстве случаев может быть автоматически обнаружен или явно указан.

Если единица данных используется для выбора правильного элемента из источника данных темы, процесс выполняется следующим образом:

  • Единица данных из первичного источника данных используется для выбора или создания правильного пути к ключу темы.
  • Путь к ключу темы используется для получения значения из источника данных темы, указанного в DataConsumerThemeHelper.
  • Полученное значение темы анализируется для автоматического обнаружения правильного метода извлечения.
  • Конечный элемент данных правильного типа (например, Material, Sprite, Image) извлекается с помощью автоматически обнаруженного метода.

Типы данных

Ожидаемый тип единицы данных, используемый для получения нужного объекта, может быть одним из следующих:

Тип данных Описание
AutoDetect Единица данных анализируется и правильная интерпретация обнаруживается автоматически. Дополнительные сведения см. в разделе "Автоматическое обнаружение типа данных" ниже.
DirectValue Ожидается, что единица данных будет иметь нужный тип T (например, Material, Sprite, Image) и использоваться напрямую.
DirectLookup Целочисленный индекс или строковый ключ, используемый для поиска нужного значения из локальной таблицы подстановки.
StaticThemedValue Статический тематический объект правильного типа извлекается из источника данных темы по указанному пути к ключу темы.
ThemeKeypathLookup Целочисленный индекс или строковый ключ, используемый для поиска требуемого пути к ключу темы.
ThemeKeypathProperty Строковое имя свойства, которое будет добавлено к базовому пути к ключу темы, предоставленному в Theme.
ResourcePath Путь к ресурсу для получения значения из ресурса Unity (может начинаться с "resource://").
FilePath Путь к файлу для получения ресурса потоковой передачи Unity (может начинаться с "file://").

Автоматическое обнаружение типа данных

Автоматическое обнаружение анализирует полученные данные и определяет метод извлечения автоматически. В таблице ниже T представляет нужный тип, например Material, Sprite, Image. Автоматическое определение может происходить в двух точках процесса:

  • В значении основной единицы данных.
  • В тематических значениях, полученных через основную единицу данных.
Тип единицы данных Рекомендации Имеет вспомогательное средство темы Поведение
T Недоступно Да/нет Используется напрямую без тем
INT любая целочисленная примитивная строка или строка с возможностью синтаксического анализа Int32 Нет Передается в качестве индекса производной функции GetObjectByIndex(n) для получения n-го объекта типа T.
INT любая целочисленная примитивная строка или строка с возможностью синтаксического анализа Int32 Да Индекс для получения пути к ключу N-й темы из локального поиска и последующего извлечения тематического объекта с помощью автоматического обнаружения.
строка Формат: "resource://{resourcePath}" Да/нет resourcePath используется для получения ресурса Unity
строка Формат: "file://{filePath}" Да/нет filePath используется для получения ресурса потоковой передачи
строка Другое Нет Передается в качестве ключа в производный метод GetObjectByKey() для получения соответствующего объекта типа T.
строка Другое Да Ключ для получения пути к соответствующему ключу темы из локального поиска и последующего извлечения тематического объекта с помощью автоматического обнаружения.

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

  1. Путь к ключу для значка состояния в базе данных — status.sprite_index.
  2. Полученное значение для status.sprite_index равно 2, что означает "отмененное" состояние.
  3. Запись N=2 (т. е. 3-я) в поиске DataConsumerSprite имеет значение Status.Icons.Cancelled.
  4. Это путь к ключу, используемый для получения значения из источника данных theme.
  5. Значение для пути к ключу Status.Icons.Cancelled — resource://Sprites/sprite_cancelled.
  6. Автоматическое обнаружение определяет, что нужно получить значок через ресурс, расположенный по адресу Resources/Sprites/sprite_cancelled

TextMeshPro StyleSheets

При применении тем можно активировать таблицы стилей TMPro. Объект ScriptableObject TMP Settings определяет, где таблицы стилей должны находиться в ресурсах. Это свойство Default Font Asset => Path.

Разместите все таблицы стилей приложения в одном подпути относительно ресурсов. Если вы хотите упорядочить их по-разному, обновите TMP Settings соответствующим образом.

Применение тем к новым элементам управления пользовательским интерфейсом

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

Можно реализовать наследование от MRTK_UXCore_ThemeProfile и добавить дополнительные тематические поля или указать элементам управления собственный объект ScriptableObject. Предоставленные объекты ничем не отличаются кроме того факта, что организация ScriptableObject определяет пути к ключам, необходимые для доступа к отдельным элементам данных с помощью отражения C#.

Добавив сценарий BindingConfigurator.cs на верхний уровень нового элемента управления, вы можете указать собственный сериализованный BindingProfile ScriptableObject, чтобы указать необходимое имя GameObject для сопоставлений путей к ключам, необходимых для связывания тематических элементов с данными в профиле темы. Этот сценарий автоматически добавит все необходимые компоненты DataConsumerXXXX во время выполнения для поддержки тем, которые вы хотите использовать.

Приступая к работе

Требования

  • Unity 2020.3 или более поздней версии;
  • TextMeshPro 2.1.4 или более поздней версии.

Примеры сцен

На первом шаге ознакомьтесь с различными примерами сцен с привязкой данных в пакете примеров MRTK и посмотрите, как настроены различные MonoBehaviour источников данных. Как правило, сценарии привязки данных необходимо размещать только в игровом объекте на самом высоком уровне в заготовке или в связанном наборе элементов пользовательского интерфейса.

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

Примечание

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

Assets/DataBinding Example/Scenes/DataBindingExamples.scene

Эта сцена демонстрирует различные сценарии переменных данных. Просто загрузите и воспроизведите сцену. Некоторые замечания.

  • Поле Text Input (Ввод текста) компонентов TextMeshPro содержит переменные, которые выглядят следующим образом: {{ firstName }}. Эти маркеры используются непосредственно в качестве локальных путей к ключам.

  • Игровые объекты для спрайтов и текста имеют определенный компонент потребителя данных, который управляет получением данных и обновлением представлений.

  • Один потребитель данных может совместно использоваться несколькими компонентами одного типа путем размещения выше в иерархии игровых объектов.

  • Потребитель данных (Data Consumer) может найти свой источник данных, если он находится на том же игровом объекте или выше в иерархии.

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

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

Assets/UX Theming Example/Scenes/AudioTheming

В этом примере темы используются для переключения аудиоклипов между фортепиано и ксилофоном.

Assets/UX Theming Example/Scenes/BatteryLevelExample

В этом примере выполняется объединение тем и привязки данных для отображения уровня заряда аккумулятора как в виде числового значения, так и в виде значка. Настройка тем используется для переключения между состояниями зарядки и ее отсутствия. Он предназначен для достижения следующих целей:

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

Примечание

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

Assets/UX Theming Example/Scenes/UXThemingExample

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

Первый проект привязки данных

Ниже приведен простой пример, который поможет вам быстро приступить к работе:

  1. Создайте новую сцену.
  2. В меню Mixed Reality Toolkit выберите Add to Scene and Configure (Добавить в сцену и настроить).
  3. Создайте пустой игровой объект и назовите его "Привязка данных". Добавьте компонент DataSourceJsonTest.
  4. В инспекторе измените URL-адрес на: https://www.boredapi.com/api/activity
  5. Добавьте в игровой объект привязки данных объект UI —> Text — TextMeshPro. Это добавит холст, а затем объект Text (TMP).
  6. Выделите объект Text (TMP) и в инспекторе измените значение Text Input на:

{{ activity }}. It's {{ type }}.

  1. Выберите объект Canvas и добавьте в него компонент Data Consumer Text.
  2. Запустите проект. Каждые 15 секунд будет отображаться другое действие.

Поздравляем. Вы создали свой первый проект привязки данных с помощью MRTK!

Создание нового источника данных

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

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

Чтобы можно было добавить источник данных в качестве компонента в игровой объект, существует другой базовый объект под названием DataSourceGOBase, где GO обозначает GameObject (игровой объект). Это MonoBehavior, которое можно добавить в игровой объект в качестве компонента. Это тонкий прокси, предназначенный для делегирования работы основному источнику данных, отличному от Unity.

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

Создание нового потребителя данных

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

Все потребители данных должны предоставлять интерфейс IDataConsumer. Некоторые основные возможности предлагаются в базовом классе с именем DataConsumerGOBase, где GO обозначает GameObject (игровой объект).

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

Создание инструмента размещения элементов коллекции

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

Все инструменты размещения элементов должны предоставлять интерфейс IDataCollectionItemPlacer. Некоторые основные возможности предлагаются в базовом классе с именем DataColletionItemPlacerGOBase. Все инструменты размещения элементов должны быть производными от этого класса.

Известные ограничения и отсутствующие функции

  • Интеграция с элементами управления на основе холста Unity и прокручиваемыми списками пока отсутствует.
  • Интеграция .NET INotifyPropertyChanged пока не реализована.
  • Пример сцены, которая извлекает изображения из Flickr и trymrtk.com не работает в HoloLens из-за ошибки HTTPS SSL в более поздних версиях Unity.
  • Дополнительная настройка производительности.
  • В этом выпуске основное внимание уделяется представлению данных, а не их сбору. Элементы управления пользовательским интерфейсом MRTK еще не подключены к настройке состояния в DataSource.
  • Динамические изменения данных списка полностью обновляют весь список вместо добавочного обновления.
  • Конвейер обработки данных еще не реализован.
  • Заполнение всех компонентов пользовательского интерфейса на двумерном экране еще не полностью поддерживается.
  • Узлы DataSourceJson должны реализовывать интерфейс IDataNode для взаимодействия с объектами DataSourceObject.