Windows 10 For Developers 1 of N

On the past March 23rd, Microsoft launched the first version of the Windows 10 developer tools SDK. This is a very early release of the tools and there is much to improveme. You perhaps have seen the features in MWC Channel9 videos that aren't available on this release. You will also need to be ready to fight with this SDK, with the installation failing and with tools crashing; you know, living in the edge has a price.
Articles on this series:

How to install the tools

In the first place, you need to be registered as a Windows Insider to be able to download all the Windows 10 related software.
To be able to install the tools you will need first some prerequisites:
  • Windows 10 Build 10041 or better
  • Visual Studio 2015 CTP6 or better
After having all these installed, you can download the ISO image to the web installer for the developer tools from technical tools page.
I might sound a bit "cautious", but remember you are working with an extremelly new and early preview, not only of the developer tools, but also the operating system and Visual Studio. Due to this preview over preview thing, I do not recommend installing these on your main or work machine.

You can go to a secondary machine you know you can wipe if needed, or go the VM way. You can use Hyper-V, VMWare or even Virtual Box to create a new VM with Win10, VS2015 and Dev tools. I even tested the emulators on a virtual machine mounted with VMWare and they work smoothly, due to VMware Hyper-V virtualization.

Known problems

After spending some days working with the preview tools, there are the following known bugs you need to take care of:
  • The current Windows 10 mobile update Microsoft made public in February isn't compatible with these tools since they need a more recent build to work. So your only choice is to deploy to an emulator. At least for the moment.
  • Problems with the emulators when you have the Android emulator installed with Cordova tools for Visual Studio. Both Windows 10 and Cordova use XDE.exe to execute the emulators. But with Cordova tools come the 8.0.12484 version and with Win10 dev tools you get the 8.0.12513 version. The Win10 dev tools version don't support the Android plugin, the Cordova tools version doesn't support the Win10 emulators. So if you run the emulator and get a "Failed to load SKU "WP"" error, just uninstall the Android emulator and run the Win10 emulator again, all will go smoothly the second time.
  • In some Virtual machines setup, you will need to assign more than 2 cores to the Windows 10 machine to make the Windows 10 mobile emulators work.
While playing with these new tools, for sure you will find more bugs or things you don't like. That's the expected result in such an early version like this. Don't hesitate to use the Windows Feedback tool in Windows 10 to submit that info to Microsoft and help outline the Windows 10 SDK. After installing the developer tools, you will find a new section in the feedback app called "Developer Platform".
 
 

A bit of "terminology" before beginning...

Before continuing your trip into  the new tools, there are some news "words" and terms in the tools you need to be familiar with:
  • Windows apps. Microsoft wants you to forget about "Windows Phone app", "Windows app", "Metro app", "Modern app". They want you to call the apps simply "Windows apps".
  • UAP: Windows Universal App Platform. The new app platform is included with Windows 10 and by the way is part of the Windows OneCore (the unified core used across all Windows 10 editions).
    • UAP is the acronym of Universal App Platform. You aren't going to develop an UAP. You will develop Windows apps, that will run over UAP and use UAP.
  • Device family. Every device type supported by UAP is a device family: Smartphones, tablets, desktop, IoT, game consoles... 
Now that you understand how to communicate with the localsm let's start the party!

Your first Windows app

Now to start to see a bit of code. After starting Visual Studio 2015 with the developer tools installed, in the "New Project" window you should see a new "Windows 10" node in the available projects:
 
 
There isn't much new here, you would find the following project templates to work with:
  • Blank Application (UAP): A new empty project using UAP.
  • Class library (UAP): A class library project.
  • Windows Runtime component (UAP): a project for creating a new Windows Runtime component.
  • Unit Test App (UAP): a new app project for testing.
Were you will see some changes are actually in the project structure after creating a new blank application project. If you take a look at the project in the Solution Explorer panel, you should find the structure isn't the same as with the "universal apps" for Windows 8.1 and Windows Phone 8.1 with a platform specific project for each target + a shared project:
 
 
In Windows 10, you have only one executable for all the platforms your app will be executed on. So, you only have one project for all and you don't need to use the shared project anymore.
Having one project for all device families, how can you use a feature included in one type of device? Microsoft resolved this using an "Extensions SDK". When you first create a new blank application project, everything you have access to is the core shared functionality across all device families. If you need to access to a phone related feature, you need to add the phone, or mobile using the new naming and extension SDK. If you need desktop features, do the same with the desktop extension SDK. To see all the available SDKs, right-click the project references then slelect References Manager > Universal App Platform > Extensions as in the following:
 
 
But, wait a minute. What if you add an extension SDK and then execute the app in a different device family not supporting the extension? Well, your app will fail. To avoid this, every time you use an API from an extension SDK, you need to check if the API is available for the device the app is running on.
 
A simple example of this way of working is, you actually will need in a real live (tm) apps: Phone back button management.
The needed APIs to manage the back button in a phone device family are located in the Windows Mobile Extension SDK, so the first thought is to add a reference to that extension SDK in your project.
 
Then, in your application app.xaml.cs file, in the class constructor you can handle the BackPressed event from the HardwareButtons class:
  1. public App()   
  2. {   
  3.     this.InitializeComponent();   
  4.     this.Suspending += OnSuspending;   
  5.     Windows.Phone.UI.Input.HardwareButtons.BackPressed += HardwareButtons_BackPressed;   
  6. }   
  7. private void HardwareButtons_BackPressed(object sender, BackPressedEventArgs e)   
  8. {   
  9.     //TODO: Back button management   
  10. }  
This will work perfectly in the Phone emulator. But if you try to run the app in a Windows 10 tablet, it will fail since the API is not available. So, add code to check if the API is available prior to using it, using the IsTypePresent method of the ApiInformation class you can find in the Windows.Foundation.Metadata namespace:
  1. using Windows.Foundation.Metadata;  
  2.   
  3. public App()   
  4. {   
  5.     this.InitializeComponent();   
  6.     this.Suspending += OnSuspending;   
  7.     if (ApiInformation.IsTypePresent("Windows.Phone.UI.Input.HardwareButtons"))  
  8.     {  
  9.         Windows.Phone.UI.Input.HardwareButtons.BackPressed += HardwareButtons_BackPressed;   
  10.     }  
  11. }   
  12. private void HardwareButtons_BackPressed(object sender, BackPressedEventArgs e)   
  13. {   
  14.     //TODO: Back button management   
  15. }  
Now, I know you have perhaps mixed feelings about that code. The capabilities check in execution and the extensions SDKs for device families is an awesome idea, in my humble opinion, but checking the types using a string? That's one big bad idea... There is nothing more error-prone than a magic string in your code. I hope this is a "work in progress" thing and Microsoft hears us screaming of pain and decide to add some kind of constants, enumerator or any other solution they want.

Fade to black...

Now, that's the end of this first article about Windows 10 development. Soon there will be a new article since there is much to talk about: Adaptative visual states, devices families, changes in XAML, different XAML files for a same page.
 
I Created a GitHub repo with all the samples from this article series. There you will find the code for this article sample about using the back button.

I hope you like it and enjoy it.
 
Happy Coding!