On October 10, Microsoft is hosting the Windows Developer Day here in London, and you can watch the live stream starting at .
The event will start with a keynote by Kevin Gallo and members of the Windows engineering team, followed by a live-streamed Q&A session and several streaming sessions diving deeper into what’s new for developers in the Windows 10 Fall Creators Update.
You might also want to check if there’s a viewing party in your area (check on the bottom of this post).
A couple of weeks ago I decided to enroll into Xamarin University and after a few classes and a final exam, I’m now a Xamarin Certified Mobile Developer!
I love Windows Development and make no mistake: I intend to keep writing and working with full native UWP!!
But at this time it makes complete sense for someone who works with XAML and C# to also learn Xamarin, as this is the best Microsoft has for cross-platform development!
Xamarin University was a really good experience and I can definitely recommend it to everyone: people that just started coding with .NET and C#, experienced developers who want to learn Xamarin, or professional developers that just want to get Xamarin certified!
Microsoft’s last update for the WP8.x operating system (dubbed “Update 2”) was more than 2 years ago… so even if the “official” support only now ended, I think we can all agree that unofficially Microsoft abandoned the OS a long time ago (mostly when they replaced it with Windows 10 Mobile).
My own experience with Windows Phone
Microsoft announced Windows Phone 7 at the Mobile World Congress in Barcelona, Spain, on February 15, 2010; I remember that the more I saw those screens and learned about the promised capabilities and technical details, the more I knew that I wanted to build apps for it, both as a hobby and professionally - and do so I did!!
When they released the first Windows Phone devices on October 21, 2010 in Europe, I went straight to a local shop and bought my very first Windows Phone: the magnificent Samsung Omnia 7.
Soon after that, Microsoft and Nokia got into a partnership to boost the operating system footprint, and as a consequence I ended up leaving Portugal and moving to Bristol UK to join the Nokia Music division, later known as MixRadio!
Nokia’s first Windows Phone was the Lumia 800, one of the best phones I have ever owned (I actually kept one of these as a souvenir)
By my account, throughout the years I owed and used at least 12 different Windows Phone devices, mostly due to my time as Nokia employee.
I also got to do a lot tech-talks on Windows Phone development, and participated in a few hackathons, helping the young and brightest with their projects.
“The King is dead, long live the King!”
Microsoft arrived late to the “mobile party” and made lots of mistakes (the lack of software upgrades for “older” devices, some less than a year old, being the biggest), but it was the lack of true first-party apps that caused users to lose interest in the phones and doomed the mobile operating system.
Windows 10 makes good on the promise of “one Windows for all devices”, but the mobile flavor never did get the same praise as the Windows Phone did - and I strongly agree with that!
I enjoyed all my Windows Phone devices, and I will miss using them a lot… but life goes on!
MSBuild based projects have two default build configurations: Debug and Release.
While these two configurations are enough for most projects, some might actually require custom build configurations that will support different environments, alternative build targets, etc..
Until now we could use Visual Studio Configuration Manager to easily create a copy an existing configuration setup, and then change small bits to match our specifications.
But now there’s a new csproj format for .NET Core, and while it includes the expected Debug and Release build configurations, the “copy configuration” process doesn’t work anymore!
The problem is that the new project format is based in quite a few implicit defaults, so Visual Studio Configuration Manager can’t actually create a copy of the existing build configurations with all the properties set.
Introducing the MSBuild Configuration Defaults
As I couldn’t find a way to “inherit” from the base Debug and Release build configurations, I tried to understand what properties were actually required on each of them, and then create some build scripts that would set them for me!
Those MSBuild scripts are available here and can easily be installed by running Install-Package MSBuildConfigurationDefaults on the Package Manager Console, or added with the Visual Studio NuGet Packages Manager.
After adding the NuGet package, I recommend closing and re-opening the solution to ensure that the build scripts are correctly loaded.
Once installed, any custom build configuration name starting or ending on “Debug” will have the following build properties set by default:
If any of these properties are set on the project, those values will have override the defaults above.
If you don’t want to name your custom build definition according to the rules above, just add a ConfigurationGroup property and set the value to Debug or Release to ensure those build definitions get the appropriate default properties set.
The following is an example of a custom build configuration called “Production”, that has the ConfigurationGroup set to “Release” (so it gets the default property values set as for the a “Release” build configuration), but also overrides the DebugSymbols property default value:
On the above example, the MainPage_Loaded is an async void method that will as it needs to await for the completion of some of its calls, but sometimes we also need to allow the event invoker to wait for all handlers to complete.
Inspired on how the background tasks use a deferral approach to solving this problem (as they too are void methods), I came up with a similar approach!
Introducing the Deferred Events
A “deferred event” is basically an event that allows the invoker to wait for the completion of all event handlers.
The trick here is to call e.GetDeferral() to retrieve a deferral object, and just before we exit the method, we do deferral.Complete() to notify the invoker that we have completed our work!
There are a few rules that you have to be aware of:
You only need to call e.GetDeferral() if you actually want to the event caller to wait for the completion of the event handler; if you don’t call it, it will just behave as a regular event handler.
You must call e.GetDeferral() to get an EventDeferral instance before any await call in your code to ensure that the event caller knows that it should wait for deferral.Complete(); ideally, it should be the first thing you do in the event handler code.
If you have indeed called e.GetDeferral(), then you must call deferral.Complete() to signal that the event handler has finished.
To ensure the correct usage of the deferred events, use the following as a template for your event handlers:
Now load your App.xaml.cs file and ensure you call the UserAgentHelper.SetDefaultUserAgent() method inside the App class constructor:
// remaining code
From that point on, any webview inside your app will use the specified user-agent string (“MyApp/1.0” in our example above)!
One final note: only a few Win32 API’s are actually allowed in apps published to the Windows Store (you can check the complete list here)!
The Windows Store recently allowed for apps to use the UrlMkSetSessionOption API, but if you look at the list above you will notice that it’s not yet listed; that should change once Microsoft updates the list on that page.
Kudos to Hermit Dave for pointing me in the right direction for a solution for this problem!