Marco de enlace de datos y creación de temas: MRTK3

Le damos la bienvenida al marco de enlace de datos y creación de temas de MRTK3. Este marco está diseñado para facilitar la creación de elementos visuales que se pueden rellenar y actualizar de forma dinámica en tiempo de ejecución mediante los datos proporcionados desde uno o varios orígenes de datos.

Descripción del enlace de datos

El enlace de datos es el proceso que establece una conexión entre la experiencia de usuario (vista) de una aplicación y los datos que se presentan (modelo). Imagine que el enlace está configurado correctamente y los datos proporcionan las notificaciones adecuadas; al cambiar los valores de los datos, los elementos enlazados a ellos reflejan los cambios de manera automática.

Marcos de enlace de datos populares:

  • Delphi
  • Windows Presentation Framework (WPF .NET)
  • Windows Forms
  • Angular
  • Backbond
  • JavaFX Bindings

Diagrama de bloques de enlace de datos de Windows Presentation Framework

Databinding Windows Presentation Framework (WPF) Para más información, vea Introducción al enlace de datos (WPF en .NET)


Diagrama de bloques equivalente de MRTK

MRTK equivalent block diagram


Objetivos de diseño

  • Multiplataforma: implementación en cualquier lugar
  • Compatibilidad con cualquier estructura y origen organizativos de orígenes de datos
  • Facilidad de integración en bases de código existentes o recién creadas
  • Facilidad de uso para diseñadores y desarrolladores
  • Posibilidad de habilitación o deshabilitación en cualquier momento durante el ciclo de vida de la aplicación
  • Compatibilidad con escenarios empresariales reales: bases de datos de back-end, plantillas prefabricadas complejas de experiencia de usuario
  • Facilidad de aplicación a componentes de la experiencia de usuario existentes que no son de MRTK y a elementos visuales nuevos
  • Enlace de cualquier tipo de datos, incluidos sprites, imágenes, materiales, animaciones y clips de audio
  • Facilidad de mejora de las capacidades sin tocar la base de código existente
  • Uso eficaz de CPU, RAM, GC y tiempo entre fotogramas
  • Integración sencilla con una amplia gama de orígenes de datos locales o de back-end
  • Cualquier combinación simultánea de orígenes de datos insertados, en tiempo de ejecución y de back-end
  • Control eficaz de colecciones de cualquier tamaño para su presentación en listas
  • Creación de temas y enlace de datos combinados para elementos de datos dinámicos con temas
  • Validación y manipulación de datos variables de forma abierta antes de presentarlos
  • Dependencias mínimas en otra funcionalidad de MRTK
  • Compatible con MRTK v2 y MRTK3
  • Facilidad de creación de marca propia o de aplicación de personalización de marca a los activos con un esfuerzo mínimo

Principales características

  • Los orígenes de datos abiertos admiten cualquier estrategia de datos persistente, remota o de RAM.
  • Los consumidores de datos abiertos admiten cualquier necesidad de enlace de datos y de creación de temas de experiencia de usuario.
  • La detección automática entre orígenes de datos y consumidores simplifica el enlace.
  • Configuración automática opcional desde un perfil de enlace.
  • El modelo de datos desacoplado y la vista admiten patrones MVC y MVVM.
  • Colecciones virtualizadas con navegación mediante paginación y desplazamiento.
  • Captura previa predictiva de elementos de colecciones para una navegación fluida por las listas.
  • Los objetos de las colecciones se pueden agrupar y reutilizar para reducir la recolección de elementos no utilizados.
  • Se puede asignar entre diferencias en los datos y ver los espacios de nombres de la ruta de acceso de clave.

Funcionalidad actual

1. Visualización de datos variables por medio de consumidores de datos

Actualmente admite:

  • Texto TextMeshPro y TextMesh
  • Hojas de estilos de texto (para creación de temas y accesibilidad)
  • Textura de sprite
  • Desencadenador booleano
  • Textura de cuadrícula
  • Iconos de fuente
  • Colecciones: listas de tamaño arbitrario que contienen elementos prefabricados rellenados con datos variables
  • Cualquier otro consumidor que admita la interfaz IDataConsumer (directamente o a través de derivaciones de clases base)

2. Entrega de datos variables por medio de una serie de orígenes de datos:

  • Texto JSON (directamente o mediante la captura de dirección URL)
  • Diccionario de elementos de datos variables
  • Objeto: datos estructurados basados en nodos
  • Reflejo de cualquier objeto de C#
  • Datos modificados mediante programación
  • Cualquier otro método que admita la interfaz IDataSource

3. Colocador de elementos de lista para administrar la manifestación visual de una lista

4. Paginación, desplazamiento y virtualización de listas

  • Los datos solo se capturan cuando están visibles o en proceso
  • Admite conjuntos de datos de back-end arbitrariamente grandes
  • La carga de la captura se equilibra entre varios marcos

5. Agrupación prefabricada de listas

  • Los elementos prefabricados se reutilizan y se vuelven a rellenar para reducir la recolección de elementos no utilizados y el tiempo de creación de instancias.

6. Aplicación dinámica de temas a elementos en tiempo de ejecución


Funcionalidad en la hoja de ruta

Además de lo que ya está disponible, las principales prioridades en cuanto a funcionalidades adicionales incluyen:

1. Canalizaciones de manipulador de datos

  • Conversión entre los valores del lado de datos y de vista
  • Localización (integración perfecta con la localización de Unity)
  • Formato
  • Validación

2. Captura previa predictiva de elementos de lista para un desplazamiento o una paginación más rápidos o fluidos

3. Más consumidores de datos

  • Establecimiento de cualquier propiedad pública en un componente
  • Establecimiento del estado activado o desactivado de una casilla
  • Establecer valor del control deslizante
  • Establecimiento de un botón de radio en un grupo
  • Propiedades materiales individuales, como el establecimiento de un color

4. Creación de temas

  • Visualización de los temas aplicados en el editor aunque no se esté ejecutando la aplicación
  • Actualización de los elementos prefabricados para reflejar un tema aplicado, de modo que se convierta en el tema predeterminado
  • Herencia de tema o estilo

Terminología

  • Origen de datos: cualquier proveedor de datos, ya sea en tiempo de ejecución, conservado en local o capturado desde un servidor.
  • Proveedor de orígenes de datos: una clase MonoBehaviour sencilla que proporciona acceso a un origen de datos que puede no estar expuesto en el gráfico de escenas de Unity.
  • Tipo de origen de datos: nombre único asignado al origen de datos para que los consumidores de datos puedan especificar sus orígenes de datos deseados por nombre.
  • Consumidor de datos: cualquier consumidor de datos que quiera actuar tras los cambios de datos, normalmente un elemento visual, aunque no es necesario. Como ejemplo, su propósito puede ser desencadenar acciones en función de cambios en los valores de los datos.
  • Controlador de datos: mecanismo para invocar una acción con el valor enlazado a datos asociado actualmente proporcionado como un parámetro.
  • Ruta de acceso de clave: selector de datos que hace referencia a un objeto específico de un origen de datos. Según la implementación actual, el formato de la ruta de acceso de clave se modela conforme a los descriptores de acceso de datos JSON para descifrar cualquier combinación anidada de asignaciones, listas y elementos atómicos.
  • Ruta de acceso de clave local: ruta de acceso de clave del lado del consumidor de datos que se puede insertar permanentemente en un elemento prefabricado reutilizable. Mediante la resolución de entidades de colección y asignadores de rutas de acceso de clave, se convierte automáticamente en una ruta de acceso de clave totalmente resuelta de un elemento específico de una colección. Si no está asociada a una colección, se puede asignar directamente a un dato del origen de datos, o bien primero se puede modificar mediante un asignador de ruta de acceso de clave.
  • Ruta de acceso de clave totalmente resuelta: ruta de acceso de clave completa y absoluta que se asigna a un objeto específico de un origen de datos. En el caso de los elementos de una colección, se trata de una combinación de la ruta de acceso de clave totalmente resuelta de una entidad de colección y una ruta de acceso de clave relativa (local) de un elemento de datos de esa entidad de colección.

  • Asignador de rutas de acceso de clave: asignador de espacios de nombres opcional entre rutas de acceso de clave locales y nombres de campos del origen de datos (por ejemplo, "vínculo" <-> "URL").

  • Tema: origen de datos que proporciona un conjunto de diversos recursos y estilos necesarios para lograr una estética visual concreta.

  • Colocador de elementos: complemento DataConsumerCollection responsable de colocar elementos visibles en una escena.

  • Grupo de objetos de datos: elementos prefabricados con instancias, en espera, listos para rellenarse con datos para la navegación por listas con una recolección de elementos no utilizados baja.

  • Virtualización de listas: capacidad de rellenar y presentar listas de tamaño arbitrariamente grande, así como de navegar por ellas.

  • Captura previa predictiva: captura previa de datos y relleno de elementos prefabricados de una colección en elementos que pronto se podrían ver por medio de desplazamiento o paginación.

  • Captura previa predictiva: captura previa de datos y relleno de elementos prefabricados de una colección en elementos que pronto se podrían ver por medio de desplazamiento o paginación.

Conceptos clave

Origen de datos

Un origen de datos es cualquier conjunto administrado de datos de tipo y complejidad arbitrarios que se puede usar para rellenar vistas de datos mediante consumidores de datos. Los datos administrados por un origen de datos pueden ser estáticos o dinámicos. Los cambios en los elementos de datos se notifican a los consumidores de datos que se han registrado para recibir notificaciones de cambios.

Proveedor de orígenes de datos

Interfaz sencilla que tiene un solo método para recuperar un origen de datos. Está diseñado para permitir que un componente de scripting de la clase MonoBehavior sea detectado automáticamente en la jerarquía de objetos de juego por componentes de consumidor de datos. No es necesario implementar un origen de datos directamente en el propio objeto del juego. Esto resulta útil cuando una clase MonoBehaviour existente debe derivar de otra clase y varias herencias evitan derivar de DataSourceGOBase. También permite que haya más código sin dependencias de Unity.

Singleton de proveedor de orígenes de datos

La clase MonoBehaviour de DataSourceProviderSingleton permite especificar un origen de datos que se puede detectar automáticamente aunque no esté en la misma jerarquía de GameObject que los consumidores de datos que quieren escucharlo. Simplemente coloque el DataSourceProviderSingleton en cualquier parte de la escena y rellene la propiedad Data Sources con los orígenes de datos que los consumidores de datos deban detectar. Los consumidores de datos también podrían recorrer los elementos principales para encontrar un origen de datos adecuado, lo que implica que puede colocar un origen de datos que proporcione los datos deseados en cualquier parte de la cadena principal de esos consumidores de datos.

Ruta de acceso de clave (cadena)

Una ruta de acceso de clave es el mecanismo para identificar de forma única cualquier fragmento de información de un origen de datos.

Aunque una ruta de acceso de clave puede ser cualquier identificador único por elemento de datos, las implementaciones actuales usan un especificador legible de usuario lógico que indica la posición de navegación de los datos de interés con respecto a todo el conjunto de datos estructurado. Se modela en el concepto de listas, diccionarios y primitivos de Javascript. Las rutas de acceso de clave son instrucciones Javascript sintácticamente correctas para acceder a los datos que se pueden representar en JSON. Una ventaja de este enfoque es que se correlaciona bien con JSON y XML. Estos son los dos medios más frecuentes para transferir información de los servicios back-end.

Rutas de acceso de clave de ejemplo:

  • temperatura
  • contacts[10].firstName
  • contactos
  • contacts[10].addresses[3].city
  • [10].title
  • kingdom.animal.mammal.aardvark.diet.foodtypes.termites

Dado que una ruta de acceso de clave es una cadena arbitraria sin taxonomía requerida, los especificadores de datos reales podrían ser cualquier método para describir qué datos se van a recuperar. XPath de XML es un ejemplo de un esquema de ruta de acceso de clave viable que funcionaría con orígenes de datos. Siempre que las rutas de acceso de clave proporcionadas por el consumidor de datos sean coherentes con las esperadas por el origen de datos, todo funcionará. Además, se pueden implementar asignadores de ruta de acceso de clave para traducir entre distintos esquemas.

Resolución de una ruta de acceso de clave

Resolver una ruta de acceso de clave significa combinar dos rutas de acceso de clave:

  1. Una ruta de acceso de clave absoluta que describe cómo acceder a un subconjunto específico de un conjunto de datos mayor, como una entrada de una lista de muchas entradas.
  2. Una ruta de acceso de clave parcial (relativa) que representa un dato específico dentro de esa entrada de lista o asignación.

Esto permite tratar un subconjunto de los datos de tal manera que no importe dónde existe realmente dentro de una jerarquía de conjuntos de datos más grande. El uso más crítico de esta capacidad es describir los datos de una sola entrada de una lista sin preocuparse de a qué entrada de esa lista hace referencia la instancia actual.

Dado que siempre se genera una ruta de acceso de clave "totalmente resuelta" que consume un origen de datos y que nunca (o, al menos, rara vez) debe ser modificada por un consumidor de datos u otro componente externo, puede tener cualquier estructura que tenga sentido para el origen de datos. Por ejemplo, en el caso de un elemento prefabricado para mostrar una entrada de lista de una foto y su título, la fecha en que fue tomada y otros atributos, la ruta de acceso de clave local del elemento prefabricado podría tener este aspecto:

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

Las rutas de acceso de clave totalmente resueltas de un elemento prefabricado de una lista podrían tener este aspecto:

  • "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"

Key Path Mapper (IDataKeyPathMapper)

Un asignador de rutas de acceso de clave permite a los orígenes de datos y a los consumidores de datos usar diferentes espacios de nombres y convenciones para rutas de acceso de clave y seguir trabajando juntos.

Un elemento prefabricado de un elemento usado habitualmente, como una pizarra para mostrar la información de contacto de personas, puede contener campos variables administrados por consumidores de datos. Para que esto sea posible, el identificador usado en cualquier aspecto variable del elemento prefabricado necesita una manera de asignarse al identificador del dato correcto del origen de datos que, en cada uso del elemento prefabricado, determina el contenido de ese elemento variable. El asignador de rutas de acceso de clave hace esto posible.

El elemento prefabricado se puede usar con orígenes de datos diferentes donde los datos se almacenen en otra estructura organizativa y usen nombres de campo. Para usar un elemento prefabricado de plantilla con cada origen de datos, un asignador de rutas de acceso de clave puede resolver las diferencias en cuanto a la organización de los datos.

Data Consumer (IDataConsumer)

Objeto que sabe cómo consumir información administrada por un origen de datos y usar esos datos para rellenar vistas de datos.

Los consumidores de datos pueden registrarse en un origen de datos para recibir notificaciones de cualquier cambio en un elemento de datos que exista en una ruta de acceso de clave especificada en un conjunto de datos. Cada vez que los datos especificados cambian (o se sospecha que han cambiado), se notifica a los consumidores de datos.

Colección de consumidores de datos

Una colección de consumidores de datos tiene la capacidad adicional de administrar una lista de elementos similares. Esta lista puede ser todo el conjunto de datos administrado por un origen de datos, o solo un subconjunto. Normalmente, los datos de cada elemento de la lista contienen tipos de información similares, aunque esto no es un requisito. Los orígenes de datos y los consumidores de datos pueden admitir listas anidadas, como una lista de palabras clave asociadas a cada foto de una lista de fotos asociadas a cada persona de una lista de contactos. La ruta de acceso de clave de las palabras clave sería relativa a la foto, la ruta de acceso de clave de las fotos sería relativa a la persona, y la ruta de acceso de clave de la persona sería relativa a la lista principal más cercana o a la raíz del conjunto de datos.

Al procesar colecciones, la ruta de acceso de clave resuelta correcta de la entrada específica de la colección se asigna a cada consumidor de datos que se encuentra en el elemento prefabricado con instancias de cada elemento de la colección. Esto luego se usa para resolver totalmente la ruta de acceso de clave de cualquier dato de vista relativo (local) dentro de ese elemento prefabricado.

Colocador de elementos de la colección de datos

Un consumidor de datos de la colección necesita un medio para rellenar experiencias de usuario con listas de elementos visuales repetidos, como una lista desplazable de productos, fotos o contactos. Esto se logra mediante la asignación de un colocador de elementos en el consumidor de datos de la colección. Este colocador de elementos es la lógica que sabe cómo solicitar elementos de lista, aceptar elementos prefabricados que se han rellenado con datos variables y, a continuación, presentarlos al usuario, normalmente insertándolos en una lista administrada por un componente de diseño de experiencia de usuario de listas.

Temas

La creación de temas usa toda la estructura de orígenes de datos y consumidores de datos. Es posible crear temas de cualquier jerarquía de GameObjects, tanto si son estáticos como si están enlazados dinámicamente a otros orígenes de datos. Esto permite aplicar el enlace de datos y la creación de temas en combinación. Incluso es posible crear temas de los datos procedentes de otro origen de datos.

Diagrama de bloques y flujo de datos

MRTK theming data flow

Creación de temas de MRTK

La creación de temas es la capacidad de cambiar la estética visual de muchos elementos de la experiencia de usuario a la vez. Normalmente, todos los datos necesarios para especificar un tema se proporcionan mediante un único origen de datos, como un objeto que admite scripts. También es posible proporcionar los datos de creación de temas según sea necesario, o dividirlos en grupos lógicos en función de su propósito.

MRTK3 Theming

Creación de temas de MRTK3 combinada con el enlace de datos

El enlace de datos y la creación de temas pueden coexistir en un único elemento de la experiencia de usuario. Cualquier elemento de experiencia de usuario puede tener aplicados simultáneamente el enlace de datos y la creación de temas. En este escenario, el flujo típico es que el dato procedente de un origen de datos se use para derivar la ruta de acceso de clave de tema correcta. Luego, esta ruta de acceso de clave se usa para recuperar un objeto del origen de datos del tema, normalmente un perfil de objeto que admite scripts, aunque, potencialmente, cualquier origen de datos que pueda resolver una ruta de acceso de clave.

Para simplificar la configuración de creación de temas y enlace de datos, es posible crear perfiles de enlace procesados mediante un elemento BindingConfigurator en el momento de la creación de instancias.

  • BindingConfigurator procesa un perfil de enlace para determinar los recursos de un elemento prefabricado a los que se va a aplicar creación de temas y asocia los elementos de datos enlazados y los elementos con temas con rutas de acceso de clave. Luego agrega el elemento DataConsumers adecuado para enlazar estos elementos visuales a los selectores de rutas de acceso de clave correctos que se van a usar para hacer referencia a datos específicos de uno o varios elementos DataSources, que normalmente son externos al propio elemento prefabricado.
  • Los datos del tema los proporciona un elemento DataSource que contiene datos de cada ruta de acceso de clave identificada en el perfil de enlace.
  • Un script auxiliar ThemeProvider facilita el uso de un elemento ScriptableObject como DataSource para la creación de temas.
  • El tema de la experiencia de usuario estándar lo proporciona MRTK_UX_ThemeProfileScriptableObject, que está enlazado a DataSourceReflection en ThemeProvider.

Theme Profile DataSource flow diagram

Origen de datos insertado

Un origen de datos insertado es adecuado en dos casos:

  1. Cuando cada instancia del elemento prefabricado puede tener una configuración de tema diferente y requiere su propio origen de datos independiente.
  2. Cuando todas las instancias de este elemento prefabricado se rigen por un perfil de tema persistente común (por ejemplo, ScriptableObject) que se puede proporcionar mediante el origen de datos insertado para que no haya que establecer dependencias externas.

DataSourceReflection

Esto puede convertir cualquier estructura o clase de C# en un elemento DataSource; para ello, se usa el reflejo para asignar rutas de acceso de clave a campos, propiedades, clases anidadas, matrices, listas y diccionarios. Se puede asociar a un elemento ScriptableObject de Unity o a cualquier otra estructura o clase de C# en la que existan datos de tema. El objeto con instancias que contiene los datos puede tener dependencias insertadas y se puede cambiar en tiempo de ejecución.

  1. Objeto que admite scripts: útil para temas estáticos compartidos entre muchos elementos prefabricados.
  2. Estructura o clase de C# no persistente: útil para modificaciones dinámicas en tiempo de ejecución del tema.

DataSourceJson

Si los datos existen como texto json, administra la asignación de rutas de acceso de clave al DOM json. Los recursos binarios se pueden recuperar de los recursos de Unity, StreamingAssets o incluso una dirección URL capturada.

DataSourceDictionary

Esta es una opción sencilla cuando basta con una lista puramente plana para satisfacer las necesidades, y para la creación de prototipos rápida. Se admiten todos los recursos de creación de temas, incluidos texto, recursos de Unity (por ejemplo, materiales, sprites e imágenes), recursos, streamingAssets o incluso elementos capturados externamente mediante una dirección URL.

Personalizado

Cualquier origen de datos personalizado que implemente la interfaz sencilla IDataSource o derive de DataSourceBase o DataSourceGOBase se puede usar para satisfacer las necesidades personalizadas.

Componentes de experiencia de usuario de creación de temas

Los controles de componentes de experiencia de usuario estándar proporcionados en el paquete UXComponents están configurados para admitir la creación de temas. Están desactivados de manera predeterminada, pero son fáciles de habilitar.

Cada control, normalmente en el GameObject superior del elemento prefabricado raíz, tiene un script con el nombre UXBindingConfigurator. Este script, si está habilitado, extrae los scripts de enlace de datos necesarios para activar la creación de temas. Asegúrese de importar también el paquete de enlace de datos y de creación de temas.

Nota sobre las hojas de estilos de TextMeshPro: actualmente no es posible usar hojas de estilos para aplicar estilo al estilo Normal de TextMeshPro. Se puede usar cualquier otro estilo incluido en la hoja de estilos predeterminada de TextMeshPro. En los ejemplos se usa Body para solucionar esta limitación.

DataSourceThemeProvider

La clase MonoBehaviour DataSourceThemeProvider se puede usar para hacer que un objeto que admite scripts y que contiene todas las referencias a todos los recursos de creación de temas actúe fácilmente como origen de datos. Esto se muestra en la escena UXThemingExample.

ThemeSelector

La clase MonoBehaviour ThemeSelector permite especificar e intercambiar fácilmente entre varios perfiles de objetos que admiten scripts. Un ejemplo de uso de esto sería facilitar el cambio entre un tema "Oscuro" y un tema "Claro". Agregue los objetos que admiten scripts a Theme Profiles, normalmente en tiempo de diseño. Luego, en tiempo de ejecución, cambie la propiedad Current Theme para cambiar el tema.

Creación de temas de consumidor de datos

Los consumidores de datos llevan a cabo la creación de temas, especialmente los que heredan de las clases DataConsumerThemeBase<T>, DataConsumerTextStyle y DataConsumer personalizada que cualquier desarrollador puede implementar para mejorar la compatibilidad con la creación de temas.

La clase base DataConsumerThemeBase<T> proporciona lógica para usar un valor entero o un dato de clave de un origen de datos principal a fin de buscar el valor final deseado desde una base de datos de temas secundaria. Esto se logra mediante la asignación de los datos de entrada a una ruta de acceso de clave de tema y luego el uso de esa ruta de acceso de tema para recuperar el valor final. De esta forma, es posible que cualquier elemento tenga aplicados el enlace de datos y la creación de temas al mismo tiempo. Por ejemplo, imagine un campo de estado de una base de datos con estados Nuevo, Iniciado y Listo representados por los valores 0, 1 y 2. Cada uno puede representarse mediante un icono de sprite. En el enlace de datos se usa un valor de 0 a 2 para buscar el sprite deseado. Con la creación de temas y el enlace de datos, el perfil de tema apunta a la lista correcta de tres sprites del perfil de tema y, luego, el valor de 0 a 2 se usa para seleccionar el sprite correcto de esa lista. Esto permite que el estilo de estos iconos sea diferente por tema.

Cuando se usan la creación de temas en tiempo de ejecución y el enlace de datos dinámico a la vez, se puede especificar una clase DataConsumerThemeHelper en cualquier clase derivada DataConsumerThemeBase para notificar cuándo ha cambiado un tema.

El intercambio de temas en tiempo de ejecución se logra mediante la sustitución de los datos en el origen de datos del tema por un nuevo conjunto de datos establecido en la misma topología del modelo de objetos de datos. DataSourceReflection se puede usar con objetos que admiten scripts donde cada perfil representa un tema. En todos los controles de experiencia de usuario de MRTK Core el perfil de tema es un objeto que admite scripts de nombre MRTK_UXComponents_ThemeProfile. El script auxiliar ThemeProvider.cs facilita el uso de este o cualquier perfil de objeto que admite scripts como origen de datos.

El método de aplicar un tema a datos dinámicos se puede detectar automáticamente en la mayoría de los casos o se puede especificar explícitamente.

Cuando se usa el dato para seleccionar el elemento correcto del origen de datos del tema, el proceso es:

  • se usa un dato del origen de datos principal para seleccionar o construir la ruta de acceso de clave de tema correcta
  • se usa la ruta de acceso de tema para recuperar un valor del origen de datos del tema especificado en DataConsumerThemeHelper
  • el valor del tema recuperado se analiza para detectar automáticamente el método de recuperación correcto
  • el elemento de datos final del tipo correcto (por ejemplo, Material, Sprite o Imagen) se recupera mediante el método detectado automáticamente.

Tipo de datos

El tipo de datos esperado del dato usado para recuperar el objeto deseado puede ser uno de los siguientes:

Tipo de datos Descripción
AutoDetect El dato se analiza y se detecta automáticamente la interpretación correcta. Vea "Tipo de datos Auto-detect" a continuación para obtener más información.
DirectValue Se espera que el dato sea del tipo T deseado (por ejemplo, Material, Sprite, Imagen) y se use directamente.
DirectLookup Índice entero o clave de cadena que se usa para buscar el valor deseado en una tabla de búsqueda local.
StaticThemedValue El objeto con temas estáticos del tipo correcto se recupera del origen de datos del tema en la ruta de acceso de tema especificada.
ThemeKeypathLookup Se usa un índice entero o una clave de cadena para buscar la ruta de acceso de clave del tema deseada.
ThemeKeypathProperty Nombre de propiedad de cadena que se va a anexar a la ruta de acceso de clave base del tema proporcionada en el tema.
ResourcePath Ruta de acceso de recurso para recuperar el valor de un recurso de Unity (puede comenzar por "resource://").
FilePath Ruta de acceso de archivo para recuperar un recurso de streaming de Unity (puede comenzar por "file://").

Tipo de datos Auto-detect

La detección automática analiza los datos recibidos y decide el método de recuperación automáticamente. En la tabla siguiente, T representa el tipo deseado, como Material, Sprite, Imagen. La detección automática puede producirse en dos lugares del proceso:

  • En el propio valor de dato principal.
  • En el valor con temas recuperado mediante el dato principal.
Tipo de dato Consideraciones Tiene auxiliar de tema Comportamiento
T N/D S/N Se usa directamente sin creación de temas
int cualquier cadena integral primitiva o int32 analizable No Se pasa como índice al elemento GetObjectByIndex(n) derivado para recuperar el objeto º de tipo T.
int cualquier cadena integral primitiva o int32 analizable Índice para capturar la ruta de acceso de clave del tema ª de la búsqueda local y luego recuperar el objeto con temas mediante la detección automática.
string Format: "resource://{resourcePath}" S/N resourcePath se usa para recuperar el recurso de Unity
string Format: "file://{filePath} S/N filePath se usa para recuperar un recurso de streaming
string Otros No Se pasa como clave al elemento GetObjectByKey() derivado para recuperar el objeto coincidente de tipo T.
string Otros Clave para capturar la ruta de acceso de clave del tema coincidente de la búsqueda local y luego recuperar el objeto con temas mediante la detección automática.

Un ejemplo para recuperar un icono de estado con temas de una base de datos que contiene un valor de estado numérico:

  1. La ruta de acceso de clave de un icono de estado de la base de datos es status.sprite_index.
  2. El valor recuperado de status.sprite_index es 2, lo que significa el estado "cancelado".
  3. La entrada N=2 (es decir, 3ª) de la búsqueda de DataConsumerSprite se establece en "Status.Icons.Cancelled".
  4. Esta es la ruta de acceso de clave que se usa para recuperar un valor del origen de datos "theme".
  5. El valor de la ruta de acceso de clave "Status.Icons.Cancelled" es "resource://Sprites/sprite_cancelled".
  6. La detección automática determina que debe recuperar el icono por medio de un recurso ubicado en "Resources/Sprites/sprite_cancelled"

TextMeshPro StyleSheets

La creación de temas es capaz de activar hojas de estilos de TMPro. El objeto que admite scripts "TMP Settings" determina en qué lugar de los recursos se espera que estén las hojas de estilos. Es la propiedad "Default Font Asset => Path".

Asegúrese de colocar las hojas de estilos específicas de una aplicación en la misma subruta de los recursos. Si quiere organizarlas de forma diferente, asegúrese de actualizar "TMP Settings" en consecuencia.

Aplicación de la creación de temas a los nuevos controles de experiencia de usuario

Si va a desarrollar nuevos controles de experiencia de usuario, es relativamente fácil aplicarles la creación de temas. En la medida en que el control use materiales, sprites y otros recursos ya en uso por otros controles de experiencia de usuario, generalmente es una cuestión de asignar nombres a los distintos objetos de juego de una manera reconocible.

Es posible heredar de MRTK_UXCore_ThemeProfile y agregar más campos con temas o apuntar los controles al objeto que admite scripts propio. No hay nada mágico en los proporcionados; la organización del objeto que admite scripts determinará las rutas de acceso de clave necesarias para acceder a elementos de datos individuales mediante el reflejo de C#.

Al agregar un script BindingConfigurator.cs al nivel superior del nuevo control, puede especificar su propio objeto que admite scripts BindingProfile serializado. De esta forma, se proporcionará el nombre del elemento GameObject necesario a las asignaciones de ruta de acceso de clave necesarias para asociar los elementos con temas a los datos proporcionados en el perfil de tema. Este script agrega automáticamente los componentes DataConsumerXXX necesarios en tiempo de ejecución para admitir la creación de temas que quiere usar.

Introducción

Requisitos

  • Unity 2020.3 LTS o posterior
  • TextMeshPro 2.1.4 o posterior

Escenas de ejemplo

Como primer paso, eche un vistazo a las distintas escenas de ejemplo de enlace de datos del paquete de ejemplos de MRTK y vea cómo se configuran las distintas clases MonoBehaviour del origen de datos. En general, los scripts de enlace de datos solo deben colocarse en el GameObject de nivel superior de un elemento prefabricado o un conjunto relacionado de elementos de la experiencia de usuario.

Además, en la mayoría de los casos de uso, los valores predeterminados funcionan de serie, pero las propiedades expuestas proporcionan mucha flexibilidad en los casos más avanzados.

Nota

Para habilitar la creación de temas en los componentes estándar de experiencia de usuario de MRTK, el símbolo MRTK_UX_DATABINDING_THEMING_ENABLED debe definirse en Configuración del reproductor. Este símbolo garantiza un impacto nulo en el rendimiento cuando no se necesita la creación de temas.

Assets/DataBinding Example/Scenes/DataBindingExamples.scene

Esta escena muestra una serie de escenarios de datos variables. Simplemente cargue la escena y reproduzca. Tenga en cuenta lo siguiente:

  • El campo Entrada de texto de los componentes de TextMeshPro contiene variables similares a esta: {{ firstName }}. Estos marcadores se usan directamente como rutas de acceso de clave locales.

  • Los GameObjects de sprites y texto tienen algún tipo de componente de consumidor de datos que administra la recepción de datos y la actualización de vistas.

  • Un único consumidor de datos puede compartirse con varios componentes del mismo tipo si se coloca más arriba en la jerarquía de GO.

  • Un consumidor de datos puede encontrar su propio origen de datos siempre y cuando esté en el mismo objeto de juego o más arriba en la jerarquía de GO.

  • Un Game Object principal tiene un componente de origen de datos que proporciona datos para todos los GameObjects secundarios que presentan un conjunto relacionado de información variable.

  • Un consumidor de datos de colección especifica un elemento prefabricado que contiene consumidores de datos que se van a usar para rellenar ese elemento prefabricado con datos variables.

Assets/UX Theming Example/Scenes/AudioTheming

En este ejemplo se usa la creación de temas para cambiar clips de audio entre un conjunto para piano y otro para xilófono.

Assets/UX Theming Example/Scenes/BatteryLevelExample

En este ejemplo se combinan la creación de temas y el enlace de datos para mostrar un nivel de batería tanto como valor numérico como icono. La creación de temas se usa para seleccionar entre un "tema de carga" y otro que no lo es. Está diseñada para satisfacer los objetivos siguientes:

  • Todos los recursos visuales pueden existir en un solo elemento ScriptableObject que actúa como perfil de tema.
  • El número de sprites de los estados de carga puede diferir del número del estado que no es de carga.
  • El algoritmo para asignar el nivel de batería notificado a un sprite en particular puede ser no lineal y diferir entre los estados de carga y no de carga.
  • Todos los recursos visuales pueden existir en un solo elemento ScriptableObject que actúa como perfil de tema.
  • El número de sprites de los estados de carga puede diferir del número del estado que no es de carga.
  • El algoritmo para asignar el nivel de batería notificado a cada sprite puede ser no lineal y diferir entre los estados de carga y no de carga.

Nota

La estructura de esta demostración no es un buen ejemplo de combinación de creación de temas y enlace de datos. En una aplicación de producción, para una separación adecuada del modelo y la vista, el estado real de la batería (nivel y carga) se proporcionaría en un origen de datos independiente al de los localizadores de recursos de los propios sprites.

Assets/UX Theming Example/Scenes/UXThemingExample

En este ejemplo se muestra cómo cambiar el tema de una aplicación completa y también se enseña el uso de DataSourceGODictionary como origen de datos para administrar una serie de contenido textual que se va a mostrar en la experiencia de usuario. En un escenario más general, es probable que los otros tipos de origen de datos más flexibles proporcionen la flexibilidad necesaria, como DataSourceReflection o DataSourceGOJson.

Primer proyecto de enlace de datos

Este es un ejemplo sencillo para ayudarle a empezar a trabajar rápidamente:

  1. Crea una escena nueva.
  2. En el menú de Mixed Reality Toolkit, seleccione la opción Add to Scene and Configure.
  3. Cree un objeto de juego vacío y llámelo "Enlace de datos". Agregue un componente DataSourceJsonTest.
  4. En el inspector, cambie la dirección URL a: https://www.boredapi.com/api/activity.
  5. Agregue un objeto UI -> Text - TextMeshPro al GameObject Enlace de datos. Se agrega un lienzo y luego un objeto "Text (TMP)".
  6. Seleccione el objeto Text (TMP) y, en el inspector, cambie la entrada de texto a:

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

  1. Seleccione el objeto Canvas y agréguele un componente Data Consumer Text.
  2. Ejecute el proyecto. Cada 15 segundos se muestra una actividad diferente.

Enhorabuena. Ha creado su primer proyecto de enlace de datos con MRTK.

Escritura de un nuevo origen de datos

Un origen de datos proporciona datos a uno o varios consumidores de datos. Sus datos pueden ser cualquier cosa: generados mediante algoritmos, en RAM, en disco o capturados desde una base de datos central.

Todos los orígenes de datos deben proporcionar la interfaz IDataSource. Parte de la funcionalidad básica se ofrece en una clase base llamada DataSourceBase. Lo más probable es que quiera derivar de esta clase para agregar la funcionalidad de administración de datos específica para sus necesidades.

Para que sea posible colocar un origen de datos como componente en un objeto de juego, existe otro objeto base llamado DataSourceGOBase, donde GO significa GameObject. Se trata de una clase MonoBehavior que se puede colocar en un GameObject como componente. Es un proxy fino diseñado para delegar el trabajo en un origen de datos principal específico que no es de Unity.

Un origen de datos puede exponer la capacidad de manipular datos en el editor de Unity. Si este es el caso, la clase derivada puede contener toda la lógica del origen de datos, o puede aprovechar un origen de datos "stock", pero también agregar campos de Inspector u otros medios para configurar los datos.

Escritura de un nuevo consumidor de datos

Un consumidor de datos recibe notificaciones cuando los datos han cambiado y luego actualiza algún aspecto de la experiencia de usuario, como el texto que se muestra en un componente de TextMeshPro.

Todos los consumidores de datos deben proporcionar la interfaz IDataConsumer. Parte de la funcionalidad básica se ofrece en una clase base llamada DataConsumerGOBase, donde GO significa GameObject.

La mayoría del trabajo de un consumidor de datos es aceptar nuevos datos y prepararlos para su presentación. Esto puede ser tan sencillo como seleccionar el elemento prefabricado correcto, o podría significar capturar más datos de un servicio en la nube, como un sistema de administración de contenido.

Escritura de un colocador de elementos de la colección de datos

Un colocador de elementos de la colección de datos es responsable de administrar qué partes de una colección son visibles actualmente y cómo presentar esa colección visible, si la colección es una lista estática pequeña o una base de datos gigante de millones de registros.

Todos los colocadores de elementos deben proporcionar la interfaz IDataCollectionItemPlacer. Parte de la funcionalidad básica se ofrece en una clase base llamada DataColletionItemPlacerGOBase. Todos los colocadores de elementos deben derivar de esta clase.

Limitaciones conocidas y características que faltan

  • Aún no se ha integrado con los controles basados en lienzos y las listas desplazables de Unity.
  • La integración de INotifyPropertyChanged de .NET aún no se ha implementado.
  • La escena de ejemplo que captura imágenes de Flickr y trymrtk.com no funciona en HoloLens debido a un error de HTTPS SSL en versiones posteriores de Unity.
  • Ajuste de rendimiento adicional.
  • Esta versión se centra en la presentación de datos, no en la captura de datos. Los controles de experiencia de usuario de MRTK aún no están conectados para establecer el estado en un elemento DataSource.
  • Los cambios dinámicos en los datos de lista actualizan completamente toda la lista en lugar de actualizarse incrementalmente.
  • La canalización de manipulación de datos aún no se ha implementado.
  • Aún no se admite el relleno de todos los componentes de experiencia de usuario en una pizarra.
  • Los nodos de DataSourceJson deben implementar la interfaz IDataNode para que sea interoperable con DataSourceObjects.