Universal Apps: partial understanding

One of the ways to build a universal app is to use the partial keyword to allow you to split out functionality that must be different between platforms.

We tried this with our error reporting code, loosely based on LittleWatson.

There is good documentation here http://msdn.microsoft.com/en-us/library/wa80x488(v=vs.90).aspx on partial classes, but despite what it said we just couldn’t get it to work correctly.  So we concocted more and more bizarre ways to use partial, so that the program would compile, including partial methods (which unless implemented the compiler optimizes out).

In the end, it turned out to be nothing related to partial at all, that was preventing our methods from being called.  What had actually gone wrong was this:  We had inadvertently put half of the partial class in a different namespace, thereby making it invisible.  It’s no wonder we couldn’t find member fields in our main implementation.

Pitfalls of adding WP8.1 support to a universal app (Part 1 of N)

As part of our continuing port from Windows 8.1 to WP8.1 of Surface Level, I’ve just recently tracked down a problem thrown during suspension.

We’d already written quite a few classes that would act as a base class, and as a result, I implemented a partial method which I could call for certain tasks.  One of these tasks was registering our Suspension handler.

The bug I was seeing was an end of file reached while reading back our state file, which we use when we resume.  But there were two problems

1.  I kept getting odd suspension manager exceptions in my crash logs.
2.  The suspended handler never seemed to be called anyway.

Item 2 was the first to solve.  It appears that like W8.1, apps aren’t suspended when run in the debugger.  The only problem was, I couldn’t find the UI to shut it off.

Well, eventually I found it here on the Debug Location toolbar:

Clicking Suspend actually caused my suspension to run (twice in fact)

The first crash was caused by the state file being read only (a side effect of running suspension twice).  It turns out that when I added the WP8.1 project, the wizard had added a second call wiring up the suspension code, which I hadn’t spotted.  Removing the duplicate wiring allowed me to get suspension working properly.

String.Format and Cargo Cult Formatting

While working on a port of our Surface Level app to a universal app, I stumbled across some exceptions being thrown in a great matrix library I picked up from here:

http://blog.ivank.net/lightweight-matrix-class-in-c-strassen-algorithm-lu-decomposition.html

Internally, the code was eventually calling

String.Format("{0,5:0.00}", v);

and the bug was caused by a leading space while parsing.

I’ve noticed this string before in some of the Microsoft accelerometer samples, but never actually looked at what it did.

It turns out the ,5 makes the field right justified, filling 5 characters, and padding with spaces.  In all of my testing up to now, I never saw this, but somehow on the latest device, I saw a value of 0, which ended up with a leading space.

The bug has now been fixed by the author in another way, but it points out the importance of actually reading every line of code, and understanding it before you put something into a project.

Why is documentation so terrible these days?

I’m recovering from ankle surgery after a low speed skiing accident that I had in February, and have decided to take the opportunity to port our Surface Level to Windows Phone 8.1 that I wrote while recovering from the initial accident.

I have about 8 weeks where I’m unable to drive, so will be working from home and very bored, so as a result, will have plenty of time for the project.

One of the things I’ve noticed both for my apps, and my job is that the documentation supplied by companies these days appears to be getting worse.  For instance, in my day job, I’m currently building an embedded system based on an STM32F4 microcontroller, and hooking it to a variety of WIFI modules on the market (the only reason for the variety is we keep coming to problems that aren’t documented, and then prevent us from using a particular module in our product).

I’m not sure if the documentation is intentionally bad so that competitors can’t find the weaknesses, or if the product is bad because it’s rushed to market, or if it’s just pure incompetence.

So, back to Surface Level.  While building the Windows Phone 8.1 version, I added back some code from the working Windows 8.1 version, including an AppBar

 

A quick check of the docs shows it works, but then when I run the program I get this:

A first chance exception of type 'Windows.UI.Xaml.Markup.XamlParseException' occurred in SurfaceLevel.WindowsPhone.exe

WinRT information: Cannot create instance of type '%0' [Line: 17 Position: 17]

Additional information: The text associated with this error code could not be found.

Well, that’s a helpful message.  Line 17 does in fact have this on it:

<AppBar x:Name="BottomBar" Opened="OnOpened">

But position 17 is at x:Name?!

If you do manage to get all the way down the page in the online version of the documentation, you might find this:

Oh, I see.  I can’t use it.

Then I tried to mirror the front camera, like I do on the Windows 8.1 version, like this:

mediaCaptureMgr.SetPreviewMirroring(selectedDeviceInformation != null ? (selectedDeviceInformation.EnclosureLocation.Panel == Windows.Devices.Enumeration.Panel.Front) : false);

That throws an exception, because the phone camera doesn’t support it (at least not on my phone), and there’s some helpful documentation in the remarks section:

Horizontal mirroring is useful for video conferencing or video chat applications, because the users typically want to see a reflected image of themselves. The non-mirrored view can look strange, because we are used to seeing ourselves in a mirror.

To mirror the preview video, apps should instead use the following method. Windows Store apps using JavaScript should use the msHorizontalMirror property of the video object. Windows Store apps using C++, C#, or Visual Basic should use the FlowDirection property on the CaptureElement.

SetPreviewMirroring can potentially be used as a performance optimization on some devices

So, we have a method that we shouldn’t use.

While the information is there, it takes at least 20 minutes to discover why things aren’t working by poring over the documentation for each and every method/function call, and my first language is American English.  I feel really sorry for people who aren’t native speakers.