First of all, I would like to remind you how you could create universal applications in Windows 8.1. A solution was created with three projects: for a phone, for Windows 8.1, and a project with common code. And how is it now in Windows 10? I'll tell you now.
This is how the universal application looked like in Windows 8.1
But then Windows 10 appeared and a reasonable question immediately arose:
What is this now to learn all over again?
')
Part of the small changes really are. But if you had a good understanding of universal projects of Windows 8.1, then everything will be familiar to you. Moreover added a certain flexibility.
Let's first consider which devices on the Windows UWP platform exist at the moment (on sale, in plans, or in a prototype):
The devices are grouped into separate families:
The diagram is dotted as the platform grows and the types of devices may become larger with time.
Now, instead of getting a solution with several projects for each device family, it’s enough to create a folder with the name of the family in its name. For example:
In this case, if the application is launched on a mobile device, the MainPage page from the DeviceFamily-Mobile folder will be displayed.
And note that if you create a page inside a folder called MainPage, then it will be created without the MainPage.xaml.cs code file.
It was the first way.
The second method is similar to the first one, but instead of creating a folder, the file name is added .DeviceFamily-Type
The third way is from codebehind.
If you compile the project and consider the MainPage.gics file, you can find an overload of the InitializeComponent method, which takes as a System.Uri resourceLocator parameter
public void InitializeComponent(global::System.Uri resourceLocator) { if (_contentLoaded) return; _contentLoaded = true; if (resourceLocator == null) { resourceLocator = new global::System.Uri("ms-appx:///MainPage.xaml"); } global::Windows.UI.Xaml.Application.LoadComponent(this, resourceLocator, global::Windows.UI.Xaml.Controls.Primitives.ComponentResourceLocation.Application); }
So in order to load the desired page, we can do this:
public MainPage() { if (Windows.System.Profile.AnalyticsInfo.VersionInfo.DeviceFamily=="Windows.Mobile") { InitializeComponent(new Uri("ms-appx:///MobileMainPage.xaml", UriKind.Absolute)); } else { InitializeComponent(); } }
In this case, if the application is launched on a mobile device, the MobileMainPage.xaml page will be loaded.
Now a little about how in C # code to determine which family of devices is being used at the moment. It's very easy to do this with this code:
if (String.Equals(Windows.System.Profile.AnalyticsInfo.VersionInfo.DeviceFamily, "Windows.Desktop")) {
If you want to use a specific device family API in your application, you can add a link to any of the UWP platform extensions.
A beaten example of using the device family API is checking for the presence of the hardware “Back” button on the phone (hardware Back button).
bool isHardwareButtonsAPIPresent = Windows.Foundation.Metadata.ApiInformation.IsTypePresent("Windows.Phone.UI.Input.HardwareButtons"); if (isHardwareButtonsAPIPresent) { Windows.Phone.UI.Input.HardwareButtons.CameraPressed += HardwareButtons_CameraPressed; } private void HardwareButtons_CameraPressed(object sender, Windows.Phone.UI.Input.CameraEventArgs e) {
For verification, use the isTypePresent method that is contained in the
Windows.Foundation.Metadata.ApiInformation class. This class also has other methods to check for the presence of available API features (events, properties ...)
Or here is a slightly less beaten example, which, if the statusbar is with the device, changes its color to chocolate:
if (Windows.Foundation.Metadata.ApiInformation.IsTypePresent("Windows.UI.ViewManagement.StatusBar")) { var statusBar = Windows.UI.ViewManagement.StatusBar.GetForCurrentView(); statusBar.BackgroundColor = Windows.UI.Colors.Chocolate; statusBar.BackgroundOpacity = 1; }
An example can be found on
github