Compartir a través de

Marco de enlace y creación de temáticas de datos: MRTK3

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

¿Qué es el 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). Supongamos que el enlace tiene la configuración correcta y que los datos proporcionan las notificaciones adecuadas; cuando los datos cambian su valor, los elementos enlazados a los datos reflejan los cambios automáticamente.

Marcos de enlace de datos populares:

  • Delfos
  • Windows Presentation Framework (WPF .NET)
  • Windows Forms
  • Angular
  • Backbond
  • Enlaces de JavaFX

Diagrama de bloques de enlace de datos de Windows Presentation Framework

Enlace de datos de Windows Presentation Framework (WPF) Para obtener más información, consulte Introducción al enlace de datos: WPF.NET

Diagrama de bloques equivalente de MRTK

Diagrama de bloques equivalente de MRTK

Objetivos de diseño

  • Multiplataforma: implementación en cualquier lugar
  • Compatibilidad con cualquier estructura organizativa y origen de orígenes de datos
  • Fácil de integrar en bases de código existentes o de campo verde
  • Designer y fácil de usar para desarrolladores
  • Se puede habilitar o deshabilitar 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 de experiencia de usuario complejas
  • Fácil de aplicar a componentes de experiencia de usuario no MRTK existentes y elementos visuales nuevos
  • Enlazar cualquier tipo de datos, incluidos sprites, imágenes, materiales, animaciones y clips de audio
  • Capacidades fáciles de mejorar sin tocar la base de código existente
  • Uso eficaz de CPU, RAM, GC y tiempo de fotograma
  • Integrarse fácilmente con una amplia variedad de orígenes de datos locales o back-end
  • Cualquier combinación simultánea de orígenes de datos incrustados, en tiempo de ejecución y back-end
  • Controlar de forma eficaz colecciones de cualquier tamaño para la presentación de lista
  • Combinación de temáticas y enlace de datos para elementos de datos dinámicos que se pueden usar con temáticas
  • Validación y manipulación de datos de variables de forma abierta antes de presentar
  • Dependencias mínimas en otras funciones de MRTK
  • Compatible con MRTK v2 y MRTK3
  • Etiqueta blanca fácil y/o aplicación de personalización de marca a activos bursátiles con un esfuerzo mínimo

Características clave

  • Los orígenes de datos abiertos admiten cualquier estrategia de datos persistente, remota o ram.
  • Los consumidores de datos de composición abierta admiten cualquier enlace de experiencia de usuario y necesidades de creación de temáticas.
  • La detección automática entre orígenes de datos y consumidores simplifica la conexión.
  • 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 colección para la navegación de lista sin problemas.
  • Los objetos de colección se pueden agrupar y reutilizar para reducir la GC.
  • Puede asignar entre diferencias en los datos y ver los espacios de nombres de keypath.

Funcionalidad actual

1. Visualización de datos variables a través de consumidores de datos

Actualmente se admite:

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

2. Proporcione datos variables mediante diversos orígenes de datos:

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

3. Placer de elemento de lista para administrar la manifestación visual de una lista

4. Enumerar paginación, desplazamiento y virtualización

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

5. Enumeración de la agrupación prefabricada

  • Los objetos prefabricados se reutilizan y repoblan para reducir el gc y el tiempo de creación de instancias.

6. Aplicar temas dinámicamente a elementos en tiempo de ejecución

Funcionalidad en la hoja de ruta

Además de lo que ya está disponible, las principales prioridades para más funcionalidades incluyen:

1. Canalizaciones del manipulador de datos

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

2. Captura previa de elementos de lista predictiva para un desplazamiento/paginación más rápido/más suave

3. Más consumidores de datos

  • Establecer cualquier propiedad pública en un componente
  • Establecer el estado de activación o desactivación de la casilla
  • Establecer el valor del control deslizante
  • Establecer un botón de radio en un grupo
  • Propiedades de material individuales, como establecer color

4. Creación de temáticas

  • Vea los temas aplicados en Editor incluso cuando no se ejecuta la aplicación
  • Actualizar los objetos prefabricados para reflejar un tema aplicado para que se convierta en el tema predeterminado
  • Herencia de temas y estilos

Terminología

  • Origen de datos : cualquier proveedor de datos, ya sea de estado en tiempo de ejecución, persistente localmente o capturado de un servidor.
  • Proveedor de orígenes de datos : un monobehaviour simple que proporciona acceso a un origen de datos que puede no exponerse en el gráfico de la escena de Unity.
  • Tipo de origen de datos : un 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 desee actuar sobre los cambios de datos, normalmente un elemento visual, pero no es necesario. Por ejemplo, su propósito puede ser desencadenar acciones basadas en cambios en el valor de datos.
  • Controlador de datos : mecanismo para invocar una acción con el valor enlazado a datos asociado actualmente proporcionado como parámetro.
  • Keypath : selector de datos que hace referencia a un objeto específico en un origen de datos. Como se implementa actualmente, el formato de ruta de claves se modela después de los descriptores de acceso de datos JSON para descifrar cualquier combinación anidada de mapas, listas y elementos atómicos.
  • Ruta de acceso de clave local : ruta de acceso del lado consumidor de datos que se puede insertar permanentemente en un objeto prefabricado reutilizable. Mediante la resolución de entidades de colección y asignadores de Keypath, esto se convertirá automáticamente en una ruta de acceso de clave totalmente resuelta para un elemento específico de una colección. Cuando no se asocian a una colección, se pueden asignar directamente a un dato del origen de datos o se pueden modificar primero mediante un asignador de Keypath.

  • Ruta de claves totalmente resuelta : ruta de acceso de clave completa y absoluta que se asigna a un objeto específico de un origen de datos. Para los elementos de una colección, se trata de una combinación de la ruta de clave totalmente resuelta para una entidad de colección y una ruta de acceso de clave relativa (local) para un elemento de datos de esa entidad de colección.

  • Asignador de ruta de acceso de claves : asignador de espacio de nombres opcional entre las rutas de claves locales y los nombres de campo del origen de datos (por ejemplo, "link" <-> "URL").

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

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

  • Grupo de objetos de datos: prefabricados en espera con instancias listos para rellenarse con datos para la navegación de lista de baja GC.

  • Virtualización de listas : capacidad de rellenar, presentar y navegar listas de tamaño arbitrariamente grande.

  • Captura previa predictiva : captura previa de datos y rellenación de objetos prefabricados de colección para elementos que pueden verse pronto mediante el desplazamiento o la paginación.

  • Captura previa predictiva : captura previa de datos y rellenación de prefabricados de colecciones para elementos que pronto se pueden ver a través de desplazamiento o paginación.

Conceptos clave

Origen de datos

Un origen de datos es cualquier conjunto administrado de datos de tipo arbitrario y complejidad que se puede usar para rellenar vistas de datos a través de consumidores de datos. Los datos administrados por un origen de datos pueden ser estáticos o dinámicos. Cualquier cambio en los elementos de datos se notificará a los consumidores de datos que se hayan registrado para recibir notificaciones de cambio.

Proveedor de origen de datos

Interfaz sencilla que tiene un único método para recuperar un origen de datos. Esto está diseñado para permitir que los componentes del consumidor de datos detecten automáticamente un componente de scripting MonoBehavior en la jerarquía de objetos de juego. No es necesario implementar un origen de datos directamente en el propio objeto de juego. Esto resulta útil cuando un MonoBehaviour existente debe derivarse de otra clase y varias herencias impiden derivarse de DataSourceGOBase. También permite que más código no tenga dependencias de Unity.

Singleton del proveedor de origen de datos

DataSourceProviderSingleton MonoBehaviour permite especificar un origen de datos que se puede detectar automáticamente incluso si no está en la misma jerarquía GameObject que los DataConsumers que desean escucharlo. Simplemente coloque el DataSourceProviderSingletonelemento en cualquier lugar de la escena y rellene la Data Sources propiedad con los orígenes de datos que van a detectar los consumidores de datos. Como alternativa, los consumidores de datos guiarán a sus padres para encontrar un origen de datos adecuado, lo que implica que puede colocar un origen de datos que proporcione los datos deseados en cualquier lugar de la cadena primaria de esos consumidores de datos.

Ruta de acceso de clave (cadena)

Una ruta de acceso 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 en relación con todo el conjunto de datos estructurados. Se modela en el concepto de listas, diccionarios y primitivos de Javascript. Las rutas de acceso clave son instrucciones Javascript sintácticamente correctas para acceder a los datos que se pueden representar en JSON. La 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 clave de ejemplo:

  • temperatura
  • contacts[10].firstName
  • contacts
  • 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 necesaria, los especificadores de datos reales podrían ser cualquier método para describir qué datos 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 rutas de acceso de claves esperadas por el origen de datos, todo funcionará. Además, los asignadores de rutas de acceso de clave se pueden implementar para traducir entre diferentes esquemas.

Resolución de una ruta de acceso de clave

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

  1. 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. Ruta de acceso parcial (relativa) que representa un dato específico dentro de esa entrada de lista o mapa.

Esto permite tratar un subconjunto de los datos de forma que no importa dónde exista realmente en 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 por la entrada de esa lista a la que hace referencia la instancia actual.

Dado que una ruta de acceso de clave "totalmente resuelta" siempre se genera y consume en un origen de datos y rara vez debe modificarse por un DataConsumer u otro componente externo, puede tener cualquier estructura que tenga sentido para DataSource. Por ejemplo, si hay un objeto prefabricado para mostrar una entrada de lista para una foto y su título, fecha tomada y otros atributos, la ruta de acceso de clave local del objeto prefabricado podría tener este aspecto:

  • "photo_url"
  • "title"
  • "date_taken"
  • “description”

Las rutas de acceso de clave totalmente resueltas para una entrada prefabricada 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"

Asignador de ruta de acceso de clave (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 clave y seguir trabajando juntos.

Un objeto prefab para un elemento de uso común, como una pizarra para mostrar la información de contacto de una persona, puede contener campos variables administrados por los consumidores de datos. Para que esto sea posible, el identificador usado para cualquier aspecto variable del prefabricado necesita una manera de asignar al identificador el dato correcto en el origen de datos que, en cada uso del prefabricado, determinará el contenido de ese elemento variable. El asignador de ruta de acceso de clave hace que esto sea posible.

El objeto prefabricado se puede usar con diferentes orígenes de datos donde los datos se almacenan en una estructura organizativa diferente y usa nombres de campo. Para usar un objeto prefabricado de plantilla con cada origen de datos, un asignador de ruta de acceso de clave puede resolver las diferencias en la forma en que se organizan los datos.

Consumidor de datos (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 con 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. Siempre que los datos especificados hayan cambiado (o se sospeche que han cambiado), se notificará a los consumidores de datos.

Colección de consumidores de datos

Una colección de consumidores de datos tiene la capacidad agregada de administrar una lista de elementos similares. Esta lista puede ser todo el conjunto de datos administrado por un origen de datos o simplemente un subconjunto. Normalmente, los datos de cada elemento de la lista contienen tipos de información similares, pero 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 en 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, y la ruta de acceso de las fotos sería relativa a la persona y la ruta de acceso de la persona sería relativa a la lista primaria más cercana o a la raíz del conjunto de datos.

Al procesar colecciones, la ruta de clave resuelta correcta para la entrada específica de la colección se asigna a cada consumidor de datos que se encuentra en el objeto prefabricado que se crea una instancia de cada elemento de colección. A continuación, se usa para resolver completamente la ruta de acceso de la clave para los datos de vista relativos (locales) dentro de ese objeto prefabricado.

Placer de elemento de recopilación de datos

Un consumidor de datos de recopilación necesita un medio para rellenar las experiencias del usuario con listas de elementos visuales repetidos, como lo que se puede encontrar en una lista desplazable de productos, fotos o contactos. Esto se logra mediante la asignación de un placer de elemento al consumidor de datos de la colección. Este placer de elemento es la lógica que sabe cómo solicitar elementos de lista, aceptar prefabs 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 para las listas.

Creación de temas

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

Diagrama de bloques y flujo de datos

Flujo de datos de creación de temáticas de MRTK

Temática de MRTK

La temática 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 los proporciona un único origen de datos, como un objeto que admite scripts. También es posible que los datos de creación de temáticas se proporcionen según sea necesario o se dividan en grupos lógicos en función de su propósito.

Temática de MRTK3

Temática de MRTK3 combinada con enlace de datos

El enlace de datos y la creación de temáticas pueden coexistir para un único elemento de experiencia de usuario. Cualquier elemento de experiencia de usuario individual puede estar enlazado a datos y temáticamente simultáneamente. En este escenario, el flujo típico es que el dato procedente de un origen de datos se usa para derivar la ruta de clave de tema correcta. A continuación, esta ruta de acceso de claves se usa para recuperar un objeto del origen de datos del tema, normalmente un perfil scriptableObject, pero potencialmente cualquier origen de datos que pueda resolver una ruta de acceso de claves.

Para simplificar la configuración de la creación de temáticas y el enlace de datos, es posible crear perfiles de enlace procesados por bindingConfigurator en el momento de la creación de instancias.

  • un BindingConfigurator procesa un perfil de enlace para determinar los recursos dentro de un objeto prefabricado que se van a aplicar temáticamente y asocia tanto los elementos de datos enlazados como los elementos temáticos a Keypaths. A continuación, agrega apropiado DataConsumers para enlazar estos elementos visuales a los selectores de Keypaths correctos que se usarán para hacer referencia a datos específicos en uno o más DataSources, que suelen ser externos al propio objeto prefabricado.
  • Los datos de tema los proporciona un DataSource que contiene datos para cada ruta de acceso clave identificada en el perfil de enlace.
  • Un ThemeProvider script auxiliar facilita el uso de scriptableObject como DataSource elemento para la creación de temáticas.
  • El tema de la experiencia de usuario estándar lo proporciona ScriptableObjectMRTK_UX_ThemeProfile que está enlazado a en DataSourceReflection .ThemeProvider

Diagrama de flujo de DataSource del perfil de tema

Origen de datos incrustado

Un origen de datos incrustado es adecuado en dos situaciones:

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

DataSourceReflection

Esto puede convertir cualquier estructura o clase de C# en un mediante la DataSource reflexión para asignar rutas de claves a campos, propiedades, clases anidadas, matrices, listas o diccionarios. Se puede asociar a un ScriptableObject de Unity o a cualquier otra estructura o clase de C# donde existan datos de tema. El objeto con instancias que contiene los datos puede insertarse en dependencias y cambiarse en tiempo de ejecución.

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

DataSourceJson

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

DataSourceDictionary

Esta es una opción sencilla cuando una lista puramente plana es lo suficientemente buena para satisfacer la necesidad y para crear prototipos rápidamente. Se admiten todos los recursos de creación de temáticas, incluidos texto, recursos de Unity (por ejemplo, materiales, sprites e imágenes), recursos, streamingassets o incluso capturables externamente a través de una dirección URL.

Personalizado

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

UXComponentes de creación de temáticas

Los controles estándar de UXComponents proporcionados en el paquete UXComponents están configurados para admitir la creación de temáticas. Está desactivado de forma predeterminada, pero es fácil de habilitar.

Cada control, normalmente en la parte superior de GameObject del objeto prefabricado raíz, tiene un script denominado UXBindingConfigurator. Este script, si está habilitado, extraerá los scripts de enlace de datos necesarios para activar el tema. Asegúrese de importar también el paquete de enlace de datos y creación de temáticas.

Nota en TextMeshPro StyleSheets: Actualmente no es posible usar StyleSheets para aplicar estilo al estilo TextMeshPro Normal . Se puede usar cualquier otro estilo que se incluya en la hoja de estilos predeterminada de TextMeshPro. En los ejemplos se usa Body para solucionar esta limitación.

DataSourceThemeProvider

DataSourceThemeProvider MonoBehaviour se puede usar para que un ScriptableObject que contenga todas las referencias a todos los recursos de creación de temáticas funcione como origen de datos. Esto se muestra en la escena UXThemingExample.

ThemeSelector

ThemeSelector MonoBehaviour permite especificar y intercambiar fácilmente entre varios perfiles de ScriptableObject. Un ejemplo de uso de esto sería facilitar el cambio entre un tema "Oscuro" y "Claro". Agregue scriptableObjects a , Theme Profilesnormalmente en tiempo de diseño. A continuación, en tiempo de ejecución, cambie la Current Theme propiedad para cambiar el tema.

Creación de temáticas de consumidor de datos

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

La clase base DataConsumerThemeBase<T> proporciona lógica para usar un entero o un dato clave de un origen de datos principal para buscar el valor final deseado de una base de datos de tema secundaria. Para ello, asigne los datos de entrada a una ruta de acceso de clave de tema y, a continuación, use esa ruta de acceso de clave de tema para recuperar el valor final. Esto permite que cualquier elemento esté enlazado a datos y temático al mismo tiempo. Por ejemplo, imagine un campo de estado en una base de datos con los estados New, Started y Done representados por los valores 0, 1 y 2. Cada una de ellas se puede representar mediante un icono de Sprite. Para el enlace de datos, se usa un valor de 0 a 2 para buscar el sprite deseado. Con el tema y el enlace de datos, el perfil de tema apunta a la lista correcta de tres sprites en el perfil de tema y, a continuación, se usa el valor de 0 a 2 para seleccionar el sprite correcto de esa lista. Esto permite que el estilo de estos iconos difiera por tema.

Cuando se usan juntos tanto el tema en tiempo de ejecución como el enlace dinámico de datos, se puede especificar una clase DataConsumerThemeHelper en cualquier clase derivada de DataConsumerThemeBase para notificar cuándo ha cambiado un tema.

El intercambio de temas en tiempo de ejecución se realiza reemplazando los datos del 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 ScriptableObjects donde cada perfil representa un tema. Para todos los controles de experiencia de usuario de MRTK Core, el perfil de tema es un ScriptableObject denominado MRTK_UXComponents_ThemeProfile. El script auxiliar ThemeProvider.cs facilita el uso de este perfil o cualquier perfil de ScriptableObject como origen de datos.

El método de aplicación de 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.
  • la ruta de acceso del tema se usa 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.

Tipos de datos

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

Tipo de datos Descripción
Detección automática El dato se analiza y se detecta automáticamente la interpretación correcta. Consulte "Detección automática de tipo de datos" a continuación para obtener más información.
DirectValue Se espera que el dato sea del tipo deseado T (por ejemplo, Material, Sprite, Imagen) y se use directamente.
DirectLookup Índice entero o clave de cadena que se usa para buscar el valor deseado de 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 clave de tema especificada.
ThemeKeypathLookup Se usa un índice entero o una clave de cadena para buscar la ruta de clave de tema deseada.
ThemeKeypathProperty Nombre de propiedad de cadena que se anexará a la ruta de clave base del tema proporcionada en el tema.
ResourcePath Ruta de acceso del 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://").

Detección automática del tipo de datos

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 referencia principal.
  • En el valor temático recuperado a través de la referencia principal.
Tipo de referencia Consideraciones Tiene el asistente de temas Comportamiento
T No aplicable S/N Se usa directamente sin creación de temáticas
Entero cualquier cadena primitiva integral o que se pueda analizar Int32 No Se pasa como índice a GetObjectByIndex(n) derivado para recuperar el nº objeto de tipo T.
Entero cualquier cadena primitiva integral o que se pueda analizar Int32 Yes Indexe para capturar Nth theme keypath desde la búsqueda local y, a continuación, recuperar el objeto temático mediante la detección automática.
string Formato: "resource://{resourcePath}" S/N resourcePath se usa para recuperar el recurso de Unity.
string Formato: "file://{filePath} S/N filePath se usa para recuperar un recurso de streaming
string Otros No Se pasa como clave a GetObjectByKey() derivada para recuperar el objeto coincidente de tipo T.
string Otros Yes Clave para capturar la ruta de clave del tema coincidente de la búsqueda local y, a continuación, recuperar el objeto temático mediante la detección automática.

Ejemplo para recuperar un icono de estado temático de una base de datos que contiene un valor de estado numérico:

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

TextMeshPro StyleSheets

Theming es capaz de activar hojas de estilos TMPro. "Configuración de TMP" ScriptableObject determina dónde se espera que las hojas de estilos estén en los recursos. Es la propiedad "Default Font Asset => Path".

Asegúrese de colocar cualquier stylesheets específico de la aplicación en la misma ruta secundaria fuera de Recursos. Si desea organizarlos de forma diferente, asegúrese de actualizar "Configuración de TMP" para que coincidan.

Hacer que los nuevos controles de experiencia de usuario sean personalizables

Si va a desarrollar nuevos controles de experiencia de usuario, es relativamente fácil hacerlos themables. En la medida en que el control usa Materiales, Sprites y otros recursos que ya están en uso por otros controles de experiencia de usuario, generalmente se trata de nombrar los distintos objetos de juego de una manera reconocible.

Es posible heredar de MRTK_UXCore_ThemeProfile y agregar más campos themables, o apuntar los controles a su propio ScriptableObject. No hay nada mágico en los proporcionados; la organización de ScriptableObject determinará las rutas de acceso clave necesarias para acceder a elementos de datos individuales mediante la reflexión de C#.

Al agregar un script de BindingConfigurator.cs al nivel superior del nuevo control, puede especificar su propio objeto BindingProfile ScriptableObject serializado. Esto proporcionará el nombre de GameObject necesario a las asignaciones de KeyPath necesarias para asociar los elementos que se pueden usar con los datos proporcionados en el perfil de tema. Este script agregará automáticamente los componentes de DataConsumerXXX necesarios en tiempo de ejecución para admitir el tema que desea usar.

Introducción

Requisitos

  • Unity 2020.3 LTS o posterior
  • TextMeshPro 2.1.4 o posterior

Escenas de ejemplo

Para obtener un primer paso, eche un vistazo a las distintas escenas de ejemplo de enlace de datos en el paquete ejemplos de MRTK y examine cómo se configuran los distintos orígenes de datos MonoBehaviours. En general, los scripts de enlace de datos solo deben colocarse en el GameObject de nivel más alto de un objeto prefab o un conjunto relacionado de elementos de experiencia de usuario.

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

Nota:

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

Assets/DataBinding Example/Scenes/DataBindingExamples.scene

Esta escena que muestra una variedad de escenarios de datos variables. Simplemente cargue la escena y reproduzca. Algunas cosas que hay que tener en cuenta:

  • El campo Entrada de texto de los componentes de TextMeshPro contiene variables que tienen este aspecto: {{ firstName }}. Estos marcadores se usan directamente como rutas de claves locales.

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

  • Varios componentes del mismo tipo pueden compartir un único consumidor de datos 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 superior en la jerarquía de GO.

  • Un objeto de juego primario tiene un componente de origen de datos que proporciona datos para todos los objetos de juego secundarios que presentan un conjunto relacionado de información de variables.

  • Un consumidor de datos de colección especifica un objeto prefabricado que contiene los consumidores de datos que se usarán para rellenar ese objeto prefabricado con datos variables.

Ejemplo de creación de temáticas de recursos/experiencia de usuario/escenas/audioLameación

En este ejemplo se usa el tema para cambiar AudioClips entre un conjunto para Piano y uno para Xilófono.

Ejemplo de creación de temáticas de recursos/experiencia de usuario/escenas/batteryLevelExample

En este ejemplo se combina el tema y el enlace de datos para mostrar un nivel de batería tanto como un valor numérico como un icono. La creación de temas se usa para seleccionar entre un tema "cargarlos" y un tema "no cargar". Está diseñado para cumplir los siguientes objetivos:

  • Todos los recursos visuales pueden existir en un solo ScriptableObject elemento que actúa como perfil de tema.
  • El número de sprites para los estados de "carga" puede diferir del número del estado "no cargando".
  • El algoritmo para asignar el nivel de batería notificado a un sprite determinado puede ser no lineal y diferir entre los estados de "carga" y "no carga".
  • Todos los recursos visuales pueden existir en un solo ScriptableObject elemento que actúa como perfil de tema.
  • El número de sprites para los estados de carga puede diferir del número de estado de no carga.
  • Algoritmo para asignar el nivel de batería notificado al que el sprite puede ser no lineal y difiere 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 tema y enlace de datos. En una aplicación de producción para la 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 que los localizadores de recursos para los sprites.

Ejemplo de creación de temáticas de recursos/experiencia de usuario/escenas/UXThemingExample

En este ejemplo se muestra cómo cambiar el tema de una aplicación completa y también se muestra cómo usar como DataSourceGODictionary origen de datos para administrar una variedad de contenido textual que se mostrará en la experiencia de usuario. En un escenario más completo, 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 que le ayudará a empezar a trabajar rápidamente:

  1. Cree una nueva escena.
  2. En el menú Mixed Reality Toolkit, seleccione la opción Agregar a escena y Configurar.
  3. Cree un objeto de juego vacío y cámbiele el nombre "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 objeto de juego Enlace de datos. Agregará un lienzo y, a continuación, un objeto "Text (TMP)".
  6. Seleccione el objeto Texto (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 Texto del consumidor de datos.
  2. Ejecute el proyecto. Cada 15 segundos, se mostrará una actividad diferente.

Felicidades. 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 algorítmicamente, en RAM, en disco o capturados de 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 denominada DataSourceBase. Lo más probable es que quiera derivar de esta clase para agregar la funcionalidad de administración de datos específica 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 un MonoBehavior que se puede colocar en un Objeto GameObject como componente. Es un proxy fino que está diseñado para delegar el trabajo en un origen de datos principal no específico de Unity.

Un origen de datos puede exponer la capacidad de manipular datos dentro de Unity Editor. 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 Inspector u otros medios para configurar los datos.

Escribir un nuevo consumidor de datos

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

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

La mayor parte 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 objeto prefabricado adecuado o podría significar capturar más datos de un servicio en la nube, como un sistema de administración de contenido.

Escribir un placer de elemento de recopilación de datos

Un placer de elemento de recopilación de datos es responsable de administrar qué partes de una colección están 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 de registros de millones gigantes.

Todos los placeres de elemento deben proporcionar la interfaz IDataCollectionItemPlacer. Parte de la funcionalidad básica se ofrece en una clase base denominada DataColletionItemPlacerGOBase. Todos los placeres de elemento deben derivarse de esta clase.

Limitaciones conocidas y características que faltan

  • Aún no se ha integrado con los controles basados en Canvas y las listas desplazables de Unity.
  • La integración de INotifyPropertyChanged de .NET aún no está implementada.
  • La escena de ejemplo que captura imágenes de Flickr y trymrtk.com no funciona en HoloLens debido a un error 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 .DataSource
  • Los cambios dinámicos en los datos de lista actualizan por completo toda la lista en lugar de actualizarse incrementalmente.
  • La canalización de manipulación de datos aún no se ha implementado
  • La rellenación de todos los componentes de la experiencia de usuario en una pizarra aún no es totalmente compatible.
  • Los nodos DataSourceJson deben implementar IDataNode la interfaz para que sea interoperable con DataSourceObjects.