About UWP Applications for WPF Developers

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

Some changes in programming languages ​​and platforms are ongoing. Imagine for a moment that C # version 10 will be released and that’s it. This is the latest version. Presented? I imagined. And in my opinion, if this ever happens, then this latest version of the language will be regularly updated.

There were “wonderful” times when my eyes widened a bit from 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 that most developers do not 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. Do not go anywhere and from the use of snippets.

For what reasons the changes are happening:

1. A harmful uncle is sitting somewhere, waiting for the moment when everyone gets used to the development platform / environment. And then he changes something.
2. Improvements / new functionality.
3. Feedback from users or developers (I did not like it and that's it). Error correction.
4. The hardware is being improved. Emphasis on energy saving, performance or beautiful effects.
5. Something global. For example, the last platform unification in UWP or something like "We want C # to write to all platforms at once, bypassing Xamarin, so we added new controls similar to other platforms." Who knows, maybe in a few years there will be such.
6. Write your option in the comments.

Why do developers need knowledge of UWP? Yes, if only because in .Net applications it will be possible to use API and UWP services in the near future. All of this may soon be possible with Project Cenntenial .

So it’s quite possible to start getting acquainted with the new platform. Let me take a short excursion 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 regulation. Description of all the features of the application - its access rights, method of installation, updating, storage of information, etc.

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

Controls

Если вы помните, то совсем недавно у Windows 8 и 8.1 была Charm panel – волшебная панелька:



Сейчас же вместо нее используются более привычные для WPF разработчиков контролы:



Здесь новым контролом является ContentDialog, который блокирует приложение, примерно так же, как блокирует его MessageBox.
Кроме того в UWP более привычная для разработчиков WP навигация:



Что может показаться интересным, так это то, что некоторые элементы управления могут иметь различный внешний вид при отображении на различных устройствах. Простыми словами, контрол может выглядеть немного иначе, например, при отображении на десктопе и на мобильном устройстве.

В целом, я так полагаю, среднестатистический разработчик уже давно привык большому разнообразию контролов. Освоение новых трудностей вызвать не должно.

Development for various devices

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



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

Now, since the UWP platform is universal, for each type of device you can create a folder in which you can place the "view" - that is, xaml file with design for device parameters.

More details here:
3 ways to set markup for various 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 pin up the classic .Net apps a bit. They either work or don't work. Store apps are a little different. In addition to the “On / Off” states, they also have an intermediate state “Suspended”. The life cycle of 8.x and UWP applications is shown in the following picture:



More details here:
Application Lifecycle in Windows 8.1 and UWP applications

Triggers and Background Jobs

.Net applications can be either executable files or they can be services. These are completely different types of applications. That is, it cannot be that the exe application, but at the same time it works in the background. No, of course, the application can work in tray. But in fact it turns out that it is running and just minimized.

As for the 8.x and UWP applications, they can contain background jobs. Background jobs are a bit of a 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’s operation as a trigger.

One of the most popular triggers is SystemTrigger.. Using it, the application can execute any code upon the occurrence of events such as: the appearance or loss of the Internet, changing the state of the network, connecting or disconnecting the user, receiving SMS, changing the time zone, etc. TimeTrigger and MaintenanceTrigger are

also quite popular . Both triggers execute any code at intervals in a certain period of time. The time interval must be at least 15 minutes. The difference is that TimeTrigger requires registering the application on the lock screen, and MaintenanceTrigger requires the device to work not from the battery, but from the network. UWP has a lot of new triggers. Take, for example, such an interesting trigger as MediaProcessingTrigger

, which allows the application to transcode multimedia as part of a background task.

Using libraries

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

PCL (portable class library) can be added to applications for various 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, some common platform-independent code can be pushed 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 is the difference between UWP applications is that they do not work with databases directly. That is, databases such as, say, SQL Server or Oracle, located on the organization’s server, will not be available 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 the Oracle Connector / Net for MySQL databases, but it currently does not support SSL and therefore is not particularly interesting. So it’s 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 various devices, then the settings will be the same everywhere.

The following small snippet stores the number of code calls 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 combined into both composite parameters and 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 .

Additionally, 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 folders of documents, photos, videos and the like can be obtained using the KnownFolders class, but in this case, setting permissions in the manifest is necessary. Access to any other folder is possible only if the user selects the folder himself while working with the application. The 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 that, you can get the last saved folder like this:

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

Data bindings

Both in WPF applications and in UWP applications, as well as in development for 8.x, you can use data bindings {binding}. But compiled bindings also appeared in UWP - {x: bind} What is the difference? Compiled ones work much faster, but they are formed / checked during compilation and not during 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 is 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 various devices or viewing distance. But he must make sure that on devices with high resolution images look good. Let's look at the Assets folder of the standard just-created universal application:



You may notice that some images have a .scale-200 postfix. 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 go to create an image option for devices with a zoom factor of 150, then you need to create an image of size 66x66 and name it Square44x44Logo.scale-150. png.

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

Conclusion

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