Categories
Desktop Code Windows Xamarin

WPF Activity in Xamarin Forms

I’ve recently been working on extending an existing product written in Xamarin Forms to Windows desktop and this has meant learning a lot more about the WPF implementation. Originally Xamarin Forms was created for mobile platforms such as Android and iOS (and Windows Phone – more on that later) but has since expanded to desktop platforms such as macOS, GTK and WPF on Windows (UWP originally straddled mobile and desktop). WPF is a more recent addition to Xamarin Forms and so understandably the implementation is less mature. It does follow the native look and feel closely but I soon found quite a jarring omission.

Our app uses the ActivityIndicator to represent indeterminate activity. On Android et al. this displays a rotating circular spinner but on WPF it was using an indeterminate progress bar squashed into a rectangular space which looked odd. This is understandable as there is no native control in WPF. I then had a flash of deja vu when thinking about something I wrote some time ago for Windows Phone!

Windows Phone 8.1 introduced the WinRT application model (from Windows 8) alongside the existing Silverlight approach but there were some complications and some types of apps could only be written in Silverlight. I created a library called Charming which added some of the Windows 8 style APIs to the Silverlight app model. This was later expanded and became Pontoon. One of the APIs was a Silverlight ProgressRing control which looked just like the Windows 8 equivalent. The progress ring still regularly appears in the Windows shell and is implemented in UWP. Since Silverlight is a subset of WPF it was straightforward to port it into the Xamarin Forms WPF platform library and modify the renderer for ActivityIndicator. Voila! A nice native looking ActivityIndicator for Windows desktop apps. This has now been merged into the Xamarin Forms code and should appear in a preview release soon alongside the MediaElement that also got merged recently. Until it hits a stable release you can add it via InTheHand.Forms too.

Categories
Bluetooth Windows Xamarin

New Year, New 32feet.NET Library

I’ve been working away on the Bluetooth code for some time. I’d been meaning to modernise the code and build with .NET Standard and NuGet in mind and ideally support more platforms. However the project has stopped and started a few times and gone down a few dead ends.

I had planned to rework the library into a full implementation of the UWP API set for Windows.Devices.Bluetooth covering Bluetooth Classic and Bluetooth LE but while I got quite far and had a set of working code for Windows, Android and iOS I decided that that wasn’t the right approach. Some aspects are clearly tied to underlying Windows concepts – the whole device finding/picking process uses magic strings and is not intuitive from a purely Bluetooth perspective. Also there was no real need to integrate both Bluetooth Classic and Bluetooth LE into a single library because there was very little shareable code and these could be maintained separately.

Instead I decided to go with a much simpler option. Build a new library around fundamentally the same API which the library has used for 16 years with a few necessary tweaks, cutting out a few of the more complex features and making it easy to do the most common tasks with Bluetooth Classic. The Bluetooth LE functionality will be revisited in 2020 with a more logical cross-platform API and packaged in a separate NuGet package (but still part of the 32feet.NET project).

What has changed

The library has been renamed InTheHand.Net.Bluetooth to make clear it is a different package and also to make clear the focus as I’ll no longer be including the IrDA functionality. It includes .NET Standard, Classic .NET Desktop, Android and iOS versions. As you can imagine there will be no new version for .NET Compact Framework. The iOS version is not yet complete but will have some limitations as imposed by the platform. I’ll discuss the details further in a separate blog post because it does some fun things over Apple’s quirky API and should make cross-platform Bluetooth Classic a lot easier for iOS.

In due course it will be joined by UWP, Linux and macOS implementations. Linux will require reworking for BlueZ 5 and macOS will be built on top of the IOBluetooth and IOBluetoothUI framework wrappers which are slowly taking shape. Potentially there may be other platforms too, such as Tizen, and hopefully we can grow the community around the project to target other platforms.

There is no BluetoothListener support in this release but it will be included in future builds (except on iOS). 95% of 32feet.NET users are using BluetoothClient to connect out to other devices so this wasn’t a top priority for this release.

The SelectBluetoothDeviceDialog which was heavily tied to WinForms has been replaced with the BluetoothDevicePicker. This offers a similar level of functionality but in a way which feels comfortable from any UI stack and supports async/await.

DiscoverDevices again is vastly simplified to remove concepts which only make sense in the Win32 implementation. Instead this method is used to discover “live” devices in the vicinity. It is accompanied by the new property PairedDevices which offers a more efficient way of retrieving paired devices without doing a live discovery.

When I started working on a modified version of the library for Unity development there was an odd problem. The Sockets stack in the Mono runtime doesn’t correctly support Bluetooth sockets and so the workaround was to P/Invoke the native Sockets APIs directly. In order to simplify the code the Win32 version uses a single implementation which calls the relevant Win32 APIs rather than using System.Net.Sockets. The library defines its own version of NetworkStream to be able to provide a familiar API which also not being tied to .NET Sockets. This makes it easier to support other platforms such as Android where the underlying implementation is completely different but can be wrapped inside a familiar .NET Stream. All of this means that the desktop .NET version of the library will work for the Windows target of a Unity project.

Where is it going?

The aim with this new version is to have a modern code base able to run on the current spectrum of .NET platforms – From IoT devices, to mobile phones to desktop PCs. Alongside the current Bluetooth Classic library and the Bluetooth LE library I’m also planning for other technologies to join the 32feet.NET project all aimed at handling short range device to device communications.

View the project on GitHub

See the latest InTheHand.Net.Bluetooth NuGet package

Categories
Windows Xamarin

Xamarin Forms MediaElement now available on WPF

Continuing from my last post on macOS, there is now a MediaElement renderer for WPF in InTheHand.Forms 2.0.2019.913. The native control in WPF is a lot more limited and is missing two big features – no system provided transport controls, and no support for HTTPS sources. The latter is an unfortunate limitation though it looks as though this is being fixed for WPF on .NET Core.

A possible workaround for these limitations is to have the WPF renderer use the UWP MediaPlayerElement when running on Windows 10 1903 and above. This is currently available as a WPF control as part of the Windows Community Toolkit.

Categories
Windows Xamarin

From Xamarin Insights to Visual Studio AppCenter

If you haven’t already heard about Visual Studio AppCenter then you should check out this blog post introducing it. Microsoft have had multiple devops technologies which all lived in separate silos. Along with its own Azure Insights it inherited Xamarin Insights and Test Cloud when it acquired Xamarin and also HockeyApp. There was obviously a lot of overlap and a mammoth task of building a unified solution.

In terms of crash reporting and analytics AppCenter owes much to HockeyApp, there’s even built in handling of viewing HockeyApp data from AppCenter. No such luck from Xamarin Insights and you’ll need to find your own time to migrate across before Xamarin Insights is retired on March 31st. I had an idea that as a stop-gap solution it would be useful to have the same API as Xamarin Insights but move to the AppCenter back-end. Thus was born InTheHand.AppCenter.Insights. This is now available on NuGet and the rest of this post will look into switching over to it and a bit of information about finding the data in the AppCenter website.

The library exposes the same API as the original Xamarin.Insights package but AppCenter doesn’t support 100% of the functionality so there are some gotchas when using it. You shouldn’t need to modify any of your code and when you are ready you can start calling the AppCenter API directly and eventually phase out the wrapper.

To start, open your existing solution and remove the Xamarin.Insights NuGet package from your projects. Next add the InTheHand.AppCenter.Insights package. It is a .NET Standard 1.0 library for maximum compatibility, it could have been higher for the supported platforms but it doesn’t need any APIs beyond 1.0. Rebuilding your app now and it should all build without any errors against the new library.

I’ve used the Obsolete attribute on methods/properties which are not supported, calling them will just be a no-op but you can remove these calls if you don’t want the warnings.

Now we’re not quite finished – your code still uses an API key for Xamarin Insights. You’ll need to create a new App on AppCenter for the required platform(s) and this will give you a new key (a Guid string) and you’ll need to replace the old Xamarin API key with this one where you call Insights.Initialize in each head project.

Once you’ve done this and rebuilt your app you’ll have working crash reporting and analytics going through to AppCenter and you haven’t had to re-write any code yet.

[Updated 8th March 2018] As of version 1.5 the Report method now supports logging exceptions to AppCenter as this functionality was recently added to AppCenter. You’ll see stack traces etc fully preserved in your App Center dashboard.

Remember I mentioned some gotchas earlier? Well there is one big gotcha – AppCenter doesn’t allow you to send handled exception reports – the Report method. So when the library processes these they are tracked analytics events with various properties of the Exception added. This means the presentation in AppCenter is not as good as the true crash reports. Unfortunately currently only the first 64 characters of the stack trace are preserved.

[Updated 28th February 2018] As of version 1.1 the library also supports Identify and will set these values using AppCenter’s SetCustomProperties feature. The unique ID you assign is given the name “Unique ID”.

AppCenter doesn’t natively support logging events with timing so the ITrackHandle implementation writes the total duration in seconds as part of the key/value data for the event.

A full crash entry looks like this in AppCenter:-

forcedCrash

An event generated by a reported exception looks like this:-

reportedException

The problem of course is that you don’t get reports logically grouped into exceptions thrown by the same code, instead you get a single “event” with the exception name and then properties which may indicate totally different stack traces. This is obviously not ideal but the danger of creating separate events using both the stack trace and exception is that there is a limit of 200 unique events. If you don’t manually delete ones you’ve finished working on as you might mark a crash as Closed you could hit this limit and lose data. I hope it is something that gets added to AppCenter soon, Microsoft promised this functionality would be in place before the Xamarin Insights shutdown but the deadline is fast approaching. When the API becomes available obviously I’ll update the wrapper as required. This is after all a temporary solution to help with the transition.

NuGet: InTheHand.AppCenter.Insights

 

Categories
Bluetooth Windows

Read iBeacons from UWP

I recently got some estimate beacons and have been trying out various things with them. By default they are configured to support Apple’s iBeacon format and could be used in an iOS app to provide location awareness in a close environment. You can read the same data from UWP and can add some location/context awareness in this way. In this post I’ll just discuss the iBeacon approach.

In UWP development there is a BluetoothLEAdvertisementWatcher which is used to read advertisement data from nearby Bluetooth Low Energy devices. The watcher fires the Received event for each advertisement found and you can read the data as required. The key to using iBeacon is to understand how the data is encoded. Advertisement sizes are limited so they need to be designed to be as compact as possible while providing enough information to uniquely identify each device. The iBeacon format consists of a UUID (Guid) and two unsigned short integers. These should be thought of as a hierarchical format:-

UUID > Major > Minor

A location aware app would use a unique UUID for its own use, for example a chain of stores. The Major id would then represent an individual store and the Minor id a location within that store. In iOS the raw iBeacon advertisements are “hidden” from the CoreBluetooth API and instead exposed by CoreLocation. In UWP we use the BluetoothLEAdvertisementWatcher and reconstruct the elements of the beacon. These are stored in a ManufacturerData section with Apple’s manufacturer id (0x4C) used. Within this we access the raw data as an iBuffer (WinRT/UWP equivalent of a byte[] array). The DataReader class is used to sequentially read through the data. The data is:-

Byte 0 – type – 2 for iBeacon

Byte 1 – data length: 21 bytes for iBeacon

Bytes 2-17: UUID

Bytes 18-19: Major ID

Bytes 20-21: Minor ID

We must be careful to respect the byte ordering of the Guid element, the following Gist wraps up the operation:-

public App()
{
this.InitializeComponent();
this.Suspending += OnSuspending;
_watcher = new BluetoothLEAdvertisementWatcher();
_watcher.Received += _watcher_Received;
_watcher.Start();
}
private void _watcher_Received(BluetoothLEAdvertisementWatcher sender, BluetoothLEAdvertisementReceivedEventArgs args)
{
foreach(BluetoothLEManufacturerData md in args.Advertisement.ManufacturerData)
{
if(md.CompanyId == 0x4C) // Apple
{
DataReader reader = DataReader.FromBuffer(md.Data);
byte advertismentType = reader.ReadByte(); // 0x02 – iBeacon
byte len = reader.ReadByte(); // 0x15 (21) – iBeacon
int a = reader.ReadInt32();
short b = reader.ReadInt16();
short c = reader.ReadInt16();
byte[] d = new byte[8];
reader.ReadBytes(d);
Guid uuid = new Guid(a, b, c, d);
ushort major = reader.ReadUInt16();
ushort minor = reader.ReadUInt16();
Debug.WriteLine(uuid + " " + major + " " + minor + " " + args.RawSignalStrengthInDBm);
}
}
}

view raw
App.xaml.cs
hosted with ❤ by GitHub

The event also gives you the Rssi, you can use this to make a general assumption about the relative distance of multiple beacons but should not assume a direct measurement of distance from it.

Categories
Surface Windows

Simulate the Surface Dial

The Surface Dial, and the RadialController API provide an interesting new input metaphor. You may have some ideas of how you could use it but don’t actually have the hardware. Since I tried creating an Etch-a-Sketch app using the dial I was thinking about how to implement a second dial.

Most of us already have a mouse with a central wheel. I decided that for the purposes of prototyping apps for the dial, or to implement a second dial-like device I could create an API around that wheel. There are a few limitations but the basic functionality is the same. The SimulatedRadialController class was born and after a few tweaks to adjust for the fact the mouse wheel reports movement in large steps (30 degrees in my testing) so I reduced this down to perform smaller movements.

The control is packaged up with NuGet. The code to use it is essentially the same as the code for the built in RadialController, the main difference being the lack of a Menu to support multiple tools. You hook up the events:-

c = SimulatedRadialController.CreateForCurrentView();
c.RotationChanged += C_RotationChanged;
c.ButtonClicked += C_ButtonClicked;

The rotation event just changes the angle of a RotateTransform on a UI element:-

private void C_RotationChanged(SimulatedRadialController sender, SimulatedRadialControllerRotationChangedEventArgs args)
{
        WheelTransform.Angle += args.RotationDeltaInDegrees;
}

I plan to add this to the previous Etch-a-Sketch sample app to provide both horizontal and vertical controls using the Dial and mouse wheel as left and right controls.

 

Categories
Tizen Windows Xamarin

Pontoon – Yet More Platforms

What started as a Windows project (unifying the then separate Phone and PC APIs) has since expanded through the Xamarin platforms (iOS and Android) and beyond. The latest NuGet package adds Apple tvOS, macOS and the recently announced Tizen .NET Preview.

The usual caveat applies that not all platforms support all functionality but there is already support for the Windows.Storage style file API, and Geolocation, Accelerometer and Gyrometer sensors, Badge and Toast notifications, VibrationDevice and PowerManager (obviously don’t expect all of these to be present in a Smart TV).

Currently there isn’t a unique NuGet platform ID for Tizen so the dll is “advertised” as .NET Standard 1.3. This will only work on Tizen and if you try to consume in any other .NET Standard project will result in errors. We’ll update this as and when a new NuGet TFM is supported.

I’ve also been updating the documentation with more platform information, so most classes should now have a table like the example below. I’d welcome any feedback on better ways to surface this information.

platform-table

Categories
Windows Xamarin

Pontoon – Available Functionality

As with the Universal Windows Platform itself, Pontoon has a rich API which supports functionality which may not be available on all platforms. There are two reasons for this – either the platform doesn’t natively support the feature or I just haven’t got around to implementing it yet.

There is a simple mechanism to test for functionality at runtime – and as with the rest of the API it’s the same as UWP – InTheHand.Foundation.Metadata.ApiInformation. Using this class you can check for the availability of types, properties, methods etc. via name. The only difference being that all classes have the root InTheHand namespace.

Currently there are a number of APIs which aren’t available on all platforms. Today’s release adds Accelerometer and Gyroscope for Windows (except Win32) and iOS. Another new API is LaunchFolderAsync on the Launcher class which is only present on Windows UWP and Win32 platforms – you would check for this using IsMethodPresent.

As always I welcome all constructive feedback – please use GitHub to raise any issues.

NuGet: https://www.nuget.org/packages/InTheHand.Pontoon/

GitHub: https://github.com/inthehand/Pontoon

Docs: http://inthehand.github.io/

Categories
Desktop Code Windows Windows Mobile Xamarin

Introducing Pontoon – A flexible bridge to the Universal Windows Platform

I first created the “Charming” libraries for Windows Phone in order to add some APIs which were added to Windows 8 but not available on phone. Many of the early ones replicated the “Charms” related functionality (Sharing/Search/Settings) hence the silly name.

When I created version 9 about a year ago I consolidated lots of separate libraries into just two – InTheHand and InTheHand.UI. The latter contained UI specific functionality such as MessageDialog, ToastNotification and ApplicationSettings. Following this I extended the library with support for iOS and Android using Xamarin and exposing the same UWP style API.

As I’ve been doing Xamarin development recently I’m constantly having to look for or write wrappers for native APIs to use across platforms. You sometimes find libraries which claim to provide a cross-platform API but actually only support iOS and Android. I looked at the large codebase I already had and thought about other areas which could be implemented across all the Windows and Xamarin platforms. Among the Windows platforms I added Win32 support so you can use these same APIs from Console, WinForms or WPF applications on versions prior to Windows 10. Since a lot of desktop apps still support Windows Vista and 7 this was very important to provide future code compatibility with Windows 10.

I’d toyed with changing the name before because it’s now irrelevant in an OS which no longer has the concept of Charms. I thought about the Windows 10 “bridges” – to take Desktop Apps, iOS and Silverlight to UWP and thought what I have here is effectively another bridge. It’s a flexible one though and it also works in both directions. You can code C# on numerous platforms and that code will be instantly portable to UWP. You can also use your UWP knowledge to easily target some of the more fiddly aspects of Xamarin platforms consistently. If you consider a Xamarin Forms application which might target iOS, Android and Windows once you step beyond laying out forms with the built in controls and basic page navigation there is no common API to work with Settings, Files, Geolocation, Network connectivity and more. If you are able to find a NuGet library which supports all the platforms you need you’ll have to learn a whole new API too. One word which kept springing to mind with the concept of a flexible bridge is Pontoon and so this is what I chose. Wikipedia says “A pontoon bridge, also known as a floating bridge, uses floats or shallow-draft boats to support a continuous deck for pedestrian and vehicle travel”. Although I renamed the GitHub repository this is a direct continuation of the Charming codebase but there will be a few breaking changes hence the new NuGet package and major version change.

If you are interesting in contributing to the library please do get in touch. There are a number of open issues which are still to be addressed and many more API areas which would make sense to implement in this way. I’ve consciously avoided most UI areas because this is something you’ll need to approach differently for each platform (unless you use Xamarin Forms) and I didn’t want introduce any additional dependencies. There are some UI elements such as StatusBar, MessageDialog, Toast/Badge notifications, CameraCaptureUI etc. I consider these to be part of the “Chrome” rather than your app UI – they will all have a very different look and feel depending on the platform but perform the same functions.

I’m still working on a sample application. I’ll probably use Xamarin Forms in order to create a simple UI to surface as much of this functionality as possible.

As always I welcome all constructive feedback – please use GitHub to raise any issues.

NuGet: https://www.nuget.org/packages/InTheHand.Pontoon/

GitHub: https://github.com/inthehand/Pontoon

Docs: http://inthehand.github.io/

 

Categories
Windows Xamarin

Xamarin Free For All!

Yesterday Microsoft announced that the Xamarin platform (the ability to run C# apps on iOS and Android) would be free with all versions of Visual Studio 2015 Update 2. This is great news and takes away a barrier for developers to use their .NET skills to write cross-platform apps.

We’ve had a number of free libraries for Xamarin for a while so I just wanted to post a quick reminder:-

Charming Apps – Provides consistent UWP style APIs you can call across iOS, Android and Windows platforms for many common tasks. From reading the app manifest properties at runtime through to UI elements and integration with platform functions like SMS, Email etc.

Xamarin Forms Maps Windows Renderers – Currently Xamarin Forms Maps only has renderers for iOS, Android and Windows Phone Silverlight. This package adds renderers for WinRT and UWP platforms.

Device Picker – Currently only supporting Windows platforms this adds a UWP style device picker to Windows Phone 8.1 and Windows 8.1 projects.

We’re continuing to extend the Charming apps libraries and will monitor as Xamarin Forms evolves…