Data binding e framework di tema - MRTK3

Benvenuti nel framework di data binding e liing MRTK3. Questo framework è progettato per semplificare la creazione di elementi visivi che possono essere popolati e aggiornati dinamicamente in fase di esecuzione dai dati forniti da una o più origini dati.

Che cos'è il data binding

Il data binding è il processo che stabilisce una connessione tra l'esperienza utente (vista) di un'applicazione e i dati presentati (modello). Si supponga che l'associazione abbia le impostazioni corrette e che i dati forniscano le notifiche appropriate; quando i dati modificano il valore, gli elementi associati ai dati riflettono automaticamente le modifiche.

Framework di data binding più diffusi:

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

diagramma a blocchi di data binding di Presentation Framework Windows

Databinding Windows Presentation Framework (WPF) Per altre informazioni, vedere Panoramica del data binding - WPF.NET


Diagramma a blocchi equivalente di MRTK

MRTK equivalent block diagram


Obiettivi di progettazione

  • Distribuzione multipiattaforma ovunque
  • Supportare qualsiasi struttura organizzativa e origine delle origini dati
  • Facile integrazione in codebase esistenti o greenfield
  • Designer e developer friendly
  • Può essere abilitato/disabilitato in qualsiasi momento durante il ciclo di vita dell'applicazione
  • Supportare scenari reali, aziendali, database back-end, modelli di prefab dell'esperienza utente complessi
  • Facile da applicare ai componenti dell'esperienza utente non MRTK esistenti e ai nuovi elementi visivi
  • Associare qualsiasi tipo di dati, inclusi sprite, immagini, materiali, animazioni e clip audio
  • È facile migliorare le funzionalità senza toccare la codebase esistente
  • Uso efficiente di CPU, RAM, GC e frame-time
  • Eseguire facilmente l'integrazione con un'ampia gamma di origini dati locali o back-end
  • Qualsiasi combinazione simultanea di origini dati incorporate, in fase di esecuzione e back-end
  • Gestire in modo efficiente le raccolte di qualsiasi dimensione per la presentazione elenco
  • Associazione di tema e data binding per elementi dati dinamici che possono essere usati
  • Convalidare e modificare i dati delle variabili in modo aperto prima di presentare
  • Dipendenze minime da altre funzionalità di MRTK
  • Compatibile con MRTK v2 e MRTK3
  • Etichetta bianca e/o applicare personalizzazione alle risorse azionarie con un minimo sforzo

Funzionalità principali

  • Le origini dati aperte supportano qualsiasi strategia di dati persistente, remota o RAM.
  • I consumer di dati aperti supportano qualsiasi associazione dell'esperienza utente e esigenze di tema.
  • L'individuazione automatica tra origini dati e consumer semplifica l'hookup.
  • Configurazione automatica facoltativa da un profilo di associazione
  • Il modello di dati e la visualizzazione separati supportano modelli MVC e MVVM.
  • Raccolte virtualizzate con navigazione tramite paging e scorrimento.
  • Prelettura predittiva degli elementi della raccolta per lo spostamento senza problemi nell'elenco.
  • Gli oggetti raccolta possono essere inseriti in pool e riutilizzati per ridurre il GC.
  • È possibile eseguire il mapping tra le differenze nei dati e visualizzare gli spazi dei nomi keypath.

Funzionalità correnti

1. Visualizzare i dati delle variabili tramite consumer di dati

Attualmente supportato:

  • TestoMeshPro e TextMesh
  • Fogli di stile testo (per tema e accessibilità)
  • Trama sprite
  • Trigger booleano
  • Trama quad
  • Icone dei tipi di carattere
  • Raccolte: elenchi di dimensioni arbitrarie contenenti prefab popolati con dati variabili
  • Qualsiasi altro consumer che supporta l'interfaccia IDataConsumer (direttamente o tramite le classi di base)

2. Fornire dati variabili usando un'ampia gamma di origini dati:

  • Testo JSON (direttamente o tramite recupero URL)
  • Dizionario di elementi dati variabili
  • Oggetto - Dati strutturati basati su nodi
  • Reflection di qualsiasi oggetto C#
  • Dati modificati a livello di codice
  • Qualsiasi altro metodo che supporta l'interfaccia IDataSource

3. Segnaposto elemento elenco per gestire la manifestazione visiva di un elenco

4. Elencare il paging, lo scorrimento e la virtualizzazione

  • I dati vengono recuperati solo quando visibili o in corso
  • Supporta set di dati back-end arbitrariamente di grandi dimensioni
  • Il recupero è bilanciato dal carico tra più fotogrammi

5. Elencare il pooling di prefab

  • I prefab vengono riutilizzati e ripopolati per ridurre il tempo di GC e creazione di istanze.

6. Applicare i temi in modo dinamico agli elementi in fase di esecuzione


Funzionalità sulla roadmap

Oltre a ciò che è già disponibile, le priorità principali per altre funzionalità includono:

1. Pipeline del manipolatore di dati

  • Conversione tra valori lato dati e lato visualizzazione
  • Localizzazione (facile integrazione con localizzazione di Unity)
  • Formattazione
  • Convalida

2. Prelettura della voce di elenco predittiva per lo scorrimento/paging più veloce/uniforme

3. Più consumer di dati

  • Impostare qualsiasi proprietà pubblica su un componente
  • Impostare lo stato di disattivazione/disattivazione della casella di controllo
  • Impostare il valore del dispositivo di scorrimento
  • Impostare un pulsante di opzione in un gruppo
  • Proprietà dei singoli materiali, ad esempio il colore impostato

4. Tema

  • Visualizzare i temi applicati nell'editor anche quando non è in esecuzione l'applicazione
  • Aggiornare i prefab per riflettere un tema applicato in modo che diventi il tema predefinito
  • Ereditarietà del tema/stile

Terminologia

  • Origine dati : qualsiasi provider di dati, che si tratti di stato di runtime, persistente in locale o recuperato da un server.
  • Provider origine dati : un semplice MonoBehaviour che fornisce l'accesso a un'origine dati che potrebbe non essere esposta nel grafico della scena unity.
  • Tipo origine dati : nome univoco assegnato all'origine dati in modo che i consumer di dati possano specificare le origini dati desiderate in base al nome.
  • Consumer di dati: qualsiasi consumer di dati che desidera intervenire sulle modifiche dei dati, in genere un elemento visivo, ma non richiesto. Ad esempio, lo scopo può essere l'attivazione di azioni in base alle modifiche apportate al valore dei dati.
  • Titolare del trattamento dei dati : meccanismo per richiamare un'azione con il valore attualmente associato a dati fornito come parametro.
  • Keypath : selettore di dati che fa riferimento a un oggetto specifico in un'origine dati. Come attualmente implementato, il formato keypath viene modellato dopo le funzioni di accesso ai dati JSON per decifrare qualsiasi combinazione annidata di mappe, elenchi e elementi atomici.
  • Keypath locale: un keypath lato consumer di dati che può essere incorporato in modo permanente in un prefab riutilizzabile. Tramite la risoluzione delle entità di raccolta e dei mapping keypath, questo verrà convertito automaticamente in un keypath completamente risolto per un elemento specifico in una raccolta. Quando non è associato a una raccolta, questi possono eseguire il mapping direttamente a un dato nell'origine dati o possono essere prima modificati tramite un Mapper Keypath.
  • Keypath completamente risolto: un keypath completo e assoluto che esegue il mapping a un oggetto specifico in un'origine dati. Per gli elementi in una raccolta, si tratta di una combinazione del keypath completamente risolto per un'entità raccolta e un keypath relativo (locale) per un elemento dati di tale entità di raccolta.

  • Keypath Mapper - Mapper facoltativo dello spazio dei nomi tra keypath locali e nomi di campo origine dati (ad esempio "link" <-> "URL").

  • Tema : origine dati che fornisce un set di vari asset e stili necessari per ottenere un'estetica visiva specifica.

  • Elemento Placer - Un compagno DataConsumerCollection responsabile dell'inserimento di elementi visibili in una scena.

  • Pool di oggetti dati : prefab di standby pronti per popolare con i dati per la navigazione elenco a basso numero di istanze.

  • Virtualizzazione elenco : possibilità di popolare, presentare e esplorare elenchi di dimensioni arbitrarie di grandi dimensioni.

  • Prefetch predittivo : pre-recupero dei dati e popolamento dei prefab di raccolta per gli elementi che potrebbero essere presto visualizzati tramite lo scorrimento/paging.

  • Prefetch predittivo : pre-recupero dei dati e popolamento dei prefab di raccolta per gli elementi che potrebbero essere presto visualizzati tramite scorrimento/paging.

Concetti chiave

origine dati

Un'origine dati è qualsiasi set gestito di dati di tipi arbitrari e complessità che possono essere usati per popolare le viste dati tramite consumer di dati. I dati gestiti da un'origine dati possono essere statici o dinamici. Le modifiche apportate agli elementi dati verranno segnalate a tutti i consumer di dati registrati per ricevere notifiche di modifica.

Provider di origine dati

Interfaccia semplice con un singolo metodo per recuperare un'origine dati. Questo è progettato per consentire a un componente di scripting MonoBehavior di essere individuato automaticamente nella gerarchia degli oggetti del gioco dai componenti del consumer dei dati. Non è necessario implementare un'origine dati direttamente sull'oggetto gioco stesso. Ciò è utile quando un MonoBehaviour esistente deve derivare da un'altra classe e più ereditarietà impedisce la derivazione da DataSourceGOBase. Consente anche a più codice di non avere dipendenze unity.

Singleton del provider di origine dati

MonoBehaviour DataSourceProviderSingleton consente di specificare un'origine dati che può essere individuata automaticamente anche se non si trova nella stessa gerarchia di GameObject dei DataConsumers che desiderano ascoltarla. È sufficiente inserire la proprietà ovunque nella scena e popolare la DataSourceProviderSingletonData Sources proprietà con le origini dati che devono essere individuate dai consumer di dati. In alternativa, i consumer di dati illustreranno i loro genitori per trovare un'origine dati appropriata, che implica che sia possibile inserire un'origine dati che fornisce i dati desiderati ovunque nella catena padre di tali consumer di dati.

Percorso chiave (stringa)

Un percorso chiave è il meccanismo per identificare in modo univoco qualsiasi elemento di informazioni in un'origine dati.

Anche se un percorso chiave può essere qualsiasi identificatore univoco per elemento di dati, le implementazioni correnti usano un identificatore leggibile utente logico che indica la posizione di spostamento dei dati di interesse rispetto all'intero set di dati strutturato. È modellato sul concetto di elenchi, dizionari e primitive di Javascript. I percorsi chiave sono istruzioni Javascript corrette sintatticamente corrette per l'accesso ai dati che possono essere rappresentati in JSON. Il vantaggio di questo approccio è che correla bene con JSON e XML. Questi sono i due mezzi più diffusi per trasferire informazioni dai servizi back-end.

Percorsi chiave di esempio:

  • temperatura
  • contatti[10].firstName
  • contatti
  • contatti[10].indirizzi[3].city
  • [10].titolo
  • kingdom.animal.mammal.aardvark.diet.foodtypes.termites

Dato che un percorso chiave è una stringa arbitraria senza tassonomia necessaria, gli identificatori di dati effettivi potrebbero essere qualsiasi metodo di descrizione dei dati da recuperare. XPath di XML è un esempio di uno schema di percorso chiave valida che funzionerebbe con le origini dati. Purché i percorsi chiave forniti dal consumer di dati siano coerenti con i keypath previsti dall'origine dati, tutto funzionerà. È inoltre possibile implementare i mapping dei percorsi chiave per tradurre tra schemi diversi.

Risoluzione di un percorso chiave

La risoluzione di un percorso chiave significa combinare due percorsi chiave:

  1. Keypath assoluto che descrive come accedere a un subset specifico di un set di dati più grande, ad esempio una voce in un elenco di molte voci.
  2. Keypath parziale (relativo) che rappresenta una specifica datum all'interno di tale elenco o voce mappa.

Ciò rende possibile trattare un sottoinsieme dei dati in modo da non importare dove in una gerarchia di set di dati più grande esiste effettivamente. L'uso più critico di questa capacità consiste nel descrivere i dati di una singola voce in un elenco senza preoccuparsi della voce in tale elenco che fa riferimento all'istanza corrente.

Poiché un percorso chiave "completamente risolto" viene sempre generato e utilizzato da un'origine dati e deve essere raramente modificato da un dataconsumer o da un altro componente esterno, può avere qualsiasi struttura che abbia senso per l'origine dati. Ad esempio, se è presente un prefab per visualizzare una voce di elenco per una foto e il relativo titolo, data e altri attributi, il percorso della chiave locale nel prefab potrebbe essere simile al seguente:

  • "photo_url"
  • "titolo"
  • "date_taken"
  • "descrizione"

I percorsi chiave completamente risolti per una voce prefab in un elenco potrebbero essere simili al seguente:

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

Percorso chiave Mapper (IDataKeyPathMapper)

Un mapper percorso chiave consente ai consumer di dati e origini dati di usare spazi dei nomi e convenzioni diversi per i percorsi chiave e ancora lavorare insieme.

Un prefab per un elemento comunemente usato, ad esempio uno slate per visualizzare le informazioni di contatto di una persona, può contenere campi variabili gestiti dai consumer di dati. Per rendere possibile questo, l'identificatore usato per qualsiasi aspetto variabile del prefab deve essere eseguito il mapping all'identificatore per il datum corretto nell'origine dati che, in ogni uso del prefab, determina il contenuto di tale elemento variabile. Il mapper percorso chiave rende possibile questa operazione.

Il prefab può essere usato con origini dati diverse in cui i dati vengono archiviati in una struttura organizzativa diversa e usano nomi di campo. Per usare un prefab modello con ogni origine dati, un mapper percorso chiave può risolvere eventuali differenze nel modo in cui i dati sono organizzati.

Consumer dei dati (IDataConsumer)

Oggetto che sa usare le informazioni gestite da un'origine dati e usare tali dati per popolare le visualizzazioni dei dati.

I consumer di dati possono registrarsi con un'origine dati per ricevere una notifica delle modifiche apportate a un elemento di dati presente in un percorso chiave specificato in un set di dati. Ogni volta che i dati specificati sono stati modificati (o sono sospetti di essere stati modificati), i consumer di dati verranno notificati.

Raccolta consumer di dati

Una raccolta consumer di dati ha la possibilità di gestire un elenco di elementi simili. Questo elenco può essere l'intero set di dati gestito da un'origine dati o solo un subset. In genere i dati per ogni elemento nell'elenco contengono tipi simili di informazioni, ma non è un requisito. Le origini dati e i consumer di dati possono supportare elenchi annidati, ad esempio un elenco di parole chiave associate a ogni foto in un elenco di foto associate a ogni persona in un elenco di contatti. Il keypath per le parole chiave sarebbe relativo alla foto e il keypath per le foto sarebbe relativo alla persona e il keypath della persona sarebbe relativo all'elenco padre più vicino o alla radice del set di dati.

Durante l'elaborazione delle raccolte, il keypath risolto corretto per la voce specifica nella raccolta viene assegnato a ogni consumer di dati trovato nel prefab creato per ogni elemento di raccolta. Viene quindi usato per risolvere completamente il percorso della chiave per i dati relativi (locali) di visualizzazione all'interno di tale prefab.

Segnaposto elemento raccolta dati

Un consumer di dati di raccolta necessita di un mezzo per popolare le esperienze utente con elenchi di elementi visivi ripetuti, ad esempio ciò che potrebbe essere trovato in un elenco scorrevole di prodotti, foto o contatti. Questa operazione viene eseguita assegnando un segnaposto dell'elemento al consumer dei dati di raccolta. Questo segnaposto dell'elemento è la logica che sa come richiedere elementi di elenco, accettare prefab popolati con dati variabili e quindi presentarli all'utente, in genere inserendoli in un elenco gestito da un componente di layout dell'esperienza utente per gli elenchi.

Temi

Il liing usa tutti gli impianti idraulici delle origini dati e dei consumer di dati. È possibile tema di qualsiasi gerarchia di GameObjects se sono statici o sono associati dinamicamente a altre origini dati. Ciò consente l'applicazione di data binding e di liing in combinazione. È anche possibile temare i dati provenienti da un'altra origine dati.

Diagramma a blocchi e flusso di dati

MRTK theming data flow

Li loroing MRTK

Il tema è la capacità di modificare l'estetica visiva di molti elementi dell'esperienza utente in una sola volta. In genere, tutti i dati necessari per specificare un tema vengono forniti da un'unica origine dati, ad esempio un oggetto scriptable. È anche possibile specificare i dati in base alle esigenze o suddivisi in gruppi logici in base allo scopo.

MRTK3 Theming

MrTK3 liing combinato con Data Binding

Data Binding e Liing possono coesistere per un singolo elemento dell'esperienza utente. Qualsiasi singolo elemento dell'esperienza utente può essere associato simultaneamente e associato ai dati. In questo scenario, il flusso tipico è che il dato proveniente da un'origine dati viene usato per derivare il keypath del tema corretto. Questo percorso chiave viene quindi usato per recuperare un oggetto dall'origine dati del tema, in genere un profilo ScriptableObject, ma potenzialmente qualsiasi origine di dati in grado di risolvere un percorso chiave.

Per semplificare la configurazione del tema e del data binding, è possibile creare profili di associazione elaborati da un bindingConfiguratore in fase di creazione di istanze.

  • Un BindingConfigurator oggetto elabora un profilo di associazione per determinare gli asset all'interno di un prefab che devono essere temati e associa sia gli elementi dati associati che gli elementi disponibili a Keypath. Aggiunge quindi l'oggetto appropriato DataConsumers per associare questi elementi visivi ai selettori Keypath corretti che verranno usati per fare riferimento a dati specifici in uno o più DataSources, che in genere sono esterni al prefab stesso.
  • I dati del tema vengono forniti da un DataSource oggetto che contiene dati per ogni percorso chiave identificato nel profilo di associazione.
  • Uno ThemeProvider script helper semplifica l'uso di scriptableObject come oggetto DataSource per il tema.
  • Il tema dell'esperienza MRTK_UX_ThemeProfile utente standard viene fornito da ScriptableObject associato a in DataSourceReflectionThemeProvider.

Theme Profile DataSource flow diagram

Origine dati incorporata

Un'origine dati incorporata è appropriata in due situazioni:

  1. Quando ogni istanza del prefab può avere impostazioni del tema diverse e richiede una propria origine dati separata.
  2. Quando tutte le istanze di questo prefab sono regolate da un profilo di tema persistente comune (ad esempio, ScriptableObject) e possono essere fornite tramite l'origine dati incorporata in modo che non vi siano dipendenze esterne da stabilire.

DataSourceReflection

In questo modo è possibile trasformare qualsiasi struct o classe C# in un DataSource oggetto usando la reflection per eseguire il mapping di percorsi chiave a campi, proprietà, classi nidificate, matrici, elenchi o dizionari. Può essere associato a un oggetto Unity ScriptableObject o a qualsiasi altro struct o classe C# in cui esistono dati del tema. L'oggetto di cui è stata creata un'istanza contenente i dati può essere inserito e modificato in fase di esecuzione.

  1. Oggetto scriptable: utile per i temi statici condivisi tra molti prefab.
  2. Struct o classe C# non persistenti: utile per le modifiche dinamiche in fase di esecuzione del tema.

DataSourceJson

Se i dati sono presenti come json testo, questo gestisce il mapping dei percorsi chiave al json DOM. Gli asset binari possono essere recuperati dalle risorse di Unity, da StreamingAssets o anche da un URL recuperato.

DataSourceDictionary

Questa è un'opzione semplice quando un elenco puramente semplice è sufficiente per soddisfare le esigenze e per la creazione rapida di prototipi. Tutti gli asset di tema sono supportati, tra cui testo, asset Unity (ad esempio, Materiali, Sprite e Immagini), Risorse, StreamingAssets o addirittura recuperabili esternamente tramite un URL.

Personalizzato

Qualsiasi origine dati personalizzata che implementa l'interfaccia semplice IDataSource o deriva da DataSourceBase o DataSourceGOBase può essere usata per soddisfare esigenze personalizzate.

Tema UXComponents

I controlli UXComponents standard forniti nel pacchetto UXComponents sono tutti configurati per supportare il tema. È disattivata per impostazione predefinita, ma è facile da abilitare.

Ogni controllo, in genere nel gameobject più alto del prefab radice, ha uno script denominato UXBindingConfigurator. Questo script, se abilitato, eseguirà il pull degli script di data binding necessari per attivare il tema. Assicurarsi di importare anche il pacchetto Data Binding e Theming.

Nota su TextMeshPro StyleSheets: non è attualmente possibile utilizzare StyleSheets per applicare lo stile TextMeshPro Normal . È possibile usare qualsiasi altro stile incluso nel foglio di stile predefinito di TextMeshPro. Gli esempi usano Body per aggirare questa limitazione.

DataSourceThemeProvider

MonoBehaviour DataSourceThemeProvider può essere usato per rendere facilmente scriptableObject contenente tutti i riferimenti a tutte le risorse di tema funzione come origine dati. Questo è illustrato nella scena UXThemingExample.

ThemeSelector

ThemeSelector MonoBehaviour consente di specificare e scambiare facilmente tra più profili ScriptableObject. Un esempio di questo tipo potrebbe essere quello di semplificare il passaggio tra un tema "Scuro" e un tema "Chiaro". Aggiungere ScriptableObjects a Theme Profiles, in genere in fase di progettazione. Quindi, in fase di esecuzione, modificare la Current Theme proprietà per modificare il tema.

Tema consumer di dati

Il tema viene eseguito dai consumer di dati, in particolare da quelli che ereditano da DataConsumerThemeBase<T>, DataConsumerTextStyle e classi DataConsumer personalizzate che qualsiasi sviluppatore può implementare per migliorare il supporto del tema.

La classe di base DataConsumerThemeBase<T> fornisce la logica per usare un valore intero o un datum chiave da un'origine dati primaria per cercare il valore finale desiderato da un database del tema secondario. Questa operazione viene eseguita eseguendo il mapping dei dati di input a un keypath del tema e quindi usando tale keypath del tema per recuperare il valore finale. Ciò consente a qualsiasi elemento di essere sia associato a dati che a tema contemporaneamente. Si supponga, ad esempio, che un campo di stato in un database contenga gli stati New, Started e Done rappresentati da valori 0, 1 e 2. Ognuno di questi può essere rappresentato da un'icona Sprite. Per il data binding, viene usato un valore compreso tra 0 e 2 per cercare lo sprite desiderato. Con il tema e il data binding, il profilo del tema punta all'elenco corretto di tre sprite nel profilo del tema e quindi viene usato il valore compreso tra 0 e 2 per selezionare lo sprite corretto da tale elenco. In questo modo, lo stile di queste icone può essere diverso per ogni tema.

Quando vengono usati insieme sia il tema di runtime che il data binding dinamico, è possibile specificare una classe DataConsumerThemeHelper in qualsiasi classe derivata da DataConsumerThemeBase per notificare quando un tema è stato modificato.

Lo scambio dei temi in fase di esecuzione viene eseguito sostituendo i dati nell'origine dati del tema con un nuovo set di dati disposto nella stessa topologia del modello a oggetti dati. DataSourceReflection può essere usato con ScriptableObjects in cui ogni profilo rappresenta un tema. Per tutti i controlli UX di MRTK Core, il profilo del tema è un oggetto ScriptableObject denominato MRTK_UXComponents_ThemeProfile. Lo script helper ThemeProvider.cs semplifica l'uso di questo profilo o di qualsiasi profilo ScriptableObject come origine dati.

Il metodo di applicazione di un tema ai dati dinamici può essere rilevato automaticamente nella maggior parte dei casi oppure può essere specificato in modo esplicito.

Quando il datum viene usato per selezionare l'elemento corretto dall'origine dati del tema, il processo è:

  • un datum dall'origine dati primaria viene usato per selezionare o costruire il keypath del tema corretto
  • il percorso chiave del tema viene usato per recuperare un valore dall'origine dati del tema specificata in DataConsumerThemeHelper
  • il valore del tema recuperato viene analizzato per rilevare automaticamente il metodo di recupero corretto
  • L'elemento dati finale di tipo corretto (ad esempio, Material, Sprite o Image) viene quindi recuperato usando il metodo rilevato automaticamente.

Tipi di dati

Il tipo di dati previsto del datum utilizzato per recuperare l'oggetto desiderato può essere uno dei seguenti:

Tipo di dati Descrizione
Autodetect Il datum viene analizzato e viene rilevata automaticamente l'interpretazione corretta. Per altre informazioni, vedere "Rilevamento automatico del tipo di dati" di seguito.
DirectValue Il datum deve essere di tipo T desiderato (ad esempio, Material, Sprite, Image) e usato direttamente.
DirectLookup Indice integrale o chiave stringa utilizzata per cercare il valore desiderato da una tabella di ricerca locale.
StaticThemedValue L'oggetto a tema statico del tipo corretto viene recuperato dall'origine dati del tema in corrispondenza del percorso chiave del tema specificato.
ThemeKeypathLookup Viene usato un indice integrale o una chiave stringa per cercare il percorso chiave del tema desiderato.
ThemeKeypathProperty Nome della proprietà stringa che verrà aggiunto al percorso chiave di base del tema fornito nel tema.
ResourcePath Percorso della risorsa per il recupero del valore da una risorsa Unity (può iniziare con "resource://").
FilePath Un percorso di file per il recupero di un asset di streaming Unity (può iniziare con "file://").

Rilevamento automatico del tipo di dati

La correzione automatica analizza i dati ricevuti e decide automaticamente il metodo di recupero. Nella tabella seguente T rappresenta il tipo desiderato, ad esempio Material, Sprite, Image. La correzione automatica può verificarsi in due posizioni nel processo:

  • Sul valore del datum primario stesso.
  • Sul valore a tema recuperato tramite il datum primario.
Tipo di riferimento Considerazioni Ha l'helper del tema Comportamento
T n/d S/N Usato direttamente senza tema
INT qualsiasi primitiva integrale o stringa analizzabile Int32 No Passato come indice a GetObjectByIndex(n) derivato per recuperare l'oggetto Nth di tipo T.
INT qualsiasi primitiva integrale o stringa analizzabile Int32 Indice per recuperare Nth theme keypath dalla ricerca locale e quindi recuperare l'oggetto a tema tramite il rilevamento automatico.
string Formato: "resource://{resourcePath}" S/N resourcePath viene usato per recuperare la risorsa Unity
string Formato: "file://{filePath} S/N filePath viene usato per recuperare un asset di streaming
string Altro No Passato come chiave a GetObjectByKey() derivato per recuperare l'oggetto corrispondente di tipo T.
string Altro Chiave per recuperare il keypath del tema corrispondente dalla ricerca locale e quindi recuperare l'oggetto a tema tramite il rilevamento automatico.

Esempio di recupero di un'icona di stato a tema da un database contenente un valore di stato numerico:

  1. Il percorso chiave per un'icona di stato nel database è status.sprite_index.
  2. Il valore recuperato per status.sprite_index è 2, ovvero lo stato "annullato".
  3. La voce N=2 (in altre parole, terza) nella ricerca DataConsumerSprite è impostata su "Status.Icons.Cancelled".
  4. Questo è il percorso chiave usato per recuperare un valore dall'origine dati "theme".
  5. Il valore per il percorso chiave "Status.Icons.Cancelled" è "resource://Sprites/sprite_cancelled".
  6. Il rilevamento automatico determina che deve recuperare l'icona tramite una risorsa che si trova in "Resources/Sprites/sprite_cancelled"

TextMeshPro StyleSheets

Il tema è in grado di attivare fogli di stile TMPro. "TMP Impostazioni" ScriptableObject determina dove devono trovarsi i fogli di stile nelle risorse. Si tratta della proprietà "Default Font Asset => Path".

Assicurarsi di inserire tutti i fogli StyleSheet specifici dell'app nello stesso sottopercorso all'esterno di Risorse. Se si desidera organizzarli in modo diverso, assicurarsi di aggiornare "TMP Impostazioni" in modo che corrisponda.

Rendere disponibili nuovi controlli dell'esperienza utente

Se si sviluppano nuovi controlli dell'esperienza utente, è relativamente semplice renderli disponibili. Nella misura in cui il controllo usa Materiali, Sprite e altri asset già in uso da altri controlli dell'esperienza utente, in genere è una questione di denominazione dei vari oggetti gioco in modo individuabile.

È possibile ereditare da MRTK_UXCore_ThemeProfile e aggiungere altri campi disponibili oppure puntare i controlli al proprio ScriptableObject. Non c'è niente di magico di quelli forniti; l'organizzazione di ScriptableObject determinerà i percorsi chiave necessari per accedere ai singoli elementi di dati tramite reflection C#.

Aggiungendo uno script BindingConfigurator.cs al livello superiore del nuovo controllo, è quindi possibile specificare il proprio oggetto BindingProfile ScriptableObject serializzato. In questo modo verrà fornito il nome GameObject necessario ai mapping KeyPath necessari per associare gli elementi temibili ai dati forniti nel profilo del tema. Questo script aggiungerà automaticamente tutti i componenti DataConsumerXXX necessari in fase di esecuzione per supportare il tema da usare.

Guida introduttiva

Requisiti

  • Unity 2020.3 LTS o versioni successive
  • TextMeshPro 2.1.4 o versione successiva

Scene di esempio

Per un primo passaggio, esaminare in modo dettagliato le varie scene di esempio di data binding nel pacchetto MRTK Examples e osservare come vengono configurate le varie origini dati MonoBehaviours. In generale, gli script di data binding devono essere inseriti solo nel GameObject di livello più alto di un prefab o in un set correlato di elementi dell'esperienza utente.

Inoltre, per la maggior parte dei casi d'uso, i valori predefiniti funzionano come "predefiniti", ma le proprietà esposte offrono una notevole flessibilità per i casi più avanzati.

Nota

Per abilitare il tema per i componenti dell'esperienza utente MRTK standard, il MRTK_UX_DATABINDING_THEMING_ENABLED simbolo deve essere definito in Player Impostazioni. Questo simbolo garantisce un impatto sulle prestazioni pari a zero quando non è necessario un tema.

Esempio/DataBinding Assets/Scenes/DataBindingExamples.scene

Questa scena che illustra un'ampia gamma di scenari di dati variabili. È sufficiente caricare la scena e giocare. Alcune considerazioni:

  • Il campo Input di testo dei componenti TextMeshPro contiene variabili simili al seguente: {{ firstName }}. Questi marcatori vengono usati direttamente come percorsi chiave locali.

  • Gli oggetti gioco per sprite e testo hanno una forma di componente Consumer di dati che gestisce la ricezione di dati e l'aggiornamento delle visualizzazioni.

  • Un singolo consumer di dati può essere condiviso da più componenti dello stesso tipo posizionando più in alto nella gerarchia GO.

  • Un consumer di dati può trovare la propria origine dati purché si trovi nello stesso oggetto gioco o superiore nella gerarchia GO.

  • Un oggetto gioco padre dispone di un componente Origine dati che fornisce dati per tutti gli oggetti gioco figlio che presentano un set correlato di informazioni sulle variabili.

  • Un consumer di dati di raccolta specifica un prefab che contiene consumer di dati che verranno usati per popolare tale prefab con dati variabili.

Esempio di tema asset/esperienza utente/scene/audioTheming

In questo esempio viene usato il tema per cambiare audioClip tra un set per Piano e uno per Xylophone.

Esempio di tema asset/esperienza utente/scene/batteryLevelexample

Questo esempio combina il tema e il data binding per visualizzare un livello di batteria sia come valore numerico che come icona. I temi vengono usati per selezionare tra un tema "caricarli" e un tema "non carica". È progettato per soddisfare gli obiettivi seguenti:

  • Tutti gli asset visivi possono esistere in un singolo ScriptableObject profilo di tema.
  • Il numero di sprite per gli stati di "ricarica" può differire dal numero per lo stato "not charge".
  • L'algoritmo per il mapping del livello di batteria segnalato a uno sprite specifico può essere non lineare e differire tra gli stati di "ricarica" e "non carica".
  • Tutti gli asset visivi possono esistere in un singolo ScriptableObject profilo di tema.
  • Il numero di sprite per gli stati di ricarica può differire dal numero per non ricaricare lo stato.
  • L'algoritmo per il mapping del livello di batteria segnalato a cui lo sprite può essere non lineare e differisce tra gli stati di ricarica e non di ricarica.

Nota

La struttura di questa demo non è un buon esempio di combinazione di tema e data binding. In un'applicazione di produzione per una corretta separazione del modello e della visualizzazione, lo stato effettivo della batteria (livello e ricarica) verrebbe fornito in un'origine dati separata rispetto ai localizzatori di risorse per gli sprite stessi.

Esempio di tema asset/esperienza utente/scene/UXThemingExample

In questo esempio viene illustrato come modificare il tema di un'intera applicazione e viene illustrato anche l'uso di come DataSourceGODictionary origine dati per la gestione di un'ampia gamma di contenuti testuali da visualizzare nell'esperienza utente. In uno scenario più completo, è probabile che gli altri tipi di origini dati più flessibili forniscano la flessibilità necessaria, ad esempio DataSourceReflection o DataSourceGOJson.

Primo progetto di data binding

Ecco un semplice esempio per iniziare rapidamente:

  1. Creare una nuova scena.
  2. Nel menu Realtà mista Toolkit selezionare l'opzione Aggiungi alla scena e Configura.
  3. Creare un oggetto gioco vuoto e rinominarlo "Data Binding". Aggiungere un componente DataSourceJsonTest.
  4. Nel controllo modificare l'URL in: https://www.boredapi.com/api/activity
  5. Aggiungere un oggetto UI -> Text - TextMeshPro all'oggetto gioco Data Binding. Aggiungerà un'area di disegno e quindi un oggetto "Text (TMP)".
  6. Selezionare l'oggetto Text (TMP) e nel controllo modificare Input di testo in:

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

  1. Selezionare l'oggetto Canvas e aggiungervi un componente Testo consumer di dati.
  2. Eseguire il progetto. Ogni 15 secondi verrà visualizzata un'attività diversa.

Complimenti. È stato creato il primo progetto di data binding con MRTK.

Scrittura di una nuova origine dati

Un'origine dati fornisce dati a uno o più consumer di dati. I dati possono essere qualsiasi cosa: generata in modo algoritmico, in RAM, su disco o recuperata da un database centrale.

Tutte le origini dati devono fornire l'interfaccia IDataSource. Alcune delle funzionalità di base sono disponibili in una classe di base denominata DataSourceBase. È molto probabile che si voglia derivare da questa classe per aggiungere la funzionalità di gestione dei dati specifica specifica alle proprie esigenze.

Per rendere possibile eliminare un'origine dati come componente in un oggetto gioco, esiste un altro oggetto di base denominato DataSourceGOBase dove GO è l'acronimo di GameObject. Si tratta di un MonoBehavior che può essere rilasciato in un GameObject come componente. Si tratta di un thin proxy progettato per delegare il lavoro a un'origine dati core non specifica di Unity.

Un'origine dati può esporre la possibilità di modificare i dati nell'editor di Unity. In questo caso, la classe derivata può contenere tutta la logica dell'origine dati oppure può sfruttare un'origine dati "stock", ma anche aggiungere campi Inspector o altri mezzi per configurare i dati.

Scrittura di un nuovo consumer di dati

Un consumer di dati riceve notifiche quando i dati sono stati modificati e quindi aggiorna alcuni aspetti dell'esperienza utente, ad esempio il testo visualizzato in un componente TextMeshPro.

Tutti i consumer di dati devono fornire l'interfaccia IDataConsumer. Alcune delle funzionalità di base sono disponibili in una classe di base denominata DataConsumerGOBase, dove GO è l'acronimo di GameObject.

La maggior parte del lavoro di un consumer di dati consiste nell'accettare nuovi dati e quindi prepararli per la presentazione. Può trattarsi di un'operazione semplice come la selezione del prefab corretto oppure il recupero di più dati da un servizio cloud, ad esempio un sistema di gestione dei contenuti.

Scrittura di un segnaposto dell'elemento della raccolta dati

Un segnaposto dell'elemento della raccolta dati è responsabile della gestione delle parti di una raccolta attualmente visibili e di come presentare tale raccolta visibile, indipendentemente dal fatto che la raccolta sia un piccolo elenco statico o un database di record gigante.

Tutti i segnaposto degli elementi devono fornire l'interfaccia IDataCollectionItemPlacer. Alcune delle funzionalità di base sono disponibili in una classe di base denominata DataColletionItemPlacerGOBase. Tutti i segnaposto degli elementi devono derivare da questa classe.

Limitazioni note e funzionalità mancanti

  • Non ancora integrato con i controlli basati su Canvas di Unity e gli elenchi scorrevoli.
  • L'integrazione di .NET INotifyPropertyChanged non è ancora implementata.
  • Scena di esempio che recupera immagini da Flickr e trymrtk.com non funzionano su HoloLens a causa di un bug HTTPS SSL nelle versioni successive di Unity.
  • Ottimizzazione delle prestazioni aggiuntiva.
  • Questa versione è incentrata sulla presentazione dei dati, non sull'acquisizione dei dati. I controlli dell'esperienza utente MRTK non sono ancora cablati per impostare lo stato in un oggetto DataSource.
  • Le modifiche dinamiche ai dati dell'elenco aggiornano completamente l'intero elenco anziché l'aggiornamento incrementale.
  • La pipeline di manipolazione dei dati non è ancora stata implementata
  • Il popolamento di tutti i componenti dell'esperienza utente in uno slate non è ancora completamente supportato.
  • I nodi DataSourceJson devono implementare l'interfaccia IDataNode per essere interoperabili con DataSourceObjects.