Category: Windows

Categories
Windows

ShowEditNewAppointmentAsync Weirdness

The Windows.ApplicationModel.Appointments namespace in Windows 8.1 (and Windows Phone 8.1) provides access to the user’s calendar. Prior to Windows 10 there were big differences in the APIs as Phone had the existing capability to extend the calendar with app-specific calendars. Now the API is unified across Windows devices but there are some changes to be aware of which will affect existing apps as well as new ones built for Windows 10.

On Windows Phone 8.1 there were two APIs for displaying a new appointment – ShowEditNewAppointmentAsync shows the edit view with the fields pre-populated with the Appointment object you supply. The second API is ShowAddAppointmentAsync which is shared with Windows 8.1. On Phone however it would display the same edit view as ShowEditNewAppointmentAsync. The screen co-ordinates you pass are ignored as the dialog is fullscreen.

On Windows 8.1 only ShowAddAppointmentAsync existed and this displayed a read-only popup view of the passed in Appointment. With just the option to save or discard the appointment (and ability to select which calendar to save in if you have multiple accounts).

If you call either of those two APIs for Windows Phone on a Windows 10 Mobile device you’ll get a different experience. Now you see a read-only fullscreen dialog showing the details of the appointment but you can tap an edit button in the appbar to fully edit the item. You’ve not lost any functionality as such but it is an extra step to get to an edit screen which is especially annoying if that is what you specifically requested.

Calendar Display > Calendar Edit

If you call either of those APIs on a Windows 10 PC you’ll get the Calendar app which will show a read-only view of the appointment with the ability to save or discard. There is no edit functionality available at all. If you’re running in Tablet mode Calendar will launch fullscreen, otherwise it just pops up a window over your app. It will be much bigger than the popup used in 8.1.

ShowEditNewAppointmentAsync
What’s wrong with this? Given the Calendar application is shared across both device types I’d expect the full version to support editing like the mobile one does. If you click “New Event” in the Calendar app you get an edit screen – this is what I’d expect from ShowEditNewAppointmentAsync. I’d also expect the same edit button on the read-only view.  I’d expect ShowEditNewAppointment to open the edit view by default – otherwise there isn’t any point in having two different APIs which do the same thing. I’m hoping that with Mobile still not finished there is time to fix that, or maybe it just needs a tweak to the Calendar app.

Categories
Bluetooth Windows

32feet and Windows Apps

Some time ago I created a subset of 32feet.NET to extend the Bluetooth functionality in Windows Phone 8.0. This was for the Silverlight app model and the only API at the time was based around the Proximity APIs. When Windows Phone 8.1 came along it brought a whole new Bluetooth (and Bluetooth LE) API which was, for the most part, consistent with Windows 8.1. I never got around to updating my code for this model.

Looking forwards Windows 10 is just around the corner and the UWP app model includes this same consistent API, with a few additions, across all the flavours of Windows – IoT, Phones and all shapes and sizes of PC. This time I went back to the drawing board and looked at what functionality was missing and could be added in.

One of the new APIs in Windows 10 is the DevicePicker in Windows.Devices.Enumeration. This is not strictly Bluetooth functionality – any class of device which can be enumerated can be used with it. However it serves as a Bluetooth device picker just fine. Since Windows 10 on phones is a little further away than the imminent launch on the desktop I thought there was a good case for providing this UI now to Windows Phone 8.1 apps and showing how to wrap it to pick Bluetooth devices. Thus you can easily reuse the same code in a Windows 10 project further down the track. Thus the InTheHand.Devices.Enumeration.DevicePicker was born. It uses the same API the exception being that screen rectangles passed in are ignored for Windows Phone as it uses a ContentDialog to pop up the selector. You can still customise the foreground/background and accent colors to match your app. For example the sample code displays this:-

32feet DevicePicker

To use the DevicePicker for Bluetooth devices you need to first have the capabilities set correctly in your package manifest (see here for details). Then assuming you have a button or similar to allow the user to start the selection process you can use the following code:-

string aqs = RfcommDeviceService.GetDeviceSelector(RfcommServiceId.ObexObjectPush);

DevicePicker picker = new DevicePicker();
picker.Appearance.BackgroundColor = Color.FromArgb(0xff, 0, 0x33, 0x33);
picker.Appearance.ForegroundColor = Colors.White;
picker.Appearance.AccentColor = Colors.Goldenrod;

// add our query string
picker.Filter.SupportedDeviceSelectors.Add(aqs);

// prompt user to select a single device
DeviceInformation dev = await picker.PickSingleDeviceAsync(new Rect());
if (dev != null)
{
   // if a device is selected create a BluetoothDevice instance to get more information
   BluetoothDevice device = await BluetoothDevice.FromIdAsync(dev.Id);

   // or get the service which you can connect to
   RfcommDeviceService service = await RfcommDeviceService.FromIdAsync(dev.Id);
}

The CodePlex project includes the source code and two samples – one showing the device picker and retrieving device information, the other a Chat application (which is interoperable with the existing 32feet BluetoothChat sample on other platforms. The binaries for the DevicePicker are up on NuGet in this package.

That covers off device selection, the other main area I knew needed some attention is Service Discovery. The Windows API provides the ability to supply custom SDP attributes when creating a service (or as mentioned in a previous blog post an “extension” record containing custom attributes). It also gives the ability to retrieve SDP records. However in both cases it uses IBuffer (the WinRT equivalent of a byte array). Therefore the other part of the new 32feet project is a set of functionality for building (and eventually parsing) SDP attribute values and records. I haven’t published this to NuGet yet as I’m still working on it but the code is there if you fancy a look.

So the next step for 32feet on Windows is a DevicePicker for 8.1 which allows you to painlessly move your code forward to 10, and a portable SDP library which will work with 8.1 and 10 and possibly outside of Windows platforms too in the future…

Categories
Windows

Determine if running on Windows Phone from a UAP application

There is new metadata query support in Windows 10 to allow your code to react at runtime based on which APIs are available. For example if running on a phone device you may want to start a call, and offer alternative actions on a desktop PC. The correct way to check the availability is to use the ApiInformation class which has a number of methods which take the string name of the type or method and return a Boolean. Without delving into the question of whether a string is the correct approach lets look at an alternative issue.

You want to determine the device type you are running on – say Windows, Windows Phone, Xbox etc to change the type of content you display. You want this high level information not just to alter screen layout or use a specific API. Each Extension SDK provides the device specific APIs for the target devices. Currently the preview tools ship with Windows Desktop Extension SDK and Windows Mobile Extension SDK. If you look at the Object Browser in Visual Studio you can see that adding each of these adds additional root level entries (like a new DLL) and each named after a Contract which is a type contained within it alongside the associated APIs. So you want to quickly determine if you are running on a “Windows Phone” device you could use the following code:-

bool isPhone = ApiInformation.IsApiContractPresent("Windows.Phone.PhoneContract",1);

It’s not currently clear exactly which contracts will be present on which devices – the APIs provided by the Windows.Phone.PhoneContract lib are all familiar APIs present from previous versions of Windows Phone. Since “Windows Mobile” will also be the SKU used for small tablets it isn’t clear if these will also implement this contract or not. If no extension SDKs are added all UAP apps will support Windows.Foundation.FoundationContract and Windows.Foundation.UniversalApiContract.

Although not a part of the current preview tools one can expect a similar set of contracts for the other flavours of Windows – Xbox, IoT etc

Categories
Windows

Moving Forwards: Geolocation

Recently I open-sourced a number of Compact Framework projects and when I was working on re-writing an application which used them as a Windows Runtime app I started to think about how much of the code might be useful for app projects. Obviously the API surface for Windows Runtime is totally different to the .NET Compact Framework. In some cases functionality which I wrote is built into the runtime, in other cases I’d made use of P/Invoke to call native APIs which is not an option. However one thing I noticed was that the Windows.Devices.Geolocation namespace which supersedes System.Device.Location was missing one key feature – a built in method to determine the distance between two points. Since I had code for this which was using the same method as the .NET framework I thought this was a prime candidate for migration.

The Windows Runtime is a rather more complex API and whereas .NET had a single GeoCoordinate type the runtime has BasicGeoposition (containing raw latitude, longitude etc) and a number of other types – Geocoodinate, Geocircle, Geopoint etc I decided to first implement an extension method which would work with two BasicGeopositions and then as a helper added an extension method for Geocoordinate which used the logic from the first.

The methods now live in a new NuGet package currently supporting Windows 8.1 and Windows Phone 8.1 – Charming Geolocation and the code will be available in the Charming project. Just add:-

using InTheHand.Devices.Geolocation;

and you can use the GetDistanceTo methods.

Part of the project using this code required an iOS implementation too for which I’ve used Xamarin. Anyone who has used this will know that while the location functionality is similar to what we are familiar with on Windows the API is significantly different. Because I wanted to fix that just the once too I wrote a wrapper API to expose the Windows API wrapping all the CoreLocation stuff. I’ll be adding this library to the NuGet package shortly and am also in the process of moving all the Charming code from CodePlex to GitHub too.