Udostępnij za pośrednictwem

Powiązanie danych i struktura motywów — MRTK3

  • Artykuł

Witamy w strukturze powiązań i motywów danych MRTK3. Ta struktura została zaprojektowana tak, aby ułatwić tworzenie elementów wizualnych, które mogą być wypełniane i aktualizowane dynamicznie w czasie wykonywania przez dane dostarczane z co najmniej jednego źródła danych.

Co to jest powiązanie danych

Powiązanie danych to proces, który ustanawia połączenie między środowiskiem użytkownika aplikacji (widok) i prezentowanym danymi (modelem). Załóżmy, że powiązanie ma poprawne ustawienia, a dane zapewniają odpowiednie powiadomienia; gdy dane zmieniają swoją wartość, elementy powiązane z danymi odzwierciedlają zmiany automatycznie.

Popularne struktury powiązań danych:

  • Delphi
  • Windows Presentation Framework (WPF .NET)
  • Windows Forms
  • Angular
  • Backbond
  • Powiązania JavaFX

Diagram bloków powiązania danych programu Windows Presentation Framework

Powiązanie struktury prezentacji systemu Windows (WPF) Aby uzyskać więcej informacji, zobacz Omówienie powiązania danych — WPF.NET

Diagram bloków równoważnych zestawu narzędzi MRTK

Diagram bloków równoważnych zestawu narzędzi MRTK

Cele projektu

  • Międzyplatformowe — wdrażanie w dowolnym miejscu
  • Obsługa dowolnej struktury organizacyjnej i źródła źródeł danych
  • Łatwe integrowanie z istniejącymi lub zielonymi bazami kodu
  • Projektant i przyjazny dla deweloperów
  • Można włączyć/wyłączyć w dowolnym momencie podczas cyklu życia aplikacji
  • Obsługa rzeczywistych scenariuszy dla przedsiębiorstw — baz danych zaplecza, złożonych szablonów prefab środowiska użytkownika
  • Łatwe zastosowanie do istniejących składników UX innych niż MRTK i nowatorskich elementów wizualnych
  • Wiązanie dowolnego typu danych, w tym sprites, obrazów, materiałów, animacji i klipów audio
  • Łatwe rozszerzanie możliwości bez dotykania istniejącej bazy kodu
  • Wydajne wykorzystanie procesora CPU, pamięci RAM, pamięci GC i czasu ramki
  • Łatwo integruj się z różnymi lokalnymi lub zaplecza źródłami danych
  • Każda jednoczesna kombinacja osadzonych, stanu czasu wykonywania i źródeł danych zaplecza
  • Wydajna obsługa kolekcji o dowolnym rozmiarze na potrzeby prezentacji listy
  • Połączone motywy i powiązanie danych dla elementów danych dynamicznych z możliwością ich obsługi
  • Weryfikowanie i manipulowanie danymi zmiennych w sposób otwarty przed przedstawieniem
  • Minimalne zależności od innych funkcji zestawu narzędzi MRTK
  • Zgodność z zestawem MRTK w wersji 2 i mrTK3
  • Łatwa etykieta i/lub stosowanie znakowania do zasobów akcji przy minimalnym nakładzie pracy

Najważniejsze funkcje    

  • Źródła danych typu open-end obsługują każdą strategię utrwalania, zdalnego lub pamięci RAM.
  • Użytkownicy danych typu open-end obsługują wszelkie powiązania środowiska użytkownika i ich potrzeby.
  • Automatyczne odnajdywanie między źródłami danych a użytkownikami upraszcza łączenie.
  • Opcjonalna automatyczna konfiguracja z profilu powiązania
  • Oddzielony model danych i wyświetlanie obsługują wzorce MVC i MVVM.
  • Zwirtualizowane kolekcje z nawigacją za pośrednictwem stronicowania i przewijania.
  • Predykcyjne pobieranie elementów kolekcji na potrzeby płynnej nawigacji na liście.
  • Obiekty kolekcji można pulować i ponownie używać w celu zmniejszenia GC.
  • Może mapować różnice między danymi i wyświetlać przestrzenie nazw ścieżki kluczy.

Bieżąca funkcjonalność

1. Wizualizowanie danych zmiennych za pośrednictwem użytkowników danych

Obecnie obsługiwane:

  • Tekst TextMeshPro i TextMesh
  • Arkusze stylów tekstu (dla motywów i ułatwień dostępu)
  • Tekstura sprite
  • Wyzwalacz logiczny
  • Tekstura czworokąta
  • Ikony czcionek
  • Kolekcje: dowolne listy rozmiarów zawierające prefabryki wypełnione danymi zmiennych
  • Każdy inny użytkownik obsługujący interfejs IDataConsumer (bezpośrednio lub za pośrednictwem wyprowadzeń klas bazowych)

2. Podaj dane zmiennych przy użyciu różnych źródeł danych:

  • Tekst JSON (bezpośrednio lub za pomocą pobierania adresu URL)
  • Słownik elementów danych zmiennych
  • Obiekt — dane ustrukturyzowane oparte na węźle
  • Odbicie dowolnego obiektu języka C#
  • Programowe zmiany danych
  • Każda inna metoda, która obsługuje interfejs IDataSource

3. Umieszczanie elementu listy w celu zarządzania wizualnym objawem listy

4. Stronicowanie listy, przewijanie i wirtualizacja

  • Dane są pobierane tylko wtedy, gdy są widoczne lub przetwarzane
  • Obsługuje dowolnie duże zestawy danych zaplecza
  • Pobieranie jest ze zrównoważonym obciążeniem w wielu ramkach

5. Wyświetlanie listy prefab puli

  • Prefabs są ponownie używane i ponownie wypełniane w celu zmniejszenia czasu GC i tworzenia wystąpienia.

6. Dynamiczne stosowanie motywów do elementów w czasie wykonywania

Funkcjonalność planu działania

Oprócz tego, co jest już dostępne, najważniejsze priorytety dla większej liczby możliwości obejmują:

1. Potoki manipulatora danych

  • Konwersja między wartościami po stronie danych i wyświetlaniem stron
  • Lokalizacja (bezproblemowa integracja z lokalizacją aparatu Unity)
  • Formatowanie
  • Walidacja

2. Wstępne pobieranie elementu listy predykcyjnej w celu szybszego/płynnego przewijania/stronicowania

3. Więcej użytkowników danych

  • Ustawianie dowolnej właściwości publicznej w składniku
  • Ustaw pole wyboru włączone/wyłączone
  • Ustaw wartość suwaka
  • Ustawianie przycisku radiowego w grupie
  • Właściwości poszczególnych materiałów, takie jak kolor zestawu

4. Motywy

  • Wyświetlanie motywów zastosowanych w edytorze nawet wtedy, gdy aplikacja nie jest uruchomiona
  • Aktualizowanie prefabów w celu odzwierciedlenia zastosowanego motywu, aby stał się motywem domyślnym
  • Dziedziczenie motywu/stylu

Terminologia

  • Źródło danych — dowolny dostawca danych, niezależnie od tego, czy jest to stan środowiska uruchomieniowego, lokalnie utrwalany, czy pobierany z serwera.
  • Dostawca źródła danych — prosty obiekt MonoBehaviour, który zapewnia dostęp do źródła danych, które może nie być uwidocznione na grafie sceny aparatu Unity.
  • Typ źródła danych — unikatowa nazwa przypisana do źródła danych, tak aby użytkownicy danych mogli określić żądane źródła danych według nazwy.
  • Użytkownik danych — każdy użytkownik danych, który chce podejmować działania na podstawie zmian danych, zazwyczaj element wizualizacji, ale nie jest wymagany. Na przykład jej celem może być wyzwalanie akcji na podstawie zmian wartości danych.
  • Kontroler danych — mechanizm wywoływania akcji z aktualnie skojarzona wartością związaną z danymi podaną jako parametr.
  • Keypath — selektor danych, który odwołuje się do określonego obiektu w źródle danych. Zgodnie z aktualnie zaimplementowanym formatem ścieżki kluczy jest modelowany po akcesorach danych JSON w celu rozszyfrowania dowolnej zagnieżdżonej kombinacji map, list i elementów niepodzielnych.
  • Lokalna ścieżka klucza — ścieżka klucza po stronie odbiorcy danych, która może być trwale osadzona w prefab wielokrotnego użytku. Dzięki rozpoznawaniu jednostek kolekcji i maperów keypath zostanie ona automatycznie przekonwertowana na w pełni rozpoznaną ścieżkę klucza dla określonego elementu w kolekcji. Jeśli nie są skojarzone z kolekcją, mogą one być mapowane bezpośrednio na elementy dat w źródle danych lub można je najpierw zmodyfikować za pomocą mapatora ścieżki kluczy.

  • W pełni rozwiązana ścieżka klucza — pełna, bezwzględna ścieżka kluczowa mapowana na jeden konkretny obiekt w źródle danych. W przypadku elementów w kolekcji jest to kombinacja w pełni rozpoznanej ścieżki kluczy dla jednej jednostki kolekcji i względnej (lokalnej) ścieżki klucza dla jednego elementu danych tej jednostki kolekcji.

  • Maper ścieżki kluczy — opcjonalny maper przestrzeni nazw między lokalnymi ścieżkami kluczy i nazwami pól źródła danych (na przykład "link" <—> "URL").

  • Motyw — źródło danych, które udostępnia zestaw różnych zasobów i stylów potrzebnych do osiągnięcia konkretnej estetyki wizualnej.

  • Item Placer — towarzysz DataConsumerCollection odpowiedzialny za umieszczenie widocznych elementów w scenie.

  • Pula obiektów danych — utworzone wystąpienia, rezerwowe prefabryki gotowe do wypełnienia danymi na potrzeby nawigacji z listą o niskiej zawartości GC.

  • Wirtualizacja listy — możliwość wypełniania, prezentowania i nawigowania po listach o dowolnym dużym rozmiarze.

  • Prefetch predykcyjny — wstępne pobieranie danych i wypełnianie prefabów kolekcji dla elementów, które wkrótce mogą być widoczne za pomocą przewijania/stronicowania.

  • Predykcyjne pobieranie wstępne — wstępne pobieranie danych i wypełnianie prefabów kolekcji dla elementów, które wkrótce mogą być widoczne za pośrednictwem przewijania/stronicowania.

Kluczowe pojęcia

Źródło danych

Źródło danych to dowolny zarządzany zestaw danych dowolnego typu i złożoności, których można użyć do wypełniania widoków danych za pośrednictwem użytkowników danych. Dane zarządzane przez źródło danych mogą być statyczne lub dynamiczne. Wszelkie zmiany elementów danych zostaną zgłoszone wszystkim użytkownikom danych, którzy zarejestrowali się w celu otrzymywania powiadomień o zmianie.

Dostawca źródła danych

Prosty interfejs, który ma jedną metodę pobierania źródła danych. Ma to na celu umożliwienie automatycznego odnajdywania składnika skryptów MonoBehavior w hierarchii obiektów gry przez składniki konsumenta danych. Nie ma potrzeby implementowania źródła danych bezpośrednio na samym obiekcie gry. Jest to przydatne, gdy istniejący obiekt MonoBehaviour musi pochodzić z innej klasy, a wiele dziedziczenia uniemożliwia wyprowadzanie z bazy danych DataSourceGOBase. Umożliwia również więcej kodu, aby nie mieć zależności aparatu Unity.

Singleton dostawcy źródła danych

Narzędzie DataSourceProviderSingleton MonoBehaviour umożliwia określenie źródła danych, które można automatycznie odnaleźć, nawet jeśli nie znajduje się w tej samej hierarchii obiektu GameObject co obiekty DataConsumers, które chcą go słuchać. Wystarczy umieścić DataSourceProviderSingletonobiekt w dowolnym miejscu w scenie i wypełnić Data Sources właściwość wszystkimi źródłami danych, które mają zostać odnalezione przez użytkowników danych. Alternatywnie konsumenci danych przeprowadzą rodziców, aby znaleźć odpowiednie źródło danych, co oznacza, że możesz umieścić źródło danych, które zapewnia żądane dane w dowolnym miejscu w łańcuchu nadrzędnym tych odbiorców danych.

Ścieżka klucza (ciąg)

Ścieżka klucza to mechanizm umożliwiający unikatowe identyfikowanie dowolnych informacji w źródle danych.

Chociaż ścieżka klucza może być dowolnym unikatowym identyfikatorem dla elementu danych, bieżące implementacje używają specyfikatora czytelnego dla użytkownika logicznego, który wskazuje położenie nawigacji interesujących danych względem całego zestawu danych strukturalnych. Jest ona wzorowana na koncepcji list, słowników i elementów pierwotnych języka JavaScript. Ścieżki kluczy są składniowo poprawne instrukcje języka JavaScript na potrzeby uzyskiwania dostępu do danych, które mogą być reprezentowane w formacie JSON. Zaletą tego podejścia jest to, że dobrze koreluje zarówno z formatami JSON, jak i XML. Są to dwa najbardziej powszechne sposoby przesyłania informacji z usług zaplecza.

Przykładowe ścieżki kluczy:

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

Biorąc pod uwagę, że ścieżka klucza jest dowolnym ciągiem bez wymaganej taksonomii, rzeczywiste specyfikatory danych mogą być dowolną metodą opisywania danych do pobrania. Ścieżka XPath XML to przykład realnego schematu ścieżki klucza, który współdziała ze źródłami danych. Jeśli ścieżki kluczy udostępniane przez użytkownika danych są zgodne ze ścieżkami kluczy oczekiwanymi przez źródło danych, wszystko będzie działać. Ponadto mapowania ścieżek kluczowych można zaimplementować w celu tłumaczenia między różnymi schematami.

Rozpoznawanie ścieżki klucza

Rozpoznawanie ścieżki klucza oznacza połączenie dwóch ścieżek kluczowych:

  1. Bezwzględna ścieżka klucza opisującą sposób uzyskiwania dostępu do określonego podzestawu większego zestawu danych, takiego jak jeden wpis na liście wielu wpisów.
  2. Częściowa (względna) ścieżka klucza reprezentująca określoną wartość dat w ramach tej listy lub wpisu mapy.

Dzięki temu można traktować podzbiór danych w taki sposób, że nie ma znaczenia, gdzie w większej hierarchii zestawu danych rzeczywiście istnieje. Najbardziej krytycznym zastosowaniem tej możliwości jest opisanie danych pojedynczego wpisu na liście bez martwienia się, który wpis na tej liście odwołuje się do bieżącego wystąpienia.

Ponieważ ścieżka klucza "w pełni rozwiązana" jest zawsze generowana i zużywana przez źródło danych i rzadko lub nigdy nie powinna być modyfikowana przez element DataConsumer lub inny składnik zewnętrzny, może mieć dowolną strukturę, która ma sens w źródle danych. Jeśli na przykład istnieje prefab, aby wyświetlić wpis listy dla zdjęcia i jego tytułu, daty wykonanej i innych atrybutów, ścieżka klucza lokalnego w prefab może wyglądać następująco:

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

W pełni rozwiązane ścieżki kluczy dla jednego wpisu prefab na liście mogą wyglądać następująco:

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

Maper ścieżki klucza (IDataKeyPathMapper)

Maper ścieżek kluczowych umożliwia źródłom danych i konsumentom danych używanie różnych przestrzeni nazw i konwencji dla ścieżek kluczowych i nadal współpracują ze sobą.

Prefab dla powszechnie używanego elementu, takiego jak łupek do wyświetlania informacji kontaktowych osoby, może zawierać pola zmiennych zarządzanych przez użytkowników danych. Aby było to możliwe, identyfikator używany dla dowolnego aspektu zmiennej prefab wymaga sposobu mapowania na identyfikator poprawnego danych w źródle danych, który w każdym użyciu prefab określa zawartość tego elementu zmiennej. Maper ścieżki klucza umożliwia to.

Prefab może być używany z różnymi źródłami danych, w których dane są przechowywane w innej strukturze organizacyjnej i używają nazw pól. Aby użyć prefab szablonu z każdym źródłem danych, maper ścieżki klucza może rozwiązać wszelkie różnice w sposobie organizowania danych.

Odbiorca danych (IDataConsumer)

Obiekt, który wie, jak korzystać z informacji zarządzanych przez źródło danych i używać tych danych do wypełniania widoków danych.

Użytkownicy danych mogą zarejestrować się w źródle danych, aby otrzymywać powiadomienia o wszelkich zmianach w elemencie danych, który istnieje w określonej ścieżce klucza w zestawie danych. Za każdym razem, gdy określone dane uległy zmianie (lub podejrzewa się, że uległy zmianie), odbiorcy danych zostaną powiadomieni.

Zbieranie danych przez konsumentów

Zbieranie danych użytkowników ma dodatkową możliwość zarządzania listą podobnych elementów. Ta lista może być całym zestawem danych zarządzanym przez źródło danych lub tylko podzbiorem. Zazwyczaj dane dla każdego elementu na liście zawierają podobne typy informacji, ale nie jest to wymagane. Źródła danych i odbiorcy danych mogą obsługiwać listy zagnieżdżone, takie jak lista słów kluczowych skojarzonych z poszczególnymi zdjęciami na liście zdjęć skojarzonych z każdą osobą na liście kontaktów. Ścieżka kluczowa słów kluczowych byłaby względna względem zdjęcia, a ścieżka klucza dla zdjęć byłaby względna wobec osoby, a ścieżka kluczowa osoby byłaby względna do najbliższej listy nadrzędnej lub katalogu głównego zestawu danych.

Podczas przetwarzania kolekcji prawidłowa rozpoznana ścieżka klucza dla określonego wpisu w kolekcji jest przypisywana do każdego odbiorcy danych znalezionego w prefab, który jest tworzone dla każdego elementu kolekcji. Następnie służy do pełnego rozpoznawania ścieżki klucza dla wszystkich względnych (lokalnych) danych widoku w tym prefab.

Miejsce elementu zbierania danych

Użytkownik danych zbierających dane potrzebuje środków, aby wypełnić środowiska użytkownika listami powtarzających się elementów wizualnych, takich jak to, co można znaleźć na przewijanej liście produktów, zdjęć lub kontaktów. Jest to realizowane przez przypisanie elementu zastępczego do odbiorcy danych kolekcji. To miejsce elementu to logika tha wie, jak żądać elementów listy, zaakceptować prefabryki, które zostały wypełnione danymi zmiennych, a następnie przedstawić je użytkownikowi, zazwyczaj przez wstawienie ich do listy zarządzanej przez składnik układu środowiska użytkownika dla list.

Używanie motywów

Motywy używają wszystkich źródeł danych i odbiorców danych. Istnieje możliwość motywowania dowolnej hierarchii obiektów GameObject niezależnie od tego, czy są statyczne, czy dynamicznie powiązane z innymi źródłami danych. Umożliwia to zastosowanie zarówno powiązania danych, jak i ich zastosowania w połączeniu. Istnieje nawet możliwość motywowania danych pochodzących z innego źródła danych.

Blokowy diagram i przepływ danych

Przepływ danych z motywami zestawu narzędzi MRTK

Motywy zestawu narzędzi MRTK

Motywy to możliwość zmiany estetyki wizualnej wielu elementów środowiska użytkownika jednocześnie. Zazwyczaj wszystkie dane potrzebne do określenia motywu są dostarczane przez pojedyncze źródło danych, takie jak obiekt skryptowy. Możliwe jest również, aby dane te były dostarczane w razie potrzeby lub podzielone na grupy logiczne w oparciu o ich przeznaczenie.

Motywy MRTK3

MrTK3 Motywy połączone z powiązaniem danych

Powiązanie danych i motywy mogą współistnieć dla jednego elementu środowiska użytkownika. Każdy pojedynczy element środowiska użytkownika może być jednocześnie tematyce i powiązany z danymi. W tym scenariuszu typowy przepływ polega na tym, że datum pochodzące z źródła danych jest używane do uzyskiwania poprawnej ścieżki klucza motywu. Ta ścieżka klucza jest następnie używana do pobierania obiektu ze źródła danych motywu, zazwyczaj profilu ScriptableObject, ale potencjalnie dowolnego źródła danych, które mogą rozpoznać ścieżkę klucza.

Aby uprościć konfigurację tworzenia motywów i powiązania danych, można utworzyć profile powiązań przetwarzane przez element BindingConfigurator w czasie tworzenia wystąpienia.

  • Profil BindingConfigurator powiązania przetwarza w celu określenia zasobów w prefab, które mają być motywami, i kojarzy zarówno powiązane elementy danych, jak i elementy z możliwością ich tworzenia z kluczami. Następnie dodaje odpowiednie DataConsumers do powiązania tych elementów wizualnych z odpowiednimi selektorami keypaths, które będą używane do odwołwania się do określonych danych w co najmniej jednym DataSourceselemencie , które są zwykle zewnętrzne dla samej prefab.
  • Dane motywu są dostarczane przez element DataSource zawierający dane dla każdej ścieżki kluczy zidentyfikowanej w profilu powiązania.
  • Skrypt ThemeProvider pomocnika ułatwia używanie obiektu ScriptableObject jako elementu DataSource do obsługi motywów.
  • Standardowy motyw środowiska użytkownika jest dostarczany przez MRTK_UX_ThemeProfile obiekt ScriptableObject , który jest powiązany z elementem DataSourceReflection w obiekcie ThemeProvider.

Diagram przepływu źródła danych profilu motywu

Osadzone źródło danych

Osadzone źródło danych jest odpowiednie w dwóch sytuacjach:

  1. Gdy każde wystąpienie prefab może mieć różne ustawienia motywu i wymaga własnego oddzielnego źródła danych.
  2. Gdy wszystkie wystąpienia tego prefab są zarządzane przez jeden wspólny profil utrwalonego motywu (na przykład ScriptableObject) i mogą być udostępniane za pomocą osadzonego źródła danych, aby nie było żadnych zależności zewnętrznych do ustanowienia.

DataSourceReflection

Może to przekształcić dowolną strukturę lub klasę DataSource języka C# w obiekt za pomocą odbicia w celu mapowania ścieżek kluczy na pola, właściwości, zagnieżdżone klasy, tablice, listy lub słowniki. Można go skojarzyć z obiektem Unity ScriptableObject lub dowolną inną strukturą lub klasą języka C#, w której istnieją dane motywu. Wystąpienie obiektu zawierającego dane może być wstrzykiwane i zmieniane w czasie wykonywania.

  1. Obiekt skryptowy: przydatny w przypadku motywów statycznych udostępnianych w wielu prefabach.
  2. Nietrwała struktura lub klasa języka C#: przydatne w przypadku dynamicznych modyfikacji w czasie wykonywania motywu.

DataSourceJson

Jeśli dane istnieją jako json tekst, zarządza to mapowaniem ścieżek kluczowych do json modelu DOM. Zasoby binarne można pobrać z zasobów aparatu Unity, zasobów przesyłania strumieniowego, a nawet pobranego adresu URL.

DataSourceDictionary

Jest to prosta opcja, gdy lista czysto płaska jest wystarczająco dobra, aby zaspokoić potrzebę i szybkie prototypowanie. Wszystkie zasoby z motywami są obsługiwane, w tym tekst, zasoby aparatu Unity (na przykład materiały, sprites i obrazy), zasoby, zasoby przesyłania strumieniowego, a nawet pobieranie zewnętrzne za pośrednictwem adresu URL.

Niestandardowy

Dowolne niestandardowe źródło danych, które implementuje prosty IDataSource interfejs lub pochodzi z DataSourceBase lub DataSourceGOBase może służyć do spełnienia niestandardowych potrzeb.

Motywy UXComponents

Standardowe kontrolki UXComponents dostępne w pakiecie UXComponents są skonfigurowane do obsługi ich obsługi. Domyślnie jest ona wyłączona, ale jest łatwa do włączenia.

Każda kontrolka, zazwyczaj w górnej części obiektu GameObject głównego prefab, ma skrypt o nazwie UXBindingConfigurator. Ten skrypt, jeśli jest włączony, spowoduje ściągnięcie wymaganych skryptów powiązania danych w celu włączenia ich. Pamiętaj, aby zaimportować również pakiet Powiązanie danych i Motywy.

Uwaga dotycząca arkuszy Stylów TextMeshPro: obecnie nie można używać arkuszy Stylów do stylu TextMeshPro w normalnym stylu. Można użyć dowolnego innego stylu zawartego w domyślnym arkuszu stylów TextMeshPro. W przykładach treść służy do obejścia tego ograniczenia.

DataSourceThemeProvider

Obiekt DataSourceThemeProvider MonoBehaviour może służyć do łatwego tworzenia obiektu ScriptableObject zawierającego wszystkie odwołania do wszystkich elementów zawartości z motywami jako źródła danych. Przedstawiono to w scenie UXThemingExample.

ThemeSelector

Funkcja ThemeSelector MonoBehaviour umożliwia określenie i łatwe zamianę między wieloma profilami ScriptableObject. Przykładem może być ułatwienie przełączania się między motywem "Ciemny" a motywem "Jasny". Dodaj element ScriptableObjects do Theme Profilesobiektu , zazwyczaj w czasie projektowania. Następnie w czasie wykonywania zmień Current Theme właściwość , aby zmienić motyw.

Motywy odbiorców danych

Motywy są realizowane przez odbiorców danych, szczególnie te, które dziedziczą z klasy DataConsumerThemeBase<T>, DataConsumerTextStyle i niestandardowe klasy DataConsumer, które każdy deweloper może zaimplementować w celu zwiększenia obsługi motywów.

Klasa bazowa DataConsumerThemeBase<T> udostępnia logikę użycia liczby całkowitej lub kluczowego źródła danych z podstawowego źródła danych w celu wyszukania żądanej wartości końcowej z pomocniczej bazy danych motywu. Jest to realizowane przez mapowanie danych wejściowych na ścieżkę kluczową motywu, a następnie użycie tej ścieżki klucza motywu w celu pobrania wartości końcowej. Dzięki temu każdy element może być jednocześnie powiązany z danymi i z motywami. Wyobraźmy sobie na przykład pole stanu w bazie danych ze stanami Nowe, Uruchomione i Gotowe reprezentowane przez wartości 0, 1 i 2. Każdy z nich może być reprezentowany przez ikonę Sprite. W przypadku powiązania danych wartość z zakresu od 0 do 2 jest używana do wyszukiwania żądanego sprite. Dzięki powiązaniu motywów i danych profil motywu wskazuje prawidłową listę trzech sprites w profilu motywu, a następnie wartość z zakresu od 0 do 2 służy do wybierania poprawnego sprite z tej listy. Dzięki temu style tych ikon różnią się w zależności od motywu.

Gdy oba środowiska uruchomieniowego i powiązanie danych dynamicznych są używane razem, klasę DataConsumerThemeHelper można określić w dowolnej klasie DataConsumerThemeBase, aby powiadomić o zmianie motywu.

Zamiana motywów w czasie wykonywania jest realizowana przez zastąpienie danych w źródle danych motywu nowym zestawem danych określonym w tej samej topologii modelu obiektów danych. Element DataSourceReflection może być używany z obiektami ScriptableObjects, gdzie każdy profil reprezentuje motyw. W przypadku wszystkich kontrolek środowiska użytkownika mrTK Core profil motywu jest obiektem ScriptableObject o nazwie MRTK_UXComponents_ThemeProfile. Skrypt pomocnika ThemeProvider.cs ułatwia korzystanie z tego lub dowolnego profilu ScriptableObject jako źródła danych.

Metoda stosowania motywu do danych dynamicznych może zostać automatycznie wykryta w większości przypadków lub można ją jawnie określić.

Gdy dane są używane do wybierania poprawnego elementu ze źródła danych motywu, proces jest:

  • datum z podstawowego źródła danych służy do wybierania lub konstruowania poprawnej ścieżki klucza motywu
  • ścieżka klucza motywu służy do pobierania wartości ze źródła danych motywu określonego w dataConsumerThemeHelper
  • pobrana wartość motywu jest analizowana w celu automatycznego wykrywania poprawnej metody pobierania
  • Końcowy element danych o poprawnym typie (na przykład Materiał, Sprite lub Obraz) jest pobierany przy użyciu metody wykrytej automatycznie.

Typy danych

Oczekiwany typ danych danych używany do pobierania żądanego obiektu może być jednym z następujących elementów:

Typ danych opis
Wykryj automatycznie… Dataum jest analizowane i automatycznie wykrywana jest poprawna interpretacja. Aby uzyskać więcej informacji, zobacz "Autowykryj typ danych".
DirectValue Oczekuje się, że datum ma być żądany typ T (na przykład Materiał, Sprite, Obraz) i używany bezpośrednio.
DirectLookup Integralny indeks lub klucz ciągu służący do wyszukiwania żądanej wartości z lokalnej tabeli odnośników.
StaticThemedValue Statyczny obiekt motywu poprawnego typu jest pobierany ze źródła danych motywu przy określonej ścieżce klucza motywu.
ThemeKeypathLookup Integralny indeks lub klucz ciągu służy do wyszukiwania żądanej ścieżki klucza motywu.
ThemeKeypathProperty Nazwa właściwości ciągu, która zostanie dołączona do ścieżki klucza podstawowego motywu podanej w temacie Motyw.
ResourcePath Ścieżka zasobu do pobierania wartości z zasobu aparatu Unity (może zaczynać się od "resource://").
FilePath Ścieżka pliku do pobierania zasobu przesyłania strumieniowego aparatu Unity (może zaczynać się od "file://").

Automatyczne wykrywanie typu danych

Autowykrywanie analizuje odebrane dane i automatycznie decyduje o metodzie pobierania. W poniższej tabeli T reprezentuje żądany typ, taki jak Materiał, Sprite, Obraz. Autowykrywanie może wystąpić w dwóch miejscach w procesie:

  • Na podstawowej wartości datum.
  • Na temat wartości pobranej za pośrednictwem podstawowej datum.
Typ datum Kwestie wymagające rozważenia Ma pomocnika motywu Zachowanie
T nie dotyczy Tak/Nie Używane bezpośrednio bez motywów
int dowolny całkowity ciąg pierwotny lub int32, który można przeanalizować Nie. Przekazano jako indeks do pochodnego getObjectByIndex(n) w celu pobrania obiektu Nth typu T.
int dowolny całkowity ciąg pierwotny lub int32, który można przeanalizować Tak Zaindeksuj, aby pobrać ścieżkę klucza motywu Nth z lokalnego wyszukiwania, a następnie pobrać obiekt z motywu za pomocą automatycznego wykrywania.
string Format: "resource://{resourcePath}" Tak/Nie resourcePath służy do pobierania zasobu aparatu Unity
string Format: "file://{filePath} Tak/Nie filePath służy do pobierania elementu zawartości przesyłania strumieniowego
string Inne Nie. Przekazano jako klucz do pochodnego getObjectByKey() w celu pobrania pasującego obiektu typu T.
string Inne Tak Klucz pobierania pasującej ścieżki klucza motywu z lokalnego wyszukiwania, a następnie pobierania obiektu z motywu za pomocą funkcji automatycznego wykrywania.

Przykład pobierania ikony stanu motywu z bazy danych zawierającej wartość stanu liczbowego:

  1. Ścieżka klucza ikony stanu w bazie danych jest status.sprite_index.
  2. Pobrana wartość dla status.sprite_index to 2, co oznacza stan "anulowany".
  3. Wpis N=2 (innymi słowy, trzeci) w odnośniku DataConsumerSprite jest ustawiony na wartość "Status.Icon.Cancelled".
  4. Jest to ścieżka klucza używana do pobierania wartości ze źródła danych "motywu".
  5. Wartość ścieżki kluczy "Status.Icon.Cancelled" to "resource://Sprites/sprite_cancelled".
  6. Funkcja automatycznego wykrywania określa, że powinna pobrać ikonę za pośrednictwem zasobu znajdującego się w lokalizacji "Resources/Sprites/sprite_cancelled"

TextMeshPro StyleSheets

Motywy mogą aktywować arkusze stylów TMPro. Obiekt ScriptableObject "Ustawienia TMP" określa, gdzie powinny znajdować się arkusze stylów w zasobach. Jest to właściwość "Domyślny zasób czcionki => ścieżka".

Pamiętaj, aby umieścić wszystkie arkusze StyleSheet specyficzne dla aplikacji w tej samej ścieżce podrzędnej w obszarze Zasoby. Jeśli chcesz zorganizować je inaczej, pamiętaj, aby zaktualizować ustawienia TMP tak, aby były zgodne.

Tworzenie nowych kontrolek środowiska użytkownika, które można z nich korzystać

Jeśli opracowujesz nowe kontrolki środowiska użytkownika, stosunkowo łatwo jest je udostępnić. W zakresie, w jakim kontrolka używa materiałów, sprites i innych zasobów już używanych przez inne kontrolki środowiska użytkownika, zazwyczaj jest to kwestia nazewnictwa różnych obiektów gry w sposób możliwy do odnalezienia.

Można dziedziczyć MRTK_UXCore_ThemeProfile i dodawać bardziej czytelne pola lub wskazywać kontrolki na własny obiekt ScriptableObject. Nie ma nic magicznego w tych, pod warunkiem; organizacja obiektu ScriptableObject określi ścieżki kluczy potrzebne do uzyskania dostępu do poszczególnych elementów danych za pomocą odbicia języka C#.

Dodając skrypt BindingConfigurator.cs do najwyższego poziomu nowej kontrolki, można następnie określić własny serializowany obiekt BindingProfile ScriptableObject. Zapewni to niezbędną nazwę Obiektu GameObject mapowania KeyPath potrzebne do skojarzenia elementów z elementami, które można z nich powiązać z danymi podanymi w profilu motywu. Ten skrypt automatycznie doda wszystkie potrzebne składniki DataConsumerXXX w czasie wykonywania, aby obsługiwać motywy, których chcesz użyć.

Wprowadzenie

Wymagania

  • Unity 2020.3 LTS lub nowszy
  • TextMeshPro 2.1.4 lub nowszy

Przykładowe sceny

Aby zapoznać się z pierwszym krokiem, przyjrzyj się bliżej różnym przykładom powiązań danych w pakiecie PRZYKŁADY zestawu narzędzi MRTK i przyjrzyj się, jak skonfigurowano różne źródła danych MonoBehaviours. Ogólnie rzecz biorąc, skrypty powiązań danych muszą być umieszczone tylko na najwyższym poziomie GameObject prefab lub powiązany zestaw elementów środowiska użytkownika.

Ponadto w większości przypadków użycia wartości domyślne działają "poza polem", ale uwidocznione właściwości zapewniają dużą elastyczność w przypadku bardziej zaawansowanych przypadków.

Uwaga

Aby włączyć motywy dla standardowych składników środowiska użytkownika zestawu narzędzi MRTK, MRTK_UX_DATABINDING_THEMING_ENABLED symbol musi być zdefiniowany w ustawieniach odtwarzacza. Ten symbol zapewnia zerowy wpływ na wydajność, gdy motywy nie są potrzebne.

Assets/DataBinding Example/Scenes/DataBindingExamples.scene

Ta scena, która demonstruje różne scenariusze danych zmiennych. Wystarczy załadować scenę i odtworzyć. Kilka rzeczy, które należy zauważyć:

  • Pole Wprowadzanie tekstu składników TextMeshPro zawiera zmienne, które wyglądają następująco: {{ firstName }}. Te znaczniki są używane bezpośrednio jako lokalne ścieżki kluczy.

  • Obiekty gry dla sprites i tekstu mają jakąś formę składnika Data Consumer, który zarządza odbieraniem danych i aktualizowaniem widoków.

  • Pojedynczy odbiorca danych może być współużytkowany przez wiele składników tego samego typu, umieszczając go wyżej w hierarchii JĘZYKA GO.

  • Użytkownik danych może znaleźć własne źródło danych, o ile znajduje się on w tym samym obiekcie gry lub wyższym w hierarchii GO.

  • Obiekt nadrzędny gry ma składnik Źródła danych, który dostarcza dane dla wszystkich obiektów gier podrzędnych, które przedstawiają powiązany zestaw informacji o zmiennych.

  • Odbiorca danych kolekcji określa prefab, który sam zawiera odbiorców danych, które będą używane do wypełniania tej prefab ze zmiennymi danymi.

Przykład motywów Assets/UX/Scenes/AudioTheming

W tym przykładzie użyto motywu do przełączania audioClips między zestawem dla fortepianu a jednym dla Xylophone.

Przykład motywów Assets/UX/Scenes/BatteryLevelExample

Ten przykład łączy motywy i powiązanie danych, aby pokazać poziom baterii zarówno jako wartość liczbową, jak i jako ikonę. Motywy służą do wybierania między "ich ładowaniem" a motywem "not charging". Jest ona przeznaczona do spełnienia następujących celów:

  • Wszystkie zasoby wizualne mogą istnieć w jednym ScriptableObject profilu motywu.
  • Liczba sprites dla stanów "ładowania" może się różnić od liczby stanu "nie naliczania opłat".
  • Algorytm mapowania zgłaszanego poziomu baterii do określonego sprite może być nieliniowy i różnić się między stanami "ładowania" i "nie ładowania".
  • Wszystkie zasoby wizualne mogą istnieć w jednym ScriptableObject profilu motywu.
  • Liczba sprites dla stanów ładowania może się różnić od liczby nieoładowania stanu.
  • Algorytm mapowania zgłaszanego poziomu baterii, do którego sprite może być nieliniowy i różni się między stanami ładowania, a nie ładowania.

Uwaga

Struktura tego pokazu nie jest dobrym przykładem łączenia motywów i powiązania danych. W aplikacji produkcyjnej w celu odpowiedniego rozdzielenia modelu i widoku rzeczywisty stan baterii (poziom i ładowanie) będzie dostarczany w osobnym źródle danych niż lokalizatory zasobów dla samych sprites.

Przykład motywów Assets/UX/Scenes/UXThemingExample

W tym przykładzie pokazano zmianę motywu całej aplikacji, a także pokazano użycie DataSourceGODictionary jako źródła danych do zarządzania różnymi treściami tekstowymi, które mają być wyświetlane w środowisku użytkownika. W bardziej kompleksowym scenariuszu inne bardziej elastyczne typy źródeł danych mogą zapewnić wymaganą elastyczność, taką jak DataSourceReflection lub DataSourceGOJson.

Pierwszy projekt powiązania danych

Oto prosty przykład, który ułatwia szybkie rozpoczęcie pracy:

  1. Utwórz nową scenę.
  2. W menu Zestaw narzędzi Mixed Reality Toolkit wybierz opcję Dodaj do sceny i Konfiguruj .
  3. Utwórz pusty obiekt gry i zmień jego nazwę na "Powiązanie danych". Dodaj składnik DataSourceJsonTest.
  4. W inspektorze zmień adres URL na: https://www.boredapi.com/api/activity
  5. Dodaj obiekt interfejsu użytkownika —> TextMeshPro do obiektu gry Powiązanie danych. Spowoduje to dodanie kanwy, a następnie obiektu "Text (TMP)".
  6. Wybierz obiekt Text (TMP), a w inspektorze zmień tekst na:

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

  1. Wybierz obiekt Kanwy i dodaj do niego składnik Tekst odbiorcy danych.
  2. Uruchamianie projektu. Co 15 sekund zostanie wyświetlone inne działanie.

Gratulacje. Utworzono pierwszy projekt powiązania danych za pomocą zestawu narzędzi MRTK!

Pisanie nowego źródła danych

Źródło danych udostępnia dane co najmniej jednemu użytkownikowi danych. Jego dane mogą być dowolne: generowane algorytmowo, w pamięci RAM, na dysku lub pobierane z centralnej bazy danych.

Wszystkie źródła danych muszą udostępnić interfejs IDataSource. Niektóre z podstawowych funkcji są oferowane w klasie bazowej o nazwie DataSourceBase. Najprawdopodobniej chcesz pochodzić z tej klasy, aby dodać określone funkcje zarządzania danymi specyficzne dla potrzeb.

Aby umożliwić usunięcie źródła danych jako składnika do obiektu gry, istnieje inny obiekt podstawowy o nazwie DataSourceGOBase , gdzie GO oznacza GameObject. Jest to element MonoBehavior, który można porzucić na obiekt GameObject jako składnik. Jest to cienki serwer proxy, który został zaprojektowany do delegowania pracy do źródła danych podstawowego specyficznego dla środowiska Unity.

Źródło danych może uwidocznić możliwość manipulowania danymi w edytorze aparatu Unity. Jeśli tak jest, klasa pochodna może zawierać całą logikę źródła danych lub może korzystać ze źródła danych "stock", ale także dodać pola Inspector lub inne sposoby konfigurowania danych.

Pisanie nowego konsumenta danych

Użytkownik danych otrzymuje powiadomienia o zmianie danych, a następnie aktualizuje pewien aspekt środowiska użytkownika, taki jak tekst wyświetlany w składniku TextMeshPro.

Wszyscy odbiorcy danych muszą podać interfejs IDataConsumer. Niektóre z podstawowych funkcji są oferowane w klasie bazowej o nazwie DataConsumerGOBase, gdzie GO oznacza GameObject.

Większość pracy użytkownika danych polega na zaakceptowaniu nowych danych, a następnie przygotowaniu ich do prezentacji. Może to być tak proste, jak wybranie właściwej prefab lub może oznaczać pobieranie większej ilości danych z usługi w chmurze, takiej jak system zarządzania zawartością.

Zapisywanie elementu zbierania danych — miejsce elementu

Miejsce elementu zbierania danych jest odpowiedzialne za zarządzanie tym, które części kolekcji są obecnie widoczne i jak przedstawić widoczną kolekcję, niezależnie od tego, czy kolekcja jest małą listą statyczną, czy gigantyczną milionową bazą danych rekordów.

Wszystkie elementy zastępcze muszą podać interfejs IDataCollectionItemPlacer. Niektóre z podstawowych funkcji są oferowane w klasie bazowej o nazwie DataColletionItemPlacerGOBase. Wszystkie elementy zastępcze powinny pochodzić z tej klasy.

Znane ograniczenia i brakujące funkcje

  • Nie jest jeszcze zintegrowana z kontrolkami opartymi na kanwie aparatu Unity i listami przewijanymi.
  • Integracja programu .NET INotifyPropertyChanged nie jest jeszcze zaimplementowana.
  • Przykładowa scena, która pobiera obrazy z platformy Flickr i trymrtk.com nie działa na urządzeniu HoloLens z powodu błędu PROTOKOŁU SSL HTTPS w nowszych wersjach aparatu Unity.
  • Dodatkowe dostrajanie wydajności.
  • Ta wersja koncentruje się na prezentacji danych, a nie przechwytywaniu danych. Kontrolki środowiska użytkownika zestawu narzędzi MRTK nie są jeszcze przewodowe do ustawiania stanu w obiekcie DataSource.
  • Dynamiczne zmiany w danych listy całkowicie odświeża całą listę zamiast przyrostowego aktualizowania.
  • Potok manipulowania danymi nie został jeszcze zaimplementowany
  • Wypełnianie wszystkich składników środowiska użytkownika na łupku nie jest jeszcze w pełni obsługiwane.
  • Węzły DataSourceJson powinny implementować IDataNode interfejs, aby umożliwić współdziałanie z obiektami DataSourceObjects.