- AdamJonsson
- Posts: 10
- Joined:
Should I use Pages or Windows for different screens in App. Suggestions for making a Navbar.
The mobile app I'm working on has a Navigation bar at the bottom of the screen with four buttons. It's always visible and will toggle different screens.
I thinking that the content of each screen would be designed as a page and clicking the buttons will determin which page is shown in the Window.
Is this a good way to go or is it better to create each screen as it's own Window and have the Navbar as a CustomControl ontop of each Window?
Clicking the buttons in the NavBar would then swap which window is visible.
My gut tells me that the first option is more correct.
I thinking that the content of each screen would be designed as a page and clicking the buttons will determin which page is shown in the Window.
Is this a good way to go or is it better to create each screen as it's own Window and have the Navbar as a CustomControl ontop of each Window?
Clicking the buttons in the NavBar would then swap which window is visible.
My gut tells me that the first option is more correct.
- AdamJonsson
- Posts: 10
- Joined:
Re: Should I use Pages or Windows for different screens in App. Suggestions for making a Navbar.
Or is this usually done with a TabControl?
-
sfernandez
Site Admin
- Posts: 2997
- Joined:
Re: Should I use Pages or Windows for different screens in App. Suggestions for making a Navbar.
Noesis (WPF) gives you the flexibility to structure your screens as you prefer.
Having a single window that loads different content depending on the selected page in the navigation bar seems better to me than having different windows sharing the same control.
Using a TabControl for that first approach can be one way to accomplish it. You can even have each screen defined as a different UserControl that gets loaded when selecting the corresponding tab:
Having a single window that loads different content depending on the selected page in the navigation bar seems better to me than having different windows sharing the same control.
Using a TabControl for that first approach can be one way to accomplish it. You can even have each screen defined as a different UserControl that gets loaded when selecting the corresponding tab:
Code: Select all
<Grid ...>
<Grid.Resources>
<DataTemplate DataType="{x:Type local:Page1ViewModel}">
<local:Page1Control />
</DataTemplate>
<DataTemplate DataType="{x:Type local:Page2ViewModel}">
<local:Page2Control/>
</DataTemplate>
...
</Grid.Resources>
<TabControl ItemsSource="{Binding Pages}".../>
</Grid>
- AdamJonsson
- Posts: 10
- Joined:
Re: Should I use Pages or Windows for different screens in App. Suggestions for making a Navbar.
What's the reason for using DataTemplates in <Grid.Resources> and <TabControl ItemsSource="{Binding Pages}".../>?
I'm don't quite understand what it means?
I did this and it works, but I assume there are some downsides with it as it's not what you recommended..
I'm don't quite understand what it means?
I did this and it works, but I assume there are some downsides with it as it's not what you recommended..
Code: Select all
<TabControl Grid.Row="1" Style="{DynamicResource NabTabStyle_TabControl}">
<TabItem Header="Screen 1">
<uc:Screen1/>
</TabItem>
<TabItem Header="Screen 2">
<uc:Screen2/>
</TabItem>
<TabItem Header="Screen 3">
<uc:Screen3/>
</TabItem>
<TabItem Header="Screen 4">
<uc:Screen4/>
</TabItem>
</TabControl>
-
sfernandez
Site Admin
- Posts: 2997
- Joined:
Re: Should I use Pages or Windows for different screens in App. Suggestions for making a Navbar.
Using <TabControl ItemsSource="{Binding Pages}".../> is following a MVVM pattern, where tabs are defined in the ViewModel data, instead of explicitly in xaml.
If your application has a fixed and known number of tabs you can just define them as you did. In our Menu3D sample we have a fixed number of screens and we also specify the different UserControls directly in the main page, and then they are made visible depending on the selected menu option.
The downside of directly specifying UserControls in your main xaml instead of via DataTemplates is that all screen files will be loaded in the application when the main window gets loaded. If you have many screens (or big ones) maybe is better to split that in templates so screens are only loaded when they are really selected:
If your application has a fixed and known number of tabs you can just define them as you did. In our Menu3D sample we have a fixed number of screens and we also specify the different UserControls directly in the main page, and then they are made visible depending on the selected menu option.
The downside of directly specifying UserControls in your main xaml instead of via DataTemplates is that all screen files will be loaded in the application when the main window gets loaded. If you have many screens (or big ones) maybe is better to split that in templates so screens are only loaded when they are really selected:
Code: Select all
<Grid ...>
<Grid.Resources>
<DataTemplate x:Key="Screen1">
<uc:Screen1/>
</DataTemplate>
<DataTemplate x:Key="Screen2">
<uc:Screen2/>
</DataTemplate>
...
</Grid.Resources>
<TabControl Width="400" Height="400">
<TabItem Header="Screen 1">
<ContentPresenter ContentTemplate="{StaticResource Screen1}" />
</TabItem>
<TabItem Header="Screen 2">
<ContentPresenter ContentTemplate="{StaticResource Screen2}" />
</TabItem>
...
</TabControl>
</Grid>
- AdamJonsson
- Posts: 10
- Joined:
Who is online
Users browsing this forum: No registered users and 9 guests