WebAuthenticationBroker is a component of Windows 10 which facilitates Oauth authentication with services from a client app. It handles the presentation and navigation of the authentication pages and returns control to your app along with a returned token or an error code. It’s a UWP API and integrates neatly with modern apps, however what may not be obvious is that it doesn’t use the Edge browser like a WebView control but instead uses the legacy Internet Explorer browser.
This is a problem because it’s old and a bit creaky and some sites don’t work with it, or actively refuse to – one of these is GitHub. If you try to authenticate with GitHub using it you’ll see a big ugly banner asking you to use a modern browser and you’ll be stuck. Hopefully this will change and the API will move to Edge (or even Chromium powered Edge which is on the horizon). However in the mean time you’ll need to roll your own solution. There are lots of ways you could do this by using the WebView control in your app and handling navigation events but I thought I’d try and recreate the same API so that I had a solution I could swap in without major changes. The result of this work is called, and excuse me it was very late when I thought of it, Authful. The full code is online in GitHub here. I haven’t released it as a NuGet library and won’t unless there is sufficient interest as I thought people might just prefer the code so that they can customise the look and feel for their own apps. There is a sample project to show how to call the API (hint: It’s the same as the UWP class). It doesn’t support the advanced options but it should work with most mainstream OAuth-based APIs.
I was almost at the point of retiring the app since Mail & Calendar has supported iCalendar (.ics) files for a while now. Then I came across a scenario where the app is still required. vCalendar files (.vcs) are very similar but use version 1.0 of the vCalendar spec whereas iCalendar is version 2.0. Mail & Calendar still can’t open this format at the time of writing.
I’ve updated the UWP app for Creators Update and later and it now just registers for .vcs files (all .ics files will be handled by the Calendar app and this avoid the OS popping up a choose app dialog unnecessarily). Doing the update also made me check that it could work on Surface Hub and HoloLens (although it just uses the standard 2D Calendar UI). If you get .vcs files via email attachments or online this is a really simple (and free) app to import them into the Windows Calendar.
Download from the store for all Windows 10 devices:-
This describes the v1.0 versions of the API Contracts. These are expanded with each Windows 10 version and so you may find you want to target newer APIs and they are not available here. In a UWP project you can easily toggle the minimum target version of Windows 10 and this defines the API surface available to you. No such option exists for this kind of interop so instead you can switch the Windows.winmd reference for an alternative version. These are installed into subfolders of the above folder with the build number of each installed SDK. The latest released version for the April 2018 update is in 10.0.17134.0. As with UWP development you need to choose your API level carefully as it will affect which machines you can deploy to. For a library developer you need to ensure you document the minimum version you support to avoid any surprises.
The Desktop App Converter (or Project Centennial) is a way of packaging up traditional desktop applications in appx format for the Windows 10 store. You would commonly use it for modernising an existing app. This allows you to take advantage of store distribution and incrementally add modern functionality to it.
My requirement was a little different. I needed a way of adding functionality to a UWP app which is not currently possible via UWP. The functionality in question was the ability to show a progress bar on the desktop taskbar entry. If you don’t know what I mean by this it is what you get with many desktop installers or other apps which make large downloads to keep you informed of progress while you do something else. There are two ways of approaching this – you can include a desktop “full-trust” component inside the same app package as a UWP app allowing you to mix and match and submit to the store as a single entity but this requires the developer to get full trust certification each time you repeat the process. The other approach is to build a standalone desktop bridge app to call the Win32 APIs necessary to control the taskbar and have other UWP apps call into this via an API. This way once the enabling app has gone through certification subsequent UWP apps can make use of it without any special permissions. Underneath there is a simple Uri scheme to request taskbar changes and so the caller won’t throw an error if the “Taskbar Progress” app isn’t installed.
The API to call this is already part of Pontoon as the InTheHand.UI.ViewManagement. StatusBarProgressIndicator. This mirrors the API in UWP which is only available on phone devices. We wrap the functionality for you so there is a common API across mobile and desktop flavours of Windows as well as Android and iOS (although iOS is limited to a indeterminate spinner).
I have a very basic sample app which I’m just waiting to convert from private to public in the store and will update this post with a link when published.
While I prepare to refresh my main machine with Windows 10 Creator’s Update and the latest Visual Studio and Xamarin updates I thought I’d throw together a summary of open-source progress since I last blogged:-
Since the announcement of CodePlex’s upcoming retirement I’ve been moving projects across to GitHub. 32feet and my Compact Framework archive are now moved, there is just some tweaking to be done on the Wiki content for the former. I’m planning a blog post on the process I’ve used.
I’ve reworked the existing documentation site which was hosting the Pontoon documentation and it now also contains InTheHand.Forms and 32feet documentation. The Compact Framework stuff may follow but it depends on getting the dependencies setup just right for the help file builder.
Pontoon has had a number of enhancements. I’ve been refactoring the code to better handle the number of different platforms which are supported. This has also allowed me to identify gaps and fill some of them. Android now has InTheHand.Devices.Radios support for Bluetooth and the ability to launch any StorageFile with Launcher.LaunchFileAsync. macOS now has full support for local and roaming settings as-per iOS.
Recently I’ve been working with a selection of Bluetooth printers. During this work I’ve noticed an odd thing about the UWP Bluetooth APIs. It’s all about the Class of Device. These are a set of defined device types and are categorised into major and minor classes. For example a Printer has a Major class of Imaging and a Minor class of Printer. In the raw form the class of device is a bitmask and the bits reserved for the major class define the behaviour of the rest of the bits. The UWP API exposes a BluetoothClassOfDevice class and this has two properties – MajorClass and MinorClass and each uses an Enumeration. The interesting thing with this approach is that the MinorClass values overlap but have different meanings depending on the major class. There are already multiple fields with the same value – ComputerDesktop, PhoneCellular and PeripheralJoystick for example. For whatever reason all of the Imaging minor classes are missing – they all pre-date the original WinRT codebase so really should have been included.
I created a gist to pull together my helper method and enum to make identifying printers a little easier. I created an extension method to return the correct minor class when you identify a device with a major class of imaging:-