Is there a best practice for when to show which ui in a DataBinding way? I believe I saw someone have a custom control where they had all their other controls hidden based on data. Is that best practice or is that wasteful?

Hello,

There are different alternatives depending on each scenario.

For example you can approach the navigation by splitting your different screens in several UserControls and then have a master/root xaml that references all of them and just changes the visibility to show/hide the active screen, like we did in our Menu3D sample.

Another options is to have a pure MVVM approach where navigation is driven by the view model by exposing properties with a different view model type for each screen. Then you can define DataTemplates registered by type to decide what to show depending on the type of view model. This is how our Layered UI sample is built.

Hope this helps.

In WPF wouldn't this typically be handled in a Window with Pages? Does Noesis support that?

An example for that kind of thing could be really valuable.

Pages in WPF are mostly intended to be used in browser like applications (usually with back and forward buttons) and hosted inside a NavigationWindow or Frame.
Noesis does not implement those containers. Please create a ticket in our bugtracker if you require we support Frame or NavigationWindow in our framework.

Would your other solutions scale well enough to very complex frontends, or should we look into creating some kind of custom control for stacking pages? The game I am working on currently has around 50 screens in the frontend which can be organized into different flows game which each contain 10-15 screens.

We currently manage flows through a state system where a state is totally seperate from views or viewmodels, and it has grown very, very messy. In new projects I would be looking to try something different for managing navigation.

Using visibility to show/hide different screens included in a master xaml makes sense in controlled scenarios with a few screens that interact between them.

But if you need a more dynamic navigation flow then having a state machine will make more sense. The way you expose those states to the UI may differ depending on your needs, but usually a simple ContentControl binding its content to the screen viewmodel, and using DataTemplates to decide which content to show depending on the data type might work. You can also implement a more complex control that is able to apply fade in and fade out animations when switching the content to a new screen.

Although both can coexist, you can have some screens where just showing/hiding parts will be enough.