Development of applications for the universal windows platform. Software platform concept. Storing application settings and working with files
Programmer's library
“It is very important not to interrupt the questions. Curiosity has its right to exist."
Albert Einstein
37. Windows family platforms
This section uses materials from the book: Jeffrey Richter. Windows for professionals (programming in Win32 API for Windows NT and Windows 95)/Trans. from English – M.: Publishing department "Russian Edition" LLP "Channel Traiding Ltd.", 1995. – 720s. (Original publication – 1995)
Win32 API interface. Windows operating systems of various versions offer developers application programs(for programmers) the so-called Win32 API (application programming interface). An API is a collection of functions that an application can access.
The Win32 API is implemented on three platforms: Win32s, Windows NT (Windows 2000) and Windows 95. Microsoft's original goal was to implement this interface (that is, all its functions) on all three platforms. In this case, an application developed for any platform could be ported to another platform quite simply: it would only need to be compiled again for the other platform. In reality, however, this dream was not fully realized, as a result of which there are quite significant differences between the three named platforms, which narrow the possibilities for transferring applications from one platform to another.
Win32s platform was the very first platform capable of running 32-bit applications. It consists of a set of dynamic link libraries (dll files) and a virtual device driver (virtual-device driver). This set is a complement to 16-bit Windows 3.x systems. Thus, Win32s is just an add-on to Windows 3.x. This add-in converts 32-bit function parameters to 16-bit and calls the corresponding Windows 3.x functions.
In Win32s, most Win32 functions are implemented simply as "stubs": when they are called, control returns without performing any action. For example, since 16-bit Windows does not support threads, the CreateThread function will return a null pointer. However, Win32s introduced some features that were not supported by Windows 3.x. These include, for example, memory-mapped files and structured exception handling.
The goal of Win32s was to encourage programmers to develop 32-bit applications so that by the time the Windows NT platform was released, 32-bit applications would already be on the market. This goal, unfortunately, was never achieved, as Win32s was not particularly successful.
Windows NT platform is a full-fledged operating system that supports Win32 functions to the fullest extent. It is a relatively new OS and is not weighed down by MS DOS. Microsoft Corporation is betting on this operating system. True, the Windows NT platform places high demands on hardware computer, primarily to the amount of RAM and hard drive.
The Windows NT platform has a number of advantages over the other two platforms.
First, 32-bit applications are native to it and can run most efficiently thanks to the Win32 API. Here it is also necessary to note the high stability of the platform in relation to inevitable failures in the operation of applications.
Secondly, Windows NT is capable of running (simultaneously) several different types of applications developed for MS DOS, OS/2, POSIX, Presentation Manager and Windows 3.x.
Thirdly, Windows NT is the only portable one of the platforms considered, i.e. it is capable of working on machines with different types processors. Since most Windows code NT is written in the C and C++ languages, then to transfer it to a computer with another (non-Intel) type of processor - MIPS R4000, DEC Alpha or Motorola PowerPC - it is enough to recompile source texts using a compiler that is native to the processor. Of course, in reality, switching to another type of computer is somewhat more complicated, since it requires rewriting two low-level components of the system: the kernel (Kernel) and the so-called hardware abstraction layer (HAL). These components are written primarily in the appropriate version of assembly language and are very specific to a particular processor. In order for applications written for Windows NT to run on another computer, all that remains is to recompile them.
Thus, if you plan to use the application you are developing on computers with different types of processors, then it must be developed for the Windows NT platform.
And finally, fourthly, Windows NT is the only platform discussed that can run on a multiprocessor computer and will actually take advantage of its unique capabilities. For example, if your computer has 30 processors, then Windows NT will actually allow up to 30 threads to run simultaneously. (Sequent has developed computer system with 30 Intel processors.)
Windows 95 platform is the latest operating system that fills a very large niche in the market for computers of the Intel 386 class and higher with 4 or more megabytes of RAM. The reason for the release of Windows 95 is precisely the excessively high Windows requirements NT to computer specifications.
In order for Windows 95 to run on machines with 4 MB of memory, Microsoft cut some features of the Win32 API. As a result, Windows 95 does not fully support some functions of the Win32 API, in particular, asynchronous file input/output, debugging, logging, security, etc. These functions are implemented, but not completely. However, Windows 95 supports most of the Win32 API functions and is the most popular platform.
Thus, of the three platforms discussed, only the Windows NT and Windows 95 platforms should be seriously considered at this time, since the Win32s platform does not actually support most of the Win32 API features.
There is one more difference to note in the Windows 95 and Windows NT platforms. In Windows 95, a number of new functions were added to the Win32 API to support modems, more accurate color reproduction, and other services. But Windows NT (at least version 3.5) does not have these functions at all. Therefore, when developing programs, you must keep in mind that some functions of the Win32 API exist on one platform and are completely absent on another. This is all the more unfortunate since the Windows NT platform should, according to Microsoft, support all the functions of the Win32 API.
A complete list of differences in the implementation of the Win32 platform in different versions of Windows can be found in the "Platform Differences" section of the ProgTech.hlp help file.
Windows NT 3.5 has built-in graphics capabilities 3D graphics OpenGL API. OpenGL is an operating system-independent, industry-standard graphics library developed by Silicon Graphics for its workstations. OpenGL is currently recognized by the Architecture Review Board, which includes firms such as DEC, IBM, Intel, Microsoft and Silicon Graphics. OpenGL technology has been licensed by Microsoft to provide this powerful 32-bit API Windows users N.T. The advanced functions of this library are required when visualization of large projects and data is required. Typical applications that require its use are CAD, mechanical and industrial design systems, statistical and scientific analysis programs.
Last update: 04/12/2017
UWP (Universal Windows Platform) is a unified platform for creating and running applications on Windows 10 and Windows 10 Mobile.
UWP was the result of a evolution of earlier technologies. Yes, with Windows release 8, a new architectural platform for applications was introduced - Windows Runtime (WinRT), which made it possible to run applications in the so-called Modern (Metro) mode on desktops and tablets. Then with the release of Windows 8.1 and Windows Phone 8.1, this technology was developed - “universal applications” appeared that could be launched immediately by Windows 8.1 and WP8.1. And in July 2015, the new Windows 10 OS was officially released. It uses the UWP platform, which is a Windows development Runtime.
As the name of the platform suggests, it is universal - universal for all devices in the Windows 10 ecosystem. And these are ordinary desktops, tablets, mobile devices, IoT devices (Internet of Things), Xbox, Surface Hub devices. And a UWP app can run equally on all these platforms as long as they have Windows 10 installed.
Why UWP?
Programming for UWP has a number of advantages:
Width of distribution. Currently (April 2017), Windows 10 is already installed on more than 400 million devices. On desktops, Windows 10 is already ahead of Windows 8/8.1.
Supports a wide range of devices. Desktops, tablets, smartphones, large Surface Hub tablets, various IoT devices, in the future HoloLens virtual reality devices - the range of devices on which Windows 10 can run is really wide.
Support for different programming languages and technologies. UWP applications can be created using languages such as Visual C++, C#, Visual Basic, JavaScript. As a technology to create GUI Visual C++, C# and Visual Basic use XAML, JavaScript uses HTML. Additionally, C++ can use DirectX instead of XAML. That is, technologies that are quite common and familiar to many.
App store and ease of distribution. The Windows Store is a great place to distribute UWP apps, both paid and free. The very capabilities of the platform and the Windows Store allow you to use different ways monetization. For example, you can integrate blocks for displaying advertisements into applications through various SDKs. Can be distributed for a fee, and the payment can be flexibly configured. If necessary, you can build in the provision of a trial version, after using which the user can decide whether to buy the application or not. And it can also be monetized using the freemium model, in which the application is shareware, and individual services within the application are provided for a certain fee. Moreover, all these monetization opportunities are provided by the built-in SDK tools.
Rich platform capabilities. UWP inherits a lot from the Windows Runtime of Windows 8.1 and at the same time provides many new functionality, such as richer cloud integration capabilities, the use of Cortana, the notification system in Win10 and much more.
What is needed to develop for UWP
To program for UWP, you need Windows 10. All other operating systems, like Windows 8.1/8/7, not to mention Windows XP, are not suitable!
You will also need a development environment Visual Studio 2017 Community. It is a fully featured free development environment that can be downloaded from the official website at https://www.visualstudio.com/downloads/download-visual-studio-vs.
You can also use the VS 2015 version, and all others previous versions Visual Studio - 2013, 2012, 2010, etc. They don't work with UWP.
At installing Visual Studio 2017 in the installer, you must check the appropriate box:
Before you start creating applications, make sure that the appropriate option for developers is installed in Windows 10 Update:
And having Windows 10 and Visual Studio 2017 installed, you can start developing applications.
So it’s quite possible to start getting acquainted with the new platform. Let me take a short excursion, describing some of the differences.
Let me start by saying that UWP apps have something that desktop Windows apps don't - they have an App Model. What is an App Model? This is a kind of regulation. Description of all the capabilities of the application - its access rights, installation method, update, information storage, etc.
Windows Store apps, just like UWP apps, have a manifest file that describes all the capabilities and permissions of the app. This is the Package.appxmanifest file. It can be edited either in a graphical editor or as XML code. Screenshot graphic editor see below.
Controls
If you remember, quite recently Windows 8 and 8.1 had a Charm panel - a magic panel:Now, instead of it, controls that are more familiar to WPF developers are used:
Here the new control is ContentDialog, which blocks the application in much the same way as MessageBox blocks it.
In addition, UWP has navigation that is more familiar to WP developers:
What may be interesting is that some controls may have different appearance when displayed on various devices. In simple words, the control may look slightly different, for example, when displayed on a desktop and on a mobile device.
In general, I believe that the average developer has long been accustomed to a wide variety of controls. Mastering new difficulties should not cause.
Development for various devices
I’ll try to figure out what would be unusual for a WPF developer. For example, this is the fact that when developing Windows 8.1 applications, it was possible to develop simultaneously for both a phone and a desktop in one solution.In this case, 3 projects were created. The WP and WinRT applications stored xaml code for “views” and some special code for devices, and the common project stored common xaml code and 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 a “view” - i.e. xaml file with a design for the device parameters.
Life cycle
There is an old joke about Formula 1: “Ralf Schumacher has two pedal positions - on and off. The remaining provisions can be neglected."With this joke I can poke some fun at classic .Net applications. They either work or they don't work. In Store apps, things are a little different. In addition to the “On/Off” states, they also have an intermediate “Suspended” state. Life cycle 8.x and UWP applications are shown in the following picture:
Triggers and background jobs
.Net applications can either be executable files or can be services/services. This is absolutely different types applications. That is, it cannot be that the application is exe, but at the same time it is running in the background. No, of course, the application can run in the tray. But in fact it turns out that it is running and simply minimized.As for 8.x and UWP applications, they may contain background jobs. Background jobs This is some semblance of a service. That is, the application may not work, but some task will be performed on the system. In addition, a background task can “catch” some events in the system using a trigger.
One of the most popular triggers is SystemTrigger. Using it, the application can execute any code upon the occurrence of such events as: the appearance or loss of the Internet, a change in the network state, a user connecting or disconnecting, receiving an SMS, changing the time zone, etc.
Also quite popular TimeTrigger And MaintenanceTrigger. Both triggers execute some code periodically within a certain period of time. The time period must be at least 15 minutes. The difference is that TimeTrigger requires the application to be registered on the lock screen, while MaintenanceTrigger requires the device to operate on mains power rather than battery power.
There are many new triggers in UWP. Take, for example, such an interesting trigger as MediaProcessingTrigger, which allows an application to transcode media as part of a background task.
Using Libraries
If in desktop apps you used DLLs, then in 8.x and UWP apps 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 Xamarin applications. That is, you can push some general platform-independent code into this library.
WinMD can only be used under 8.x or UWP. Regardless of the language in which applications are written, they can work with WinMD. But WinMD itself, if it contains complex calculations, is better written in C++ to achieve the best performance.
However, when developing for UWP, you can also create a class library (DLL).
Working with data
Another thing that's different about UWP apps is that they don't work directly with databases. 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 from Store app, and the application would start working with the SQL Server database located on the server in local network. But you can work with data using web services. It is possible to use Oracle Connector/Net for MySQL databases, but it is not at the moment 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.To store information within an application, you can use SQLite.
Storing application settings and working with files
Storing application settings is possible not only on the device, but also in the cloud. Thus, if you run the application on different devices, the settings will be the same everywhere.The following small snippet saves 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 setting will be saved locally on the device.
Settings can be arranged both into complex parameters and into containers. Files, just like settings, can be stored on the device in 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 it is necessary to set permissions in the manifest. Access to any other folder is possible only if the user selects the folder himself while working with the application. Visited folders can be saved so that when the application is restarted, the user does not have 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 like this:
String mruFirstToken = StorageApplicationPermissions.MostRecentlyUsedList.Entries.FirstOrDefault().Token; lastFolder = await StorageApplicationPermissions.MostRecentlyUsedList.GetFolderAsync(mruFirstToken);
Data bindings
In both WPF and UWP applications, as well as when developing under 8.x, you can use data bindings. But UWP also introduced compiled bindings – (x:bind) What’s the difference? Compiled ones work much faster, and they are formed/checked during compilation and not during application launch. They are also strongly typed.Read more here.
Dear Khabra residents!
I would like to tell you in more detail about one of the most interesting innovations in my opinion. We will talk about the simultaneous development of applications for Windows 8 and Windows Phone, i.e. about universal applications for the Windows platform.
The Microsoft platform covers a wide range of devices - from smartphones and tablets to desktop computers And game console Xbox One, and it is quite natural that the developer wants to minimize the effort when creating applications for all form factors. On competing platforms there is a huge difference between desktop and mobile apps (as they run different operating systems), while mobile applications, designed for a smartphone, can work on tablet devices, which often leads to user dissatisfaction due to a not very high-quality user interface.
At the moment, Microsoft has come close to unifying all platforms (Windows Phone, Windows 8, Xbox One) in terms of API, and allowing the programmer to make maximum use of the common code when creating applications, while maintaining the ability to use various designs for various form factors. Read more about how this is currently implemented - below.
How were they created before? Windows applications+Phone
Until now, to create apps that shared code between Windows and Windows Phone, you had to use a shared portable library to separate out the common code responsible for data access and business logic, and different designs for the UI. This approach is described in more detail in a special course on Microsoft Virtual Academy, or. Also, due to the difference in the API of Windows 8 and Windows Phone, some of the code had to be made platform-dependent.Universal Windows Apps
The following innovations were announced at the build conference:- IN new version Windows Phone 8.1 will use Windows RT API This means that about 90% system calls between Windows 8.1 and Windows Phone 8.1 will be common. Additionally, the XAML markup language has also been unified across platforms. In other words, new Windows Phone 8.1 apps will use Windows XAML, not Silverlight. If you need compatibility, you can still develop for Windows Phone using Silverlight, incl. using new opportunities, but this is a topic for a separate article.
- Coming to Visual Studio 2013 Update 2 new template project for unified Windows applications. This template creates different projects for Windows and Phone, and a third "shared" project that houses all the shared code. In this case, the shared project
may contain not only code, but also XAML markup, shares, images, etc. This project is not compiled into a separate library, but is split between the two platform projects at the text inclusion level at compilation time. This template can be used for development in C#/XAML, C++/XAML or HTML/JS. - If you want to separate some platform-independent code into a separate library shared between multiple applications, you can still use a portable library that can now also include XAML markup. Portable libraries can be used for development in C# or Visual Basic.
- There is no binary compatibility between platforms yet, i.e. Windows 8 and Windows Phone apps will still be distributed through their respective stores, and the developer will need to create and upload app packages to each store (although Windows Phone 8.1 will now use the same .appx format as Windows 8. However Windows and Windows Phone stores will use common app identifiers, which will allow you to implement scenarios single app purchase for use on all platforms.
- Xbox One apps in the current version of Visual Studio Update 2 do not fit so well into the overall story, although it was shown at the plenary talk Universal Khan Academy app using Kinect, running on Xbox and Windows(yes, Kinect v2 will be supported in Windows Store applications, but again this is a topic for another article). Development for Xbox One is currently expected to be in HTML/JS/CSS and C++
Universal Hello World
Let's look at a small example of creating a universal application. The project structure in Visual Studio 2013 Update 2 has been redesigned to include both Windows and Windows Phone apps, as well as universal apps and libraries, in the Window Store.The newly created universal application will be designed for the Windows Phone 8.1 platform and Windows 8.1 Update. At the same time, Windows Phone project templates based on Silverlight are available in the Windows Phone application section, which will allow you to create applications for earlier versions platforms - but the capabilities of universal applications cannot be used.
After creating an empty universal application, we will have the following structure, consisting of three projects: one project for each platform and a common shared project:
Please note:
- By default, page design (XAML) for platforms is divided into different projects. However, in simple cases, you can use common XAML files for all platforms if you are confident that your design will adapt well enough to different resolutions, from smartphone to desktop. However, many built-in controls (for example, GridView) can adapt and change their appearance depending on the platform.
- If you already have finished project Windows or Windows Phone, you can create a universal application based on it by selecting context menu project corresponding item. This will convert the project into the same three-project structure, and you will be able to move application files into a common project for sharing.
- You can include links to libraries (References) in the shared project, and these links will be added to both projects (we see that there is a Shared link in the links of each of the platform projects). If some libraries are available only for one of the platforms, then we can still use the corresponding functionality in the general code, surrounding it with #ifdef conditional compilation directives. Visual Studio is so convenient that Intellisense will work, warning us that the link is only available on one of the platforms.
- If we bring the XAML code into a common project, then a drop-down is available in the XAML editor to switch the platform, and we can visually edit the page design both in phone mode and in tablet/desktop mode.
In most cases, you will want to share as much code as possible between platforms, moving everything possible into a shared project. In our case, we can move MainPage.xaml from one of the projects to the shared project, and delete it in platform projects, since in our case the page design will not differ from platform to platform:
Thus, we have a universal application, the code and design of which is entirely in the shared project.
On the way to real application- Photo Viewer
Let's try to turn our Hello World application into something useful - for example, into a viewer best photos flickr. Flickr provides an RSS feed of photos, so identifying the appropriate data source is relatively easy (for simplicity, RSS loading is made non-asynchronous; in real projects this should not be done):Code for getting images from Flickr
public class Flickr ( List
On the main page we use a GridView bound to this data source. In order for photos to be available on different platforms different sizes, we use the key from the resource file that determines the required photo size.
XAML design of the main application page
To set different parameters in the resource file, we will create in each of the platform projects its own resource file Resource.xaml with the following content:
And finally, we need to include this resource file in App.xaml (which is in the shared project):
App.xaml
As a result, we get a pair of applications for Windows 8 and Windows Phone that correctly display the image gallery, taking into account the specifics of the platform.
The complete source code for the application can be obtained on github.
Morality
To create new applications on the Windows 8 platform now the best solution will use universal applications. If you have an existing Windows 8 application, then it makes sense to slowly convert it into a universal application and port it to Windows Phone 8.1. Existing Windows Phone 8 applications are more difficult to convert into a universal application (because a number of operations use different sets of APIs), we will talk about this later. Finally, universal Windows Phone apps require Windows versions Phone 8.1, so at the moment, in order to have a fairly wide install base, it makes sense to use Silvelight 8.0 applicationsoperating room Windows system Core OS is the future foundation of Windows and a historic step forward in making Windows 10 a true universal OS.
In a nutshell, Windows Core OS (abbreviated as WCOS) is a cross-platform glue for Windows that allows the use of any device or architecture, enhanced by modular extensions that can enable the necessary features on the devices.
The “Andromeda OS” project is now called “Windows Core OS” in dedicated circles
Its main goal is to make Windows 10 much more flexible and compatible with a large number devices without being tied to certain previously developed product options. As a result, Windows will become “smaller” (depending on the device), the OS itself will be developed faster, and devices will not be oversaturated with components and functions that are no longer relevant. Overall performance and speed of operations on smaller or weaker devices will increase.
What does this mean for the user?
Today's Windows 10 comes in several flavors (for example, there are versions for desktop PCs and for mobile devices), not being the only OS for all devices. However, these versions share common elements such as OneCore and the Universal Windows Platform, so WCOS is intended to replace these variations with the Universal Platform.
WCOS opens the door to many new Windows configurations. Of course, Windows 10 desktop OSes like Pro and Enterprise will continue to exist, providing the full functionality and features of a desktop OS.
The initial implementation of WCOS is expected to be developed in 2018 and, most likely, will be focused on the mobile segment.
The next step is to prepare WCOS for desktop computers and devices like Xbox. WCOS and the collaboration between Microsoft and CShell are helping the corporation make a big leap towards the "One Windows" concept. The first universal Windows components 10 had OneCore and the Universal Windows Platform. Now Microsoft is moving further in this direction with WCOS and CShell.
The future of Windows
WCOS will be a boost Windows startup on modern mobile devices and will make it compatible with innovative devices that may see the world in the next few years. Microsoft needs an OS that is flexible, configurable, and responsive, which Windows currently isn't. WCOS will fix this.
Important: WCOS is not intended to be a direct-to-consumer product and will not be publicly sold by Microsoft. This is an internal platform that allows you to create versions of Windows 10 that were previously unrealistic. But as always, Microsoft could cancel or delay its WCOS plans at any time.