Lately I’ve been spending a lot of time thinking about my career and where it’s going. I don’t want to give the impression that I have never thought about my career before, but now the thoughts are becoming constant.
Windows has been a cornerstone of the PC industry for decades now. From MS DOS to Windows 10, the market share has been dominated by the Windows OS (90.82% PC Source:newmarketshare.com, 2016-04-06). With all the new devices being released, there is a need for a platform that can simplify the development time so that individual apps don't have to be created for each and every device. The platform should also not be heavy (unlike the .NET Framework). It must be a smaller modular framework. Here comes the Universal Windows Platform (UWP).
UWP attempts to do this by creating a core foundation that can run all Windows Devices called the Windows Runtime. Of course each device can have specialized APIs (like a PC can use the full .NET Framework). This poses some great benefits to us when we start working in the IoT (Internet of Things) world. With the Windows 10 IoT Core, we can take advantage of the UWP on Raspberry Pis, Arduino, etc.
This article will give the basics of the UWP, the disadvantages as of today, and how to create a project in VS 2015.
The reference at the top of the post links to the official guide to UWP. This is definitely a better explanation of the platform that I can ever post here. But I will give a summary.
The UWP is based on device families. With the advent of more and more devices with different input modalities and form factors, a need arose to be able to program against different ones. A device family comes in the form of "device types" if you will.
These "device types" include Mobile, PC/Desktop/Laptop, XBox, IoT, etc. Each device inherently works with the core WinRT (Windows Runtime) without any worries whatsoever. But they also add their own unique capabilities. Device APis may not work on all other UWP enabled devices, which is ok. My Raspberry Pi may not be able to make a call and thus shouldn't have that Api available.
When creating a new app, it is up to you to target the device families you wish to run your app on. If you target the Universal Device Family, you can (in theory) run the app on any Windows 10 Device. However, you can narrow your scope by selecting only the devices you wish to work with. Then only the common Apis will be available between them.
In coding, there is the idea of adaptive code that can dynamically detect and use features of a device when they are available outside the universal device family. Performing conditional coding can be done regardless of the app or device you target. The reason for selecting devices is so that when you code, the apis are available unconditionally without any other special guards in place.
The UI element of UWP is not unique. We can use various technologies including XAML and HTML to develop the front-end. If you are using XAML, there are adaptive panels including the RelativePanel which can help when working with changing layouts (landscape vs Portrait vs Desktop). There are ways you can scale the content based on teh device and platform. This will be discussed in future posts.
Lastly, input handling is done a bit differently with new classes including the PointerPoint, PointerDevice, CoreIndependentInputSource and InkCanvas classes. There are more but these are the core classes that allow unified capabilities. For example, the PointPoint unifies raw touch, mouse and pen data into a consistent interface of events. The PointerDevice can be used to determine the actual device in use.
So let's go through a basic example of creating a shell of a UWP Application. It will do nothing by show a UI window and will be the basis of all apps in the future.
C++ Universal Windows Application
C# Universal Windows Application
Visual Basic (VB) Universal Windows Application
The project template provides you with a few files that you should understand.
The App.xaml code behind is where we reference the MainPage class. This can be changed by locating the typeof(MainPage). Optional of course if you like the naming
The package.appxmanifest can be viewed in the UI Mode or the XML Mode. If you right-click the file and click 'View Code' you can see the XML. Let's look at the UI first
Manifest UI: Application Tab
There are several tabs in the UI: Application, Visual Assets, Capabilities, Declarations, Content URIs and Packaging. The ones I care about the most is the Application and Capabilities. The Application tab shows basic information about the app and the supported rotations, etc. You must declare the entry point here which is the class with namespace prefixed.
The capabilities tab allows you to select the optional access requirements for the app like: Phone Calls, Microphone, Internet, etc.
Manifest UI: Capabilities Tab
What is weird is that I don't see a way to target devices from the UI directly. The only way (that I'm aware of) is to do this in the code. Initially all projects target Microsoft.Universal. However, I have shown an example of targeting Microsoft.Mobile and Microsoft.Desktop below. (Reference: https://msdn.microsoft.com/en-us/library/windows/apps/dn986903.aspx)
As of now, the versions, I don't think, are that important. I'm sure they will be soon but as of now, 10.0.0.0 is all that you can put in.
There are a bunch more options but these are the basics that are needed.
Finally, let's deploy the app and run it. Since Microsoft has put a restriction on these apps, we must install them through the Windows App Store in most cases (IoT being an exception). So that is why the new Deploy option is available under the Build menu.
So go to Build > Deploy App.
Wait til is all done. (You may see it restoring NuGet packages)
Then Click the Play Button with Local Machine Selected.
And Blam! The app is ready to go. All white and blank, with no usefulness at all...yep.
Although I feel that UWP will be a great addition to the Windows Family, there are some things that need to be figured out. Right now, you can't install an app by downloading it from the web. Really? Seriously?! Tim Sweeney of Epic Games wasn't to thrilled about this idea himself (http://arstechnica.com/gaming/2016/03/tim-sweeney-to-microsoft-universal-windows-platform-can-should-must-and-will-die/). I can't say I fully agree with him, but it is an issue. The next stage of the game would really be able to mix their Cross-Platform with their Cross-Device UWP. Although UWP is good for Windows devices, it won't work directly on Linux or Mac or anything else for that matter.
So Microsoft still has a ways to go to really become the front-runner in this cross-platform market. However, it is nice that the Api is unified amongst Windows Devices which is really the first they've been able to accomplish this. Let's see what happens next in the epic chapter of Microsoft.
Check out our thoughts here.
There is one, and only one, primary focus that any software developer acknowledge: the ability for software to be maintainable. Of course, correctness, functionality, and performance are all important, these will always be easier to address with maintainable software.