About UWP Apps for WPF Developers

I would like to code WPF developers from the fear of something new, talking about the differences that await them when developing applications for the universal Windows platform. So put the banks in front of the monitor, I begin to give the installation.

Some changes in programming languages ​​and platforms occur constantly. Imagine for a moment that C # version 10 comes out and that's it. This is the latest version. Submitted? I imagined. And in my view, if it ever happens, this latest version of the language will be updated regularly.

There were “wonderful” times when my eyes slightly diverged from the differences in the code (even in the XAML code): WPF, Silverlight, Windows Phone, then WinRT, and now also UWP. How many developers are never confused? I think most developers don't keep everything in mind. It is enough to keep in mind the basic concepts of work. When it comes to coding, auxiliary tools like IntelliSense, Blend, etc. are used. Nowhere to get away from using snippets.

What are the reasons for the changes:
')
1. A harmful uncle is sitting somewhere, who is waiting for the moment when everyone will get used to the platform / development environment. And then he changes something.
2. Improvements / new functionality.
3. User or developer feedback (I didn't like it and that's it). Error correction.
4. The hardware is being improved. Emphasis on energy saving, on performance or on beautiful effects.
5. Something global. For example, the latest integration of platforms in UWP or something like "We want C # to be written for all platforms at once, bypassing Xamarin, so they added you new controls similar to other platforms". Who knows, maybe in a few years there will be such.
6. Write your version in the comments.

Why do developers need knowledge of UWP? Yes, at least due to the fact that in .Net applications it will be possible to soon use the API and services of UWP. All this may soon become possible with the help of Project Cenntenial .

So it is possible to begin to get acquainted with the new platform. Let me do a little digression, describing some of the differences.

To begin with, UWP applications have something that classic Windows applications don't have — they have an App Model. What is an App Model? This is a kind of time limit. Description of all features of the application - its access rights, method of installation, updating, storing information, etc.

Windows Store apps, just like UWP apps, have a manifest file that describes all the features and rights of the app. This is the Package.appxmanifest file. It can be edited both in a graphic editor, and in the form of XML code. Screenshot graphics editor, see below.

Controls

If you remember, recently Windows 8 and 8.1 had a Charm panel - a magic socket:



Now, instead of it, more familiar controls for WPF developers are used:



Here, the new control is ContentDialog, which blocks the application, much like the MessageBox blocks it.
In addition, the UWP is more familiar to WP developers:



What may seem interesting is that some controls may have a different appearance when displayed on different devices. In simple words, the control may look a little different, for example, when displayed on the desktop and on a mobile device.

In general, I suppose, the average developer has long been accustomed to a wide variety of controls. Mastering new difficulties should not cause.

Development for various devices

I will try to make out that for WPF developer will be unusual. For example, this is what, when developing applications for Windows 8.1, it was possible in one solution to develop simultaneously both for a phone and for a desktop.



In this case, created 3 projects. In the WP and WinRT applications, the xaml code of the "views" and some special code for the devices were stored, and in the general project the common code xaml and the common for two projects code C # were stored.

Now, since the UWP platform is universal, for each type of device you can create a folder in which you can put a “view” - i.e. xaml design file for device parameters.

Read more here:
3 ways to set markup for different devices in C # / XAML Windows UWP applications

Life cycle

There is an old joke about Formula 1: “Ralph Schumacher has two pedal positions - on and off. The remaining provisions can be neglected. "

With this joke, I can add some classic .Net apps. They either work or do not work. In Store applications, things are a little different. In addition to the on / off states, they also have an intermediate state “Suspended”. The life cycle of applications 8.x and UWP is displayed in the following picture:



Read more here:
Application Lifecycle in Windows 8.1 and UWP

Triggers and background jobs

.Net applications can be either executable files or can be services / services. These are completely different types of applications. That is, there can be no such thing as an exe application, but at the same time it works in the background. No, of course, the application can work in the tray. But in fact, it turns out that it is running and simply collapsed.

As for applications 8.x and UWP, they can contain background tasks. Background jobs are some kind of service. That is, the application may not work, but some task will be performed in the system. In addition, the background task can “catch” some events in the system operation with a trigger.

One of the most popular triggers is SystemTrigger . Using it, an application can execute any code when events such as: the appearance or disappearance of the Internet, a change in the network state, the connection or disconnection of a user, receiving SMS, changing the time zone, etc. occur.

TimeTrigger and MaintenanceTrigger are also quite popular. Both triggers perform any code at intervals for a certain period of time. The time interval must be at least 15 minutes. The difference is that TimeTrigger requires registration of the application on the lock screen, and MaintenanceTrigger requires the device to work not from the battery, but from the network.

There are many new triggers in UWP. Take, for example, such an interesting trigger as MediaProcessingTrigger , which allows an application to transcode multimedia as part of a background task.

Use of libraries

If you used DLLs in classic applications, you can use both PCL and WinMD runtime components in applications 8.x and UWP. What's the Difference?

PCL (portable class library) can be added to applications for different platforms. And under the .Net Framework of various versions, and under Windows 8.x and under WP, under UWP and even under iOS / Android applications Xamarin. That is, you can stuff some common platform-independent code into this library.

WinMD can only be used under 8.x or UWP. Regardless of the language in which the applications are written, they can work with WinMD. But WinMD itself, if it contains complex calculations, is better to write in C ++ to achieve the best performance.

However, when developing for UWP, you can create a class library (DLL).

Work with data

What else is different about UWP applications is that they do not work directly with databases. That is, such databases as, say, SQL Server or Oracle, located on the server of the organization, will be inaccessible to you. However, it would be strange if the user downloaded the application from the Store, and the application would start working with the SQL Server database located on the server on the local network. But you can work with data using web services. It is possible to use Connector / Net for MySQL databases, but at the moment it does not support SSL and therefore is not particularly interesting. So it is better not to deviate from the concept of using services to access data.

You can use SQLite to store information inside the application.

Storing application settings and working with files

Storage of application parameters is possible not only on the device, but also in the cloud. Thus, if you run the application on different devices, then the settings will be the same everywhere.

The following small snippet saves the amount of code calling in the cloud:

int timescount = 0; Object roamS = Windows.Storage.ApplicationData.Current.RoamingSettings.Values["times"]; if (roamS != null) timescount = (int)roamS; timescount++; Windows.Storage.ApplicationData.Current.RoamingSettings.Values["times"] = timescount; 

If you replace Windows.Storage.ApplicationData.Current.RoamingSettings with Windows.Storage.ApplicationData.Current.LocalSettings, the parameter will be saved locally on the device.

Settings can be arranged both in compound parameters and in containers. Files in the same way as the settings can be stored both on the device in a local folder and in the cloud. But besides this, it is possible to store files in a temporary folder, which if necessary can be cleared by the system - ApplicationData.TemporaryFolder .

In addition, you can access the folder that is contained in the application using
Windows.ApplicationModel.Package.Current.InstalledLocation

Access to files stored on disks is also organized according to a special model. The contents of document folders, photos, videos and the like can be obtained using the KnownFolders class, but in this case, you need to set permissions in the manifest. Access to any other folder is possible only if the user selects the folder itself while working with the application. Visited folders can be saved, so that when you restart the application, do not force the user to do unnecessary actions

  var folderPicker = new Windows.Storage.Pickers.FolderPicker(); folderPicker.FileTypeFilter.Add(".jpg"); folderPicker.FileTypeFilter.Add(".jpeg"); folderPicker.FileTypeFilter.Add(".png"); folderPicker.SuggestedStartLocation = Windows.Storage.Pickers.PickerLocationId.PicturesLibrary; folderPicker.SettingsIdentifier = "picker2"; Windows.Storage.StorageFolder lastFolder = await folderPicker.PickSingleFolderAsync(); if (lastFolder == null) return; String mruToken = Windows.Storage.AccessCache.StorageApplicationPermissions.MostRecentlyUsedList.Add(lastFolder); 

After this you can get the last saved folder as follows:

 String mruFirstToken = StorageApplicationPermissions.MostRecentlyUsedList.Entries.FirstOrDefault().Token; lastFolder = await StorageApplicationPermissions.MostRecentlyUsedList.GetFolderAsync(mruFirstToken); 

Data bindings

Both in WPF and UWP applications, as well as in development for 8.x, you can use data binding - {binding}. But compiled bindings also appeared in UWP - {x: bind} What is the difference? Compiles work much faster, and they are generated / checked at compile time and not at the time of application launch. They are also strongly typed.

Read more here:
Compiled data bindings in Windows 10 applications

Effective pixels

By creating a UWP application, you are developing in effective pixels, not physical ones. A special scaling algorithm allows you to ensure that the font size of 24 pixels will be equally readable on both the large PC screen and the phone screen.



Thus, it turns out that the developer may not care about the pixel density on different devices or the viewing distance. But he has to make sure that on high-resolution devices the images look good. Let's look at the Assets folder of the standard universal application you just created:



You may notice that some images have a postfix .scale-200. This means that the scaling size is set to 200. For example, take the file Square44x44Logo.scale-200.png - its physical size is 88x88 pixels. That is a scale of 200%. All available options are 100, 125, 150, 200, 250, 300, 400.

Example: if you want to create an image variant for devices with a scaling factor of 150, then you need to create an image of size 66x66 and name it Square44x44Logo.scale-150.png.

This concerns not only the images used in the application description, but also the images that you use in the UI.

Conclusion

In fact, all the new UWP features are listed for quite some time (you can mention Adaptive triggers, Splitview, Ink, Map, etc.). I hope that I was able in a short article to talk about both the key differences and some similarities with WPF.