I have some general questions about handling state changes. Coming off of Unity UGUI, I have a class object for each screen state that contain different events/properties relative to those UIs. It seems as though I can carry over this concept to Noesis as DataContexts but its not clear how I can wire everything together..

To start with..

I see that there are both Visual States & Storyboards in Studio.. Storyboards basically are 'animation graphs' which is obvious enough.. I can fade in/fade out screens beautifully.. no problem there... but Visual States has no documentation other than the class reference, and its not exactly clear what their purpose is. Do these play a role?

So more broadly, what is the intended workflow for dealing with screen state transitions, and then calling back to Unity to indicate a transition is complete?

"StoryboardCompletedTrigger" seems to be a good starting point but I'm assuming I need to have a boolean flag or some such thing so Unity knows the exact moment its safe to enable/disable the next screen state. Or should I be allowing Noesis todo that for me and just send messages backwards to Unity?

If any of those are stupid questions, just point me to a Sample and say 'figure it out'

As you mentioned Storyboard are simple timelines with key frame animations, and you can use the StoryboardCompletedTrigger to determine when they're finished. From that trigger you can start new animations (ControlStoryboardAction), change states (GoToStateAction) or even invoke a command (InvokeCommandAction) that will call Unity code.

VisualStates are commonly used inside controls to define the appearance depending on its state. For example a Button will define its MouseOver and Pressed states, or Unfocused and Focused states; a ListBoxItem can also specify its Unselected and Selected states; and so on. Those states are automatically launched by the control when appropriate so you don't have to care about that.

Apart from that you can create VisualStates for whole screens and manually set them using any kind of trigger (like DataTrigger, EventTrigger, etc.) plus a GoToStateAction when you need.

Or should I be allowing Noesis todo that for me and just send messages backwards to Unity?

Ideally from Unity you just expose a "Data State" to Noesis, and using triggers + actions you handle everything from within the XAML. And as I mentioned before, by changing properties or invoking commands you can call back to Unity code.

Hope this helps. If you need further details on anything please let me know.

I'm sorry to say now I'm just more confused. If different screen states exist in different XAML files, presumably Unity needs to be in charge of changing XAML files and the event triggers therein reflect on the DataContext.

Honestly I think I'll just pause on my UI development for now until I see some updated YT videos or something more comprehensive surrounding the integration.. I've been at this for over a week now and I've made zero progress in getting anything to work the way I would expect. The NorthGame sample looks to be a proper real-world use case but it kills Unity constantly and shows errors in Studio OOTB.

Do we have any timelines around any new materials that would be relevant to Unity? And did I read correctly, is there an updated integration forthcoming?

The NorthGame sample looks to be a proper real-world use case but it kills Unity constantly and shows errors in Studio OOTB.

This was fixed in version 3.2.8, which was released today. The Unity tutorial has been fully reviewed, although its overall structure remains the same

Rockin'


At the very least it does run in-engine and doesn't appear to crater.

I updated the NorthGame sample in our GitHub (there were a few wrong font names), please download it again.
Remember to build the solution in Blend so it downloads the Noesis.GUI.Extension nuget that is required to support all our extensions.
You should be able to see the xamls in Blend designer without errors now.