Infrastructure de liaison et de thème de données — MRTK3

Bienvenue dans l’infrastructure de liaison de données et de thème MRTK3. Cette infrastructure est conçue pour faciliter la création d’éléments visuels qui peuvent être remplis et mis à jour dynamiquement au moment de l’exécution par les données fournies à partir d’une ou plusieurs sources de données.

Qu’est-ce que la liaison de données ?

La liaison de données est le processus qui établit une connexion entre l’expérience utilisateur (vue) d’une application et les données présentées (modèle). Supposons que la liaison a les paramètres corrects et que les données fournissent les notifications appropriées ; lorsque les données changent de valeur, les éléments liés aux données reflètent automatiquement les modifications.

Frameworks de liaison de données populaires :

  • Delphi
  • Windows Presentation Framework (WPF .NET)
  • Windows Forms
  • Angle
  • Backbond
  • Liaisons JavaFX

Diagramme de bloc de liaison de données Windows Presentation Framework

Databinding Windows Presentation Framework (WPF) Pour plus d’informations, consultez Vue d’ensemble de la liaison de données - WPF.NET

Diagramme de blocs équivalent MRTK

Diagramme de blocs équivalent MRTK

Objectifs de conception

  • Multiplateforme : déployer n’importe où
  • Prendre en charge toute structure organisationnelle et origine des sources de données
  • Intégration facile dans des bases de code existantes ou greenfield
  • Designer et convivial pour les développeurs
  • Peut être activé/désactivé à tout moment pendant le cycle de vie de l’application
  • Prendre en charge des scénarios d’entreprise réels : bases de données principales, modèles de préfabriqués d’expérience utilisateur complexes
  • Facile à appliquer aux composants d’expérience utilisateur non MRTK existants et aux nouveaux éléments visuels
  • Lier n’importe quel type de données, y compris les sprites, les images, les matériaux, les animations et les clips audio
  • Fonctionnalités faciles à améliorer sans toucher à la base de code existante
  • Utilisation efficace du processeur, de la RAM, du GC et du délai d’exécution
  • S’intégrer facilement à un large éventail de sources de données locales ou principales
  • Toute combinaison simultanée de sources de données principales et d’état d’exécution incorporées
  • Gérer efficacement les collections de toutes tailles pour la présentation de liste
  • Combinaison de thèmes et de liaison de données pour des éléments de données dynamiques à thème
  • Valider et manipuler les données de variables de manière ouverte avant de présenter
  • Dépendances minimales vis-à-vis d’autres fonctionnalités MRTK
  • Compatible avec MRTK v2 et MRTK3
  • Facile à mettre en marque blanche et/ou à appliquer une personnalisation aux ressources boursières avec un minimum d’effort

Fonctionnalités clés

  • Les sources de données ouvertes prennent en charge toute stratégie de données persistante, distante ou RAM.
  • Les consommateurs de données ouverts prennent en charge tous les besoins en matière de liaison d’expérience utilisateur et de thème.
  • La découverte automatique entre les sources de données et les consommateurs simplifie la connexion.
  • Configuration automatique facultative à partir d’un profil de liaison
  • Le modèle de données découplé et la vue prennent en charge les modèles MVC et MVVM.
  • Collections virtualisées avec navigation via la pagination et le défilement.
  • Prérécupération prédictive des éléments de collection pour une navigation fluide dans la liste.
  • Les objets de collection peuvent être mis en pool et réutilisés pour réduire le gc.
  • Peut mapper entre les différences de données et afficher les espaces de noms keypath.

Fonctionnalités actuelles

1. Visualiser des données variables via des consommateurs de données

Actuellement pris en charge :

  • TextMeshPro et TextMesh text
  • Feuilles de style de texte (pour les thèmes et l’accessibilité)
  • Texture de sprite
  • Déclencheur booléen
  • Texture quad
  • Icônes de police
  • Collections : listes de taille arbitraire contenant des préfabriqués remplis avec des données variables
  • Tout autre consommateur prenant en charge l’interface IDataConsumer (directement ou via des dérivations de classes de base)

2. Fournissez des données variables à l’aide de différentes sources de données :

  • Texte JSON (directement ou par extraction d’URL)
  • Dictionnaire des éléments de données variables
  • Objet - Données structurées basées sur des nœuds
  • Réflexion d’un objet C#
  • Données modifiées par programmation
  • Toute autre méthode prenant en charge l’interface IDataSource

3. Placer un élément de liste pour gérer la manifestation visuelle d’une liste

4. Lister la pagination, le défilement et la virtualisation

  • Les données sont extraites uniquement lorsqu’elles sont visibles ou en cours de traitement
  • Prend en charge les jeux de données back-end arbitrairement volumineux
  • La récupération est équilibrée sur plusieurs images

5. Lister le regroupement de préfabriqués

  • Les préfabriqués sont réutilisés et remplis à nouveau pour réduire le temps de gc et d’instanciation.

6. Appliquer des thèmes dynamiquement aux éléments au moment de l’exécution

Fonctionnalités sur la feuille de route

En plus de ce qui est déjà disponible, les principales priorités pour d’autres fonctionnalités sont les suivantes :

1. Pipelines de manipulateur de données

  • Conversion entre les valeurs côté données et côté vue
  • Localisation (intégration transparente avec la localisation Unity)
  • Mise en forme
  • Validation

2. Prérécupération d’élément de liste prédictive pour un défilement/pagination plus rapide/plus fluide

3. Plus de consommateurs de données

  • Définir une propriété publique sur un composant
  • Définir l’état activé/désactivé de la case à cocher
  • Définir la valeur du curseur
  • Définir une case d’option dans un groupe
  • Propriétés material individuelles, telles que définir la couleur

4. Thème

  • Afficher les thèmes appliqués dans l’éditeur même quand l’application n’est pas en cours d’exécution
  • Mettre à jour les préfabriqués pour refléter un thème appliqué afin qu’il devienne le thème par défaut
  • Héritage de thème/style

Terminologie

  • Source de données : tout fournisseur de données, qu’il s’agisse d’un état d’exécution, d’une persistance locale ou d’une extraction à partir d’un serveur.
  • Fournisseur de source de données : monobehaviour simple qui fournit l’accès à une source de données qui peut ne pas être exposée dans le graphique de scène Unity.
  • Type de source de données : nom unique attribué à la source de données afin que les consommateurs de données puissent spécifier la ou les sources de données souhaitées par leur nom.
  • Consommateur de données : tout consommateur de données qui souhaite agir en cas de modifications de données, généralement un élément visuel, mais qui n’est pas obligatoire. Par exemple, son objectif peut être de déclencher des actions basées sur des modifications de valeur de données.
  • Contrôleur de données : mécanisme permettant d’appeler une action avec la valeur liée aux données actuellement associée fournie en tant que paramètre.
  • Keypath : sélecteur de données qui fait référence à un objet spécifique dans une source de données. Tel qu’il est actuellement implémenté, le format keypath est modélisé d’après les accesseurs de données JSON pour déchiffrer toute combinaison imbriquée de cartes, de listes et d’éléments atomiques.
  • Local Keypath : chemin de clé côté consommateur de données qui peut être incorporé de manière permanente dans un préfabriqué réutilisable. Grâce à la résolution des entités de collection et des mappeurs Keypath, sont automatiquement convertis en un chemin de clé entièrement résolu pour un élément spécifique d’une collection. Lorsqu’ils ne sont pas associés à une collection, ils peuvent être mappés directement à une référence dans la source de données ou par le biais d’un mappeur Keypath.

  • Chemin de clé entièrement résolu : chemin de clé complet et absolu mappé à un objet spécifique dans une source de données. Pour les éléments d’une collection, est une combinaison du chemin de clé entièrement résolu pour une entité de collection et d’un chemin de clé relatif (local) pour un élément de données de cette entité de collection.

  • Mappeur keypath : mappeur d’espace de noms facultatif entre les chemins de clés locaux et les noms de champs de source de données (par exemple « lien » <-> « URL »).

  • Thème : source de données qui fournit un ensemble de différents éléments et styles nécessaires pour obtenir une esthétique visuelle spécifique.

  • Placeur d’éléments : compagnon DataConsumerCollection chargé de placer des éléments visibles dans une scène.

  • Pool d’objets de données : préfabriqués de secours instanciés et prêts à être renseignés avec des données pour la navigation dans une liste à faible gc.

  • Virtualisation de liste : possibilité de remplir, de présenter et de parcourir des listes de taille arbitrairement volumineuse.

  • Prérécupération prédictive : prérécupération des données et remplissage des préfabriqués de collection pour les éléments qui peuvent bientôt être vus par défilement/pagination.

  • Prérécupération prédictive : prérécupération des données et remplissage des préfabriqués de collection pour les éléments qui peuvent bientôt être vus par défilement/pagination.

Concepts clés

Source de données

Une source de données est un ensemble managé de données de type(s) arbitraire(s) et de complexité qui peut être utilisé pour remplir des vues de données via des consommateurs de données. Les données gérées par une source de données peuvent être statiques ou dynamiques. Toutes les modifications apportées aux éléments de données sont signalées aux consommateurs de données qui se sont inscrits pour recevoir des notifications de modification.

Fournisseur de source de données

Une interface simple qui a une seule méthode pour récupérer une source de données est conçue pour permettre à un composant de script MonoBehavior d’être découvert automatiquement dans la hiérarchie des objets de jeu par des composants consommateurs de données. Il n’est pas nécessaire d’implémenter une source de données directement sur l’objet de jeu lui-même. Ce qui est utile lorsqu’un MonoBehaviour existant doit dériver d’une autre classe et que plusieurs héritages empêchent la dérivation de DataSourceGOBase. Il permet également à davantage de code d’avoir aucune dépendance Unity.

Singleton du fournisseur de source de données

Le DataSourceProviderSingleton MonoBehaviour permet de spécifier une source de données qui peut être découverte automatiquement même si elle ne se trouve pas dans la même hiérarchie GameObject que les DataConsumers qui souhaitent l’écouter. Placez n’importe DataSourceProviderSingletonoù dans la scène et renseignez la Data Sources propriété avec toutes les sources de données découvertes par les consommateurs de données. Sinon, les consommateurs de données guident leurs parents pour trouver une source de données appropriée, ce qui implique que vous pouvez placer une source de données qui fournit les données souhaitées n’importe où dans la chaîne parente de ces consommateurs de données.

Chemin de la clé (chaîne)

Un chemin d’accès clé est le mécanisme permettant d’identifier de manière unique toute information dans une source de données.

Bien qu’un chemin d’accès clé puisse être n’importe quel identificateur unique par élément de données, les implémentations actuelles utilisent un spécificateur logique lisible par l’utilisateur qui indique la position de navigation des données d’intérêt par rapport à l’ensemble du jeu de données structuré. Il est modélisé sur le concept javascript de listes, de dictionnaires et de primitives. Les chemins de clé sont des instructions JavaScript syntaxiquement correctes pour accéder aux données qui peuvent être représentées dans JSON. L’avantage de cette approche est qu’elle est bien corrélée avec JSON et XML qui sont les deux moyens les plus répandus de transférer des informations à partir des services principaux.

Exemples de chemins de clé :

  • Température
  • contacts[10].firstName
  • contacts
  • contacts[10].adresses[3].ville
  • [10].title
  • kingdom.animal.mammal.aardvark.diet.foodtypes.termites

Étant donné qu’un chemin de clé est une chaîne arbitraire sans taxonomie requise, les spécificateurs de données réels peuvent être n’importe quelle méthode pour décrire les données à récupérer. XPath de XML est un exemple de schéma de chemin de clé viable qui fonctionne avec des sources de données. Tant que les chemins de clés fournis par le consommateur de données sont cohérents avec les chemins de clés attendus par la source de données, tout fonctionne. En outre, les mappeurs de chemins de clés peuvent être implémentés pour traduire entre différents schémas.

Résolution d’un chemin de clé

La résolution d’un chemin d’accès de clé implique la combinaison de deux chemins de clés :

  1. Chemin de clé absolu qui décrit comment accéder à un sous-ensemble spécifique d’un jeu de données plus volumineux, tel qu’une entrée dans une liste de nombreuses entrées.
  2. Chemin de clé partiel (relatif) qui représente une référence spécifique dans cette entrée de liste ou de carte.

Cela permet de traiter un sous-ensemble des données de manière à ce qu’il n’importe pas où, dans une hiérarchie de jeu de données plus grande, il existe réellement. L’utilisation la plus critique de cette capacité consiste à décrire les données d’une seule entrée dans une liste sans se soucier de l’entrée dans cette liste que le instance actuel fait référence.

Étant donné qu’un chemin de clé « entièrement résolu » est généré et consommé par une Source de données et qu’il est rarement modifié par un DataConsumer ou un autre composant externe, il peut avoir n’importe quelle structure qui a un sens pour la Source de données. Par exemple, s’il existe un préfabriqué pour afficher une entrée de liste pour une photo et son titre, la date de prise et d’autres attributs, le chemin de clé local dans le préfabriqué peut ressembler à ceci :

  • « photo_url »
  • « title »
  • « date_taken »
  • « description »

Les chemins d’accès de clé entièrement résolus pour une entrée préfabriquée dans une liste peuvent ressembler à ceci :

  • « 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 »

Mappeur de chemin de clés (IDataKeyPathMapper)

Un mappeur de chemin de clés permet aux sources de données et aux consommateurs de données d’utiliser différents espaces de noms et conventions pour les chemins de clés tout en continuant à fonctionner ensemble.

Un préfabriqué pour un élément couramment utilisé, tel qu’une ardoise pour afficher les informations de contact d’une personne, peut contenir des champs variables gérés par les consommateurs de données. Pour utiliser, l’identificateur utilisé pour n’importe quel aspect variable du préfabriqué a besoin d’un moyen de mapper à l’identificateur pour la référence correcte dans la source de données qui, dans chaque utilisation du préfabriqué, détermine le contenu de cet élément variable. Le mappeur de chemin d’accès de clé rend cela possible.

Le préfabriqué peut être utilisé avec différentes sources de données où les données sont stockées dans une structure organisationnelle différente et utilisent des noms de champs. Pour utiliser un préfabriqué de modèle avec chaque source de données, un mappeur de chemin de clés peut résoudre les différences dans l’organisation des données.

Consommateur de données (IDataConsumer)

Objet qui sait comment consommer des informations gérées par une source de données et utiliser ces données pour remplir les vues de données.

Les consommateurs de données peuvent s’inscrire auprès d’une source de données pour être avertis de toute modification apportée à un élément de données qui existe à un chemin de clé spécifié dans un jeu de données. Chaque fois que les données spécifiées changent (ou sont suspectées de modification), le ou les consommateurs de données sont avertis.

Collecte de consommateurs de données

Une collection de consommateurs de données a la possibilité supplémentaire de gérer une liste d’éléments similaires. Cette liste peut être l’intégralité du jeu de données géré par une source de données, ou simplement un sous-ensemble. En règle générale, les données de chaque élément de la liste contiennent des types d’informations similaires, mais ce n’est pas obligatoire. Les sources de données et les consommateurs de données peuvent prendre en charge des listes imbriquées, telles qu’une liste de mots clés associés à chaque photo dans une liste de photos associées à chaque personne dans une liste de contacts. Le chemin de clé des mots clés est relatif à la photo, et le chemin de clé pour les photos est relatif à la personne, et le chemin de clé de la personne est relatif à la liste parente la plus proche ou à la racine du jeu de données.

Lors du traitement des collections, le chemin de clé résolu correct pour l’entrée spécifique de la collection est affecté à chaque consommateur de données trouvé dans le préfabriqué instancié pour chaque élément de collection. Il est utilisé pour résoudre entièrement le chemin de clé pour toutes les données de vue (locale) relatives dans ce préfabriqué.

Placer d’élément de collecte de données

Un consommateur de données de collection a besoin d’un moyen de remplir les expériences utilisateur avec des listes d’éléments visuels récurrents, tels que ce qui peut être trouvé dans une liste déroulante de produits, de photos ou de contacts. Pour ce faire, affectez un placer d’élément au consommateur de données de collecte. Ce placer d’élément est la logique qui sait demander des éléments de liste, accepter des préfabriqués remplis avec des données variables, puis les présenter à l’utilisateur, généralement en les insérant dans une liste gérée par un composant de disposition d’expérience utilisateur pour les listes.

Thèmes

Le thème utilise toute la plomberie des sources de données et des consommateurs de données. Il est possible de thèmer n’importe quelle hiérarchie de GameObjects, qu’ils soient statiques ou liés dynamiquement à d’autres sources de données. Le résultat permet d’appliquer à la fois la liaison de données et le thème. Il est même possible de thèmer les données provenant d’une autre source de données.

Diagramme de blocs et flux de données

Flux de données de thème MRTK

Thème MRTK

Le thème est la capacité à changer l’esthétique visuelle de nombreux éléments d’expérience utilisateur à la fois. En règle générale, toutes les données nécessaires pour spécifier un thème sont fournies par une seule source de données telle qu’un objet scriptable. Il est également possible que les données de thème soient fournies en fonction des besoins ou divisées en groupes logiques en fonction de leur objectif.

Thème MRTK3

Thèmes MRTK3 combinés à la liaison de données

La liaison de données et le thème peuvent coexister pour un seul élément d’expérience utilisateur. N’importe quel élément d’expérience utilisateur individuel peut être simultanément à thème et lié aux données. Dans ce scénario, le flux classique est que la référence provenant d’une source de données est utilisée pour dériver le chemin de clé de thème correct. Ce chemin de clé est ensuite utilisé pour récupérer un objet à partir de la source de données du thème, généralement un profil ScriptableObject, mais potentiellement n’importe quelle source de données pouvant résoudre un chemin de clé.

Pour simplifier la configuration des thèmes et de la liaison de données, il est possible de créer des profils de liaison traités par un BindingConfigurator au moment de l’instanciation.

  • Un BindingConfigurator traite un profil de liaison pour déterminer les ressources d’un préfabriqué qui doivent être à thème et associe à la fois des éléments de données liés et des éléments pouvant faire l’objet d’un thème à Keypaths. Il ajoute ensuite approprié DataConsumers pour lier ces éléments visuels aux sélecteurs Keypaths corrects qui sont utilisés pour référencer des données spécifiques dans un ou plusieurs DataSources, qui sont généralement externes au préfabriqué lui-même.
  • Les données de thème sont fournies par un DataSource qui contient des données pour chaque keypath identifié dans le profil de liaison.
  • Un ThemeProvider script d’assistance facilite l’utilisation d’un ScriptableObject comme DataSource thème.
  • Le thème d’expérience utilisateur standard est fourni par l’objet MRTK_UX_ThemeProfileScriptableObject qui est lié à un DataSourceReflection dans le ThemeProvider.

Diagramme de flux de source de données de profil de thème

Source de données incorporée

Une source de données incorporée est appropriée dans deux situations :

  1. Lorsque chaque instance du préfabriqué peut avoir des paramètres de thème différents et nécessite sa propre source de données distincte.
  2. Lorsque toutes les instances de ce préfabriqué sont régies par un profil de thème persistant commun (par exemple, ScriptableObject) et peuvent être fournies par le biais de la source de données incorporée afin qu’il n’y ait aucune dépendance externe à établir.

DataSourceReflection

Cela peut transformer n’importe quel struct ou classe C# en un DataSource en utilisant la réflexion pour mapper des chemins de clés à des champs, des propriétés, des classes imbriquées, des tableaux, des listes ou des dictionnaires. Il peut être associé à un ScriptableObject Unity ou à tout autre struct ou classe C# où des données de thème existent. L’objet instancié contenant les données peut être injecté et modifié au moment de l’exécution.

  1. Objet scriptable : utile pour les thèmes statiques partagés entre de nombreux préfabriqués.
  2. Classe ou struct C# nonpersisted : utile pour les modifications dynamiques au moment de l’exécution du thème.

DataSourceJson

Si les données existent sous forme json de texte, elles sont gérées en mappant des chemins de clés au json DOM. Les ressources binaires peuvent être récupérées à partir des ressources Unity, de StreamingAssets ou même d’une URL extraite.

DataSourceDictionary

Il s’agit d’une option simple lorsqu’une liste purement plate est suffisante pour répondre aux besoins et pour un prototypage rapide. Toutes les ressources de thème sont prises en charge, notamment le texte, les ressources Unity (par exemple, les matériaux, les sprites et les images), les ressources, les streamingassets ou même les ressources extraites en externe via une URL.

Personnalisé

Toute source de données personnalisée qui implémente l’interface simple IDataSource ou dérive de DataSourceBase ou DataSourceGOBase peut être utilisée pour répondre à des besoins personnalisés.

UXComponents de thèmes

Les contrôles UXComponents standard fournis dans le package UXComponents sont tous configurés pour prendre en charge les thèmes. Il est DÉSACTIVÉ par défaut, mais il est facile à activer.

Chaque contrôle, généralement sur le GameObject le plus haut du préfabriqué racine, a un script appelé UXBindingConfigurator. Ce script, s’il est activé, extrait les scripts de liaison de données nécessaires pour activer les thèmes. Veillez également à importer le package Liaison de données et thème.

Remarque sur les feuilles de style TextMeshPro : il n’est actuellement pas possible d’utiliser StyleSheets pour appliquer un style au style TextMeshPro Normal . Tout autre style inclus dans la feuille de style par défaut de TextMeshPro peut être utilisé. Les exemples utilisent Body pour contourner cette limitation.

DataSourceThemeProvider

Le DataSourceThemeProvider MonoBehaviour peut être utilisé pour faire en sorte qu’un ScriptableObject contenant toutes les références à toutes les ressources de thème fonctionne en tant que source de données. Cela est illustré dans la scène UXThemingExample.

ThemeSelector

MonoBehaviour ThemeSelector permet de spécifier et d’échanger facilement entre plusieurs profils ScriptableObject. Un exemple d’utilisation serait de faciliter le basculement entre un thème « Sombre » et un thème « Clair ». Ajoutez scriptableObjects au Theme Profiles, généralement au moment du design. Ensuite, au moment de l’exécution, modifiez la Current Theme propriété pour modifier le thème.

Thème des consommateurs de données

Les thèmes sont effectués par les consommateurs de données, en particulier ceux qui héritent de DataConsumerThemeBase<T>, DataConsumerTextStyle et les classes DataConsumer personnalisées que tout développeur peut implémenter pour améliorer la prise en charge de la thémage.

La classe de base T> DataConsumerThemeBase<fournit une logique permettant d’utiliser un entier ou une donnée clé d’une source de données primaire pour rechercher la valeur finale souhaitée à partir d’une base de données de thème secondaire. Pour ce faire, mappez les données d’entrée à un chemin de clé de thème, puis utilisez ce chemin de clé de thème pour récupérer la valeur finale. Cela permet à n’importe quel élément d’être à la fois lié aux données et à thème. Par exemple, imaginez un champ status dans une base de données avec les états Nouveau, Démarré et Terminé représentés par les valeurs 0, 1 et 2, où chacun est représenté par une icône Sprite. Pour la liaison de données, une valeur comprise entre 0 et 2 est utilisée pour rechercher le sprite souhaité. Avec les thèmes et la liaison de données, le profil de thème pointe vers la liste correcte de trois sprites dans le profil de thème, puis la valeur comprise entre 0 et 2 est utilisée pour sélectionner le sprite correct dans cette liste. Cela permet au style de ces icônes de varier selon le thème.

Lorsque les thèmes d’exécution et la liaison de données dynamiques sont utilisés ensemble, une classe DataConsumerThemeHelper peut être spécifiée dans n’importe quelle classe dérivée de DataConsumerThemeBase pour avertir en cas de modification d’un thème.

L’échange de thèmes au moment de l’exécution consiste à remplacer les données au niveau de la source de données du thème par un nouveau jeu de données disposé dans la même topologie de modèle objet de données. DataSourceReflection peut être utilisé avec ScriptableObjects où chaque profil représente un thème. Pour tous les contrôles MRTK Core UX, le profil de thème est un ScriptableObject nommé MRTK_UXComponents_ThemeProfile. Le script d’assistance ThemeProvider.cs facilite l’utilisation de ce profil ou de n’importe quel profil ScriptableObject comme source de données.

La méthode d’application d’un thème aux données dynamiques peut être détectée automatiquement dans la plupart des cas, ou elle peut être spécifiée explicitement.

Lorsque la référence est utilisée pour sélectionner l’élément approprié dans la source de données du thème, le processus est le suivant :

  • une référence de la source de données primaire est utilisée pour sélectionner ou construire le chemin de clé de thème approprié
  • le chemin de clé de thème est utilisé pour récupérer une valeur de la source de données de thème spécifiée sur dataConsumerThemeHelper
  • la valeur du thème récupéré est analysée pour détecter automatiquement la méthode de récupération correcte
  • l’élément de données final de type correct (par exemple, Material, Sprite ou Image) est ensuite récupéré à l’aide de la méthode détectée automatiquement.

Types de données

Le type de données attendu de la référence utilisée pour récupérer l’objet souhaité peut être l’un des suivants :

Type de données Description
Détection automatique La référence est analysée et l’interprétation correcte est détectée automatiquement. Pour plus d’informations, consultez « Détection automatique du type de données ».
DirectValue La référence est censée être de type T souhaité (par exemple, Matériau, Sprite, Image) et utilisée directement.
DirectLookup Clé d’index ou de chaîne intégrale utilisée pour rechercher la valeur souhaitée dans une table de recherche locale.
StaticThemedValue L’objet à thème statique du type correct est récupéré à partir de la source de données de thème au niveau du chemin de clé de thème spécifié.
ThemeKeypathLookup Un index intégral ou une clé de chaîne est utilisé pour rechercher le chemin de clé de thème souhaité.
ThemeKeypathProperty Nom de propriété de chaîne ajouté au chemin de clé de base du thème fourni dans le thème.
ResourcePath Chemin d’accès à la ressource pour récupérer la valeur d’une ressource Unity (peut commencer par « resource:// »).
FilePath Chemin d’accès de fichier pour récupérer une ressource de streaming Unity (peut commencer par « file:// »).

Détection automatique du type de données

Détection automatique analyse les données reçues et décide automatiquement de la méthode de récupération. Dans le tableau, T représente le type souhaité, tel que Material, Sprite, Image. La détection automatique peut se produire à deux endroits du processus :

  • Sur la valeur de référence primaire elle-même.
  • Sur la valeur à thème récupérée via la référence principale.
Type de référence Considérations Dispose d’un helper de thème Comportement
T s/o O/N Utilisé directement sans thème
int toute chaîne primitive intégrale ou int32 parsable Non Passé en tant qu’index à getObjectByIndex(n) dérivé pour récupérer le nième objet de type T.
int toute chaîne primitive intégrale ou int32 parsable Oui Index pour extraire nième chemin de clé de thème à partir de la recherche locale, puis récupérer l’objet à thème via la détection automatique.
string Format : « resource://{resourcePath} » O/N resourcePath est utilisé pour récupérer la ressource Unity
string Format : « file://{filePath} O/N filePath est utilisé pour récupérer une ressource de streaming
string Autre Non Passé en tant que clé à getObjectByKey() dérivé pour récupérer l’objet correspondant de type T.
string Autre Oui Clé pour extraire le chemin de clé de thème correspondant à partir de la recherche locale, puis récupérer l’objet à thème via la détection automatique.

Exemple de récupération d’une icône de status à thème à partir d’une base de données contenant une valeur de status numérique :

  1. Le chemin de clé d’une icône de status dans la base de données est status.sprite_index.
  2. La valeur récupérée pour status.sprite_index est 2, ce qui signifie « annulé » status.
  3. L’entrée N=2 (en d’autres termes, troisième) dans la recherche DataConsumerSprite est définie sur « Status.Icons.Cancelled ».
  4. Chemin de clé utilisé pour récupérer une valeur à partir de la source de données « thème ».
  5. La valeur du chemin de clé « Status.Icons.Cancelled » est « resource://Sprites/sprite_cancelled ».
  6. La détection automatique détermine qu’elle doit récupérer l’icône via une ressource située dans « Resources/Sprites/sprite_cancelled »

Feuilles de style TextMeshPro

Les thèmes peuvent activer les feuilles de style TMPro. « Paramètres TMP » ScriptableObject détermine où les feuilles de style sont censées se trouver dans les ressources. Il s’agit de la propriété « Default Font Asset => Path ».

Veillez à placer les feuilles de style spécifiques à l’application dans le même sous-chemin hors ressources. Si vous souhaitez les organiser différemment, veillez à mettre à jour les « paramètres TMP » pour qu’ils correspondent.

Rendre les nouveaux contrôles d’expérience utilisateur thémables

Si vous développez de nouveaux contrôles d’expérience utilisateur, il est relativement facile de les rendre à thème. Dans la mesure où le contrôle utilise des matériaux, des sprites et d’autres ressources déjà utilisées par d’autres contrôles d’expérience utilisateur, il s’agit généralement de nommer les différents objets du jeu de manière détectable.

Il est possible d’hériter de et d’ajouter MRTK_UXCore_ThemeProfile d’autres champs à thème, ou de pointer vos contrôles vers votre propre ScriptableObject. Il n’y a rien de magique dans ceux qui sont fournis ; les organization de ScriptableObject déterminent les chemins de clés nécessaires pour accéder à des éléments de données individuels via la réflexion C#.

En ajoutant un script BindingConfigurator.cs au niveau supérieur du nouveau contrôle, vous pouvez ensuite spécifier votre propre bindingProfile ScriptableObject sérialisé. Cela fournit le nom GameObject nécessaire aux mappages KeyPath nécessaires pour associer vos éléments à thème aux données fournies dans le profil de thème. Ce script ajoute automatiquement les composants DataConsumerXXX nécessaires au moment de l’exécution pour prendre en charge les thèmes que vous souhaitez utiliser.

Prise en main

Configuration requise

  • Unity 2020.3 LTS ou version ultérieure
  • TextMeshPro 2.1.4 ou version ultérieure

Exemples de scènes

Pour une première étape, examinez de près les différents exemples de scènes de liaison de données dans le package d’exemples MRTK et examinez la façon dont les différentes sources de données MonoBehaviours sont configurées. En règle générale, les scripts de liaison de données doivent uniquement être placés sur le GameObject de niveau le plus élevé d’un préfabriqué ou d’un ensemble d’éléments d’expérience utilisateur associé.

En outre, pour la plupart des cas d’usage, les valeurs par défaut fonctionnent « prêtes à l’emploi », mais les propriétés exposées offrent une flexibilité pour les cas plus avancés.

Remarque

Pour activer les thèmes pour les composants d’expérience utilisateur MRTK standard, le MRTK_UX_DATABINDING_THEMING_ENABLED symbole doit être défini dans paramètres du lecteur. Ce symbole garantit un impact nul sur les performances lorsque le thème n’est pas nécessaire.

Assets/DataBinding Example/Scenes/DataBindingExamples.scene

Cette scène qui illustre différents scénarios de données variables. Chargez la scène et jouez. Voici quelques points à noter :

  • Le champ Entrée de texte des composants TextMeshPro contient des variables qui ressemblent à ceci : {{ firstName }}. Ces marqueurs sont utilisés directement comme chemins de clés locaux.

  • Les objets de jeu pour les sprites et le texte ont une forme de composant Consommateur de données qui gère la réception des données et la mise à jour des vues.

  • Un seul consommateur de données peut être partagé par plusieurs composants du même type en étant placé plus haut dans la hiérarchie GO.

  • Un consommateur de données peut trouver sa propre source de données tant qu’elle se trouve sur le même objet de jeu ou plus dans la hiérarchie GO.

  • Un objet de jeu parent a un composant Source de données qui fournit des données pour tous les objets de jeu enfants qui présentent un ensemble connexe d’informations de variable.

  • Un consommateur de données de collection spécifie un préfabriqué, qui contient lui-même des consommateurs de données utilisés pour remplir ce préfabriqué avec des données variables.

Assets/UX Theming Example/Scenes/AudioTheming

Cet exemple utilise des thèmes pour basculer les audioclips entre un jeu pour Piano et un pour Xylophone.

Assets/UX Theming Example/Scenes/BatteryLevelExample

Cet exemple combine des thèmes et une liaison de données pour afficher un niveau de batterie à la fois sous forme de valeur numérique et d’icône. Le thème est utilisé pour choisir entre un thème « les charger » et un thème « ne pas charger ». Il est conçu pour répondre aux objectifs suivants :

  • Toutes les ressources visuelles peuvent exister dans un seul et même ScriptableObject profil de thème.
  • Le nombre de sprites pour les états de « facturation » peut différer du nombre pour l’état « ne charge pas ».
  • L’algorithme de mappage du niveau de batterie signalé à un sprite particulier peut être non linéaire et différer entre les états de « charge » et « pas de charge ».
  • Toutes les ressources visuelles peuvent exister dans un seul et même ScriptableObject profil de thème.
  • Le nombre de sprites pour les états de facturation peut différer du nombre pour l’état de non-facturation.
  • Algorithme de mappage du niveau de batterie signalé auquel le sprite peut être non linéaire et différer entre les états de charge et de non-chargement.

Remarque

La structure de cette démonstration n’est pas un bon exemple de combinaison de thèmes et de liaison de données. Dans une application de production pour une séparation appropriée du modèle et de la vue, l’état réel de la batterie (niveau et charge) est fourni dans une source de données distincte par rapport aux localisateurs de ressources pour les sprites eux-mêmes.

Assets/UX Theming Example/Scenes/UXThemingExample

Cet exemple illustre la modification du thème d’une application entière et montre également l’utilisation d’un DataSourceGODictionary comme source de données pour la gestion d’une variété de contenu textuel à afficher dans l’expérience utilisateur. Dans un scénario plus complet, les autres types de sources de données plus flexibles sont susceptibles de fournir la flexibilité nécessaire, comme DataSourceReflection ou DataSourceGOJson.

Premier projet de liaison de données

Voici un exemple simple pour vous aider à démarrer rapidement :

  1. Créez une scène.
  2. Dans le menu Mixed Reality Kit de ressources, sélectionnez l’option Ajouter à la scène et configurer.
  3. Créez un objet de jeu vide et renommez-le « Liaison de données ». Ajoutez un composant DataSourceJsonTest.
  4. Dans l’inspecteur, remplacez l’URL par un site web fournissant une recherche de données.
  5. Ajoutez un objet UI -> Text - TextMeshPro à l’objet de jeu Data Binding. Il ajoute un canevas, puis un objet « Text (TMP) ».
  6. Sélectionnez l’objet Text (TMP) et, dans l’inspecteur, remplacez l’entrée de texte par :

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

  1. Sélectionnez l’objet Canvas et ajoutez-y un composant Texte consommateur de données.
  2. Exécutez le projet. Toutes les 15 secondes, une activité différente est affichée.

Félicitations. Vous avez créé votre premier projet de liaison de données avec MRTK !

Écriture d’une nouvelle source de données

Une source de données fournit des données à un ou plusieurs consommateurs de données. Ses données peuvent être n’importe quoi : générées de manière algorithmique, en RAM, sur disque ou extraites d’une base de données centrale.

Toutes les sources de données doivent fournir l’interface IDataSource. Certaines des fonctionnalités de base sont proposées dans une classe de base appelée DataSourceBase. Vous souhaitez probablement dériver de cette classe pour ajouter la fonctionnalité de gestion des données spécifique à vos besoins.

Pour permettre de supprimer une source de données en tant que composant sur un objet de jeu, un autre objet de base existe, où DataSourceGOBase GO signifie GameObject. Il s’agit d’un MonoBehavior qui peut être déposé sur un GameObject en tant que composant. Il s’agit d’un proxy léger conçu pour déléguer le travail à une source de données de base non-Unity spécifique.

Une source de données peut exposer la possibilité de manipuler des données dans l’éditeur Unity. Si c’est le cas, la classe dérivée peut contenir la logique de la source de données ou utiliser une source de données « stock », mais également ajouter des champs Inspector ou d’autres moyens de configuration des données.

Écriture d’un nouveau consommateur de données

Un consommateur de données reçoit des notifications lorsque les données changent, puis met à jour un aspect de l’expérience utilisateur, tel que le texte affiché dans un composant TextMeshPro.

Tous les consommateurs de données doivent fournir l’interface IDataConsumer. Certaines des fonctionnalités de base sont proposées dans une classe de base appelée DataConsumerGOBase, où GO signifie GameObject.

La plupart du temps, le travail d’un consommateur de données consiste à accepter de nouvelles données, puis à les préparer pour la présentation. Cela peut être aussi simple que de sélectionner le préfabriqué approprié, ou cela peut signifier extraire plus de données à partir d’un service cloud tel qu’un système de gestion de contenu.

Écriture d’un placer d’élément de collecte de données

Un placer d’élément de collecte de données est responsable de la gestion des parties d’une collection qui sont actuellement visibles et de la façon de présenter cette collection visible, qu’il s’agisse d’une petite liste statique ou d’une base de données d’enregistrements d’un million géant.

Tous les placers d’éléments doivent fournir l’interface IDataCollectionItemPlacer. Certaines des fonctionnalités de base sont proposées dans une classe de base appelée DataColletionItemPlacerGOBase. Tous les placers d’élément doivent dériver de cette classe.

Limitations connues et fonctionnalités manquantes

  • Pas encore intégré aux contrôles canvas d’Unity et aux listes de défilement.
  • L’intégration de .NET INotifyPropertyChanged n’est pas encore implémentée.
  • Exemple de scène qui extrait des images à partir de Flickr et trymrtk.com ne fonctionne pas sur HoloLens en raison d’un bogue SSL HTTPS dans les versions ultérieures d’Unity.
  • Réglage supplémentaire des performances.
  • Cette version se concentre sur la présentation des données, et non sur la capture de données. Les contrôles d’expérience utilisateur MRTK ne sont pas encore câblés pour définir l’état dans un DataSource.
  • Les modifications dynamiques apportées aux données de liste actualisent complètement la liste entière au lieu d’une mise à jour incrémentielle.
  • Pipeline de manipulation de données non implémenté
  • Le remplissage de tous les composants d’expérience utilisateur sur une ardoise n’est pas encore entièrement pris en charge.
  • Les nœuds DataSourceJson doivent implémenter IDataNode l’interface pour être interopérable avec DataSourceObjects.
  • Last updated on