What is the difference between <common:LayoutAwarePage and <UserControl... in XAML in Windows 8. Looks like both are used as W8 pages.
A Page is what you need to use inside of a Frame to support the standard navigation framework and the standard AppBar class. LayoutAwarePage adds support for different visual states depending on layout (portrait, landscape full/filled/snapped), which really is required when you are building an app to submit to the store.
A UserControl is just a simple way to group some UI pieces and code-behind together useful especially if you want to have a reusable piece of UI that shows up on different pages or if your page design becomes too complicated (eg. if you have a lot of XAML for different page layouts). It is also useful if you want to create a common control to be reused in multiple places or multiple projects, but don't care about being able to restyle it - then you would need to create a custom/templated control.
layoutawarepage are page that allow supports for the various view such as filled, snapped, portrait and landscape. in which you would have to handle the visualstatemanager in xaml and do the switching from various view in codebehind.
while usercontrol are elements that you can place in other pages.
Related
I am new to UWP app development and want to understand how xaml control is rendered in the UWP application. Which is the class that implements the rendering logic? And is that code open source? Also, when I create a new custom control, do I need to take care of rendering myself?
How is xaml control rendered in UWP application?
This is a big topic, for understanding this, we need to know UI Framework Layering. Windows.UI.XAML-> Windows.UI.Composition-> DirectX Family.
Derive from official document, The Visual layer provides a high performance, retained-mode API for graphics, effects and animations, and is the foundation for all UI across Windows devices. You define your UI in a declarative manner and the Visual layer relies on graphics hardware acceleration to ensure your content, effects and animations are rendered in a smooth, glitch-free manner independent of the app's UI thread.
And is that code open source?
Currently, the UWP open source controls are WinUI. You could find the base custom control build logic.
do I need to take care of rendering myself
The rendering is very low level, if you just custom control that inherit Control class, you have no need to care about the rendering process, you just need to build the interface in the target templated style. and add specific dependency property in the code behind. For more detail please refer to Templated Control document.
I have been trying to create a Xamarin Forms App using Prism that works on both phones and tablets.
For the tablet layout I'm trying to create something similar to the draft image below while still reusing the Pages/ViewModels from the phone.
What I have tried:
Using a TabbedPage where each Tab contains a MasterDetailPage. There are two issues with this solution:
Xamarin only recommends using a MasterDetailPage as the root page
I managed to implement this "solution" but probably due to the reason above the xaml of the pages inside the MasterDetailPage don't bind correctly to their ViewModels.
Using a TabbedPage in which each Tab contains a Page divided in two parts which have a ContentView:
This solution works, but I can't reuse the Page from the Phone version directly on the layout.
I did try using Prism Partial Views to implement this solution, but I think the parent Page needs to contain the ViewModel that is going to be used by the ContentView which wouldn't work in this scenario (because it's going to contain two View Models).
Not sharing the Pages/ContentViews/ViewModels between phone and tablet:
This solution works, because I can implement the MasterDetailPage with ContentViews but there's is no code being shared for pages/views that basically do exactly same thing so it's really not ideal.
Any idea on how I can implement this layout while still sharing the Views and View Models between the Phone and Tablet implementations?
Note: This app is for Android, iOS and UWP using Xamarin Forms 3.4 and Prism 7.1
I would like to create a simple wizard based on a TabControl in Avalonia UI with four pages. Each page with a few controls. Instead of the TabItem headers I would like to create my own buttons and hide the default TabItem headers.
There are plenty of solutions for WPF, mostly involving ItemsContainerStyle and the Visibility property, both of which don't seem to be accessible in the Avalonia TabControle.
Is there any way to hide the headers?
Or is there a better way to implement a wizard?
You probably need to use the Carousel class directly. It's used by the TabControl internally for presenting the current item.
See example usage here:
https://github.com/AvaloniaUI/Avalonia/blob/master/samples/ControlCatalog/Pages/CarouselPage.xaml - markup
https://github.com/AvaloniaUI/Avalonia/blob/master/samples/ControlCatalog/Pages/CarouselPage.xaml.cs - codebehind
I am trying to implement a layout like the one in the MSN News app on my app for Windows 10
I want to replicate a menu like the one that says "All, Top Stories, US" and such. I have tried ListBox, AppBar and CommandBar and nothing seems to resemble this layout. Which controller should I use?
Check out the Pivot control. You can find out what elements any UWP XAML apps are made of by debugging them with VS and using the Live Visual Tree view.
Making first windows store app and need to have some controls show up at the top and bottom of every screen. When I did some WPF dev, I created a usercontrol and added it to every page. How is this done in windows store apps?
More specifically the header has a company logo and a status icon that changes based on an external resource (idle -> running, etc). The footer is where navigation happens in a somewhat linear fashion. Also, the footer displays the date and current time that continues to update. with the content in the middle changing based on what is selected in the footer.
There are a couple of different ways to do this. It really matters on whether you need it to be the same control (same instance) or if it is just a header/footer control which is added to each page and changes based on what you put into it.
Firstly, if this is something that can be incorporated into a CommandBar, that's the first thing I suggest you try. Then you can just create a StaticResource for each CommandBar, styled in the way you want for the header and footer. When you declare each page, in the root declaration, just set:
Page.TopAppBar="{StaticResource MyHeader}"
Page.BottomAppBar="{StaticResource MyFooter}"
You can make them Sticky and style them in any way that you would prefer, including having a collapsed version with just an ellipsis (...) to hide/show it. You can store all of the data for them inside of their own ViewModels, and have the control's DataContext just bind directly to the VM so that each instantiation pulls from the same data.
If it's not something that can be incorporated into a type of CommandBar, then I suggest you create your own Page subclass. The Template for it will wrap its ContentPresenter in your custom Header and Footer objects, likely in a Grid panel. This way will create a new copy of them each time, so they'll still need to bind to a ViewModel.
The final option that I see is to create a parent Page which has, similar to the subclass method, your header and footer wrapping the content. This time though, have them wrap a Frame. Then, all you have to do is call Frame.Navigate on that Frameand the header/footer controls will not be recreated, only the content in between them.
You can see something similar to this done in most of the Windows 8/8.1 app samples. They create a Content Frame, then navigate that through each page of the sample, generally on a selection from a navigation ListBox.
If you add a bit more information, I can try and tailor the answer a bit and provide some more specificity, but these are the general ways that I can see for you to accomplish what you have described.
Update:
Based on what you've said, to me it seems like the easiest thing to do would be to go with the third option, a Page wrapping a Frame. I suggest this because then it makes it quite easy for the bottom bar to affect navigation, and it sounds like you don't want the header or footer to be affected by page transitions.
If you check out the official ListView sample, you'll note their main page is declared something like this:
<Page
...>
<Grid Background="{ThemeResource ApplicationPageBackgroundThemeBrush}">
<!-- Navigation and other stuff -->
<Frame Grid.Column="1" x:Name="ScenarioFrame" Margin="30,50,30,0" />
</Grid>
</Page>
This is your basic main page declaration. You can then declare three Rows, one for your header, one for your Content, and one for your footer. If you want the footer to pop in and out, you can totally build the footer you have described into a CommandBar and include it on this page. Whenever you need to Navigate, just call ScenarioFrame.Navigate from your code-behind. You can now create Pages like normal, and Navigate to them like you would any other app.
This should also be 'Universal', so you should be able to include it in a Universal app, so long as you make sure your footer scales to the size of the screen (which you should already do). If you do try this, make sure that your navigation code in your main page is as generic as possible and the majority of the 'specialty navigation', such as Panes and settings are handled each platform-specific page, or at least via messaging (such as that provided by MvvmLight) and a NavigationHelper class.
Hope this helps and happy coding!