Calendar Import is Back

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:-

https://www.microsoft.com/store/productId/9WZDNCRDZZZF

 

Using specific versions of UWP from Win32

From a Win32 .NET library (One that targets desktop apps whether Console, WinForms or WPF) you can add two references and take advantage of (most) UWP APIs.

The first is a .NET library which handles interop with the UWP / WinRT APIs:-

C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETCore\v4.5\System.Runtime.WindowsRuntime.dll

The second is the metadata for the UWP APIs themselves:-

C:\Program Files (x86)\Windows Kits\10\UnionMetadata\Windows.winmd

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.

Xamarin Forms MediaElement

Some time ago I created a MediaElement control for Xamarin Forms for displaying video (and audio) content across the main mobile platforms and it’s been steadily improving and has been used in a number of projects.

After some discussions on GitHub I started the process of integrating the control into Xamarin Forms itself with a Pull request opened last week. There will be some API changes in the transition and I’ll be sure to keep the current control available until its fully integrated into a stable Xamarin Forms release.

Things are progressing well with some reviews and code changes, partly to fit the Xamarin coding style and partly having fresh eyes looking at the code pointing out some improvements. I’ve already created a new renderer for WPF which supports the basics (The WPF MediaElement doesn’t have built-in transport controls so this isn’t supported yet). It highlighted something as I was testing on iOS where the video just wouldn’t work. I later remembered that unless you explicitly request it in your info.plist the app will block any http resources. But you’ll not get an error, the video will simply be stuck in the ReadyToPlay state. Switching to an https target fixed the issue immediately. This lead me to create the following table showing supported URI types and how they map on each platform. These apply to both the InTheHand.Forms version and the Xamarin.Forms control although only the latter has WPF support:-

 

Uri Scheme Android iOS UWP WPF
HTTP/HTTPS Yes HTTPS only or set NSAppTransportSecurity in info.plist Yes Yes
file Yes Yes Yes Yes
ms-appx Yes. Items must have the build action AndroidResource and be located in the Resources/raw folder of the project Yes. Items must have the build action BundleResource Yes Maps to pack://application:,,,{localpath}
ms-appdata Yes (Local+Temp) Yes (Local+Temp) Yes (Local, Temp and Roaming) Yes (Local+Temp)

Azure IoT DevKit – External Connectivity

Beyond the sensors built into the board the possibilities are endless when you consider attaching external devices. As I mentioned in my previous post, the DevKit has an edge connector with a number of input/output pins as well as power. You’ll need an “edge connector breakout” like this to make use of them.

I found this excellent post by Jeremy Lindsay which included a table of the pin numbers and how they map to Arduino pin names – you need this so that you can refer to a physical pin on the edge connector breakout to a pin in your Arduino sketch.

From this it’s possible to rig up an LED or similar on a breadboard and set it from code. One of the things I wanted to try out was using an ultra-sonic distance sensor and this is where I hit a snag. Unlike many Arduino boards there is no 5v output (even though it is driven from a USB 5v input) and the sensor I am using requires one. I’ve had to order a few more parts before I can make progress on this project. Essentially I’ll need a separate 5v supply to my breadboard and will have to convert the output from the sensor down to the 3.3v expected by the DevKit board.

First Steps with Azure IoT DevKit

The Azure IoT DevKit is an Arduino compatible board which is ready to use in conjunction with Azure IoT Hub to build an end-to-end IoT system. Code running on the board is native C and you deploy to the board using Visual Studio Code over the included USB cable. Then your device uses WiFi to establish a connection back to Azure where you can process data received from the device in a number of ways. Two-way messaging is supported so you can respond to the device and send commands to control it. Basically the possibilities are endless!

mxkit

The board itself has a number of sensors – temperature, pressure, humidity, movement and an RGB LED and a small (but very clear) display for output. Other inputs and outputs are possible by attaching to the edge connector which is the same as the microbit. The package consists of the board and USB cable in a neat little cardboard box.

Everything you need software-wise is explained on this GitHub site along with a number of sample apps. It’s even possible to deploy the required IoT Hub and services to your Azure account automatically.

There are three suppliers listed on the “Get a Kit” page and at the time of looking only Plugable had stock but don’t ship internationally. Luckily I was able to find Mouser who had stock and ship to the UK. It only took a couple of days to ship from the US.

I’ll revisit this when I look at setting up the software and provisioning a working program.

 

Bluetooth with Xamarin Mac

I’ve been working on adding macOS support to 32feet.NET and there are two frameworks in macOS for Classic Bluetooth – IOBluetooth and IOBluetoothUI. I soon discovered that neither of these had bindings in the standard Xamarin.Mac package which is referenced by all Xamarin Mac applications. I decided to build binding libraries for both APIs and publish the code as part of 32feet.NET. This means you can either use the IOBluetooth lower-level APIs yourself or later use the platform-agnostic 32feet API.

Today I’ve published the first release of the InTheHand.IOBluetoothUI package. There are fewer APIs than IOBluetooth and I’ve already begun the manual process of simplifying and making it more “.NET friendly”. There is also documentation to add, though even Apple’s documentation on IOBluetooth is rather thin at best…

These are by no means final and there will be changes to the APIs as names are cleaned up and more is tested and fixed. If you’d like to try them in your projects please let me know your feedback via GitHub. Those NuGet packages are:-

https://www.nuget.org/packages/InTheHand.IOBluetooth/

https://www.nuget.org/packages/InTheHand.IOBluetoothUI/