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.

 

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

Building an Etch-a-Sketch with Surface Dial

Microsoft have demonstrated how the Surface Dial can be used in conjunction with Pen input for drawing, but what about drawing with the Dial itself?

For those of us with warm memories of the Etch-a-Sketch I thought it would be fun to replicate the experience with the Surface Dial. Now of course there is a big caveat – you only have a single Dial to use at a time. This can be worked around by using the Click functionality of the Dial – Tapping the top of the dial switches between horizontal and vertical drawing.

The code to achieve this is very simple, and I’ve pasted it in a Gist here:-

You could extend this to support keyboard input too as at the moment the app will do nothing if you don’t have a Dial setup on the PC. The output is created using the InkCanvas control along with a small Ellipse to show the current location:-

Dial-A-Sketch

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/

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/

 

Latest Version of InTheHand.Core

I’ve just updated the NuGet package for InTheHand.Core. This adds a VibrationDevice which works across all Xamarin Platforms (hardware permitting) and fixes a bug with PowerManager.RemainingChargePercent on iOS. The library now has 18 namespaces full of UWP APIs for all Xamarin platforms (and this doesn’t count the sister library InTheHand.UI). Check it out here:-

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