Now that you understand how to communicate with the locals let's start the party.
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.
Where 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 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 select 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.
- public App()
- {
- this.InitializeComponent();
- this.Suspending += OnSuspending;
- Windows.Phone.UI.Input.HardwareButtons.BackPressed += HardwareButtons_BackPressed;
- }
- private void HardwareButtons_BackPressed(object sender, BackPressedEventArgs e)
- {
-
- }
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 use it, using the IsTypePresent method of the ApiInformation class you can find in the Windows.Foundation.Metadata namespace.
- using Windows.Foundation.Metadata;
-
- public App()
- {
- this.InitializeComponent();
- this.Suspending += OnSuspending;
- if (ApiInformation.IsTypePresent("Windows.Phone.UI.Input.HardwareButtons"))
- {
- Windows.Phone.UI.Input.HardwareButtons.BackPressed += HardwareButtons_BackPressed;
- }
- }
- private void HardwareButtons_BackPressed(object sender, BackPressedEventArgs e)
- {
-
- }
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 the 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.
Summary
In this article, we learned about Windows 10 For Developers 1 of N.