Some years ago, I had an idea for an application, and the functionality of that application involved extracting the contents of a zip file. I spent a while trying to work out how to do this in VB6 programmatically, and finally got bored, and my app never happened (not that there was such a thing as an app at the time).

Recently, I thought that I might re-visit my idea. Things have moved on since VB6, and this is how to work with zip files in 2016.

The following code will allow you to access the files inside an archive:

I used to believe that Nunit’s TestCase test (that is, an ability to define a test and then simply pass it alternate parameters) was denied MSTest users. It appears that this is, at least now, fallacious.

Given the constant problems that I have with finding the correct NUnit test adaptor, and trying to work out which are the right libraries, I think, despite coming late to this party, MS might actually drag people back to MSTest with this.

I’ve had a couple of problems recently, where I’ve had tasks or asynchronous methods and they don’t quote fit into the architecture that I find myself in. I’d come across the TaskCompletionSource before, but hadn’t realised how useful it was. Basically, a TaskCompletionSource allows you to control when a task finishes; and allows you to do so in a synchronous, or asynchronous fashion. What this gives you is precise control over when an awaited task finishes.

UWP

Consider the following code in UWP. Basically, what this does is execute an anonymous function on the UI thread:

Now the function will return when the the TaskCompletionSource.SetResult has been called.

Event based

The second scenario where this is useful is where you are trying to use an event based architecture within an async / await scenario. The following example is a little contrived, but it does illustrate the point:

Imagine that BackgroundFunction is performing a long running task where a specific condition needs to return control. There are obviously combinations of functions in the TPL (WaitAll, WhenAll, WhenAny and WhenAll), however, these rely on the whole task, or a set of tasks, completing. Again, the below example is contrived, but it illustrates the granular control over the task that you have.

I will re-iterate again, I realise that in the above example, there are better ways to achieve this, and the example is purely for illustration.

Conclusion

Generally speaking, the simplest and most robust code comes from using the task architecture in the way it was designed: that is, use async / await inside a method that returns a Task. I’m not suggesting in this post that the methods I’ve described should replace that; but there are situations where that might not fit.

Sharing has changed slightly between Windows 8 and 10, but broadly speaking, the concept is the same. This article is pretty much where I worked most of this out from; however, there were some small pieces missing for my implementation:

Sharing Video Files

My target here was to share an avi file that I’d just created. My first step was to create a Share Helper (most of what is in here is described in the linked article):

The function SetStorageItems accepts an IEnumarable of IStorageItem. In this case I only have one thing to share, so I’ve just created an arbitrary list. The event handling seems a little overly complex for what it is.

Microsoft recommend that you don’t purposely call the ShowShareUI, but there are a number of situations – for example, the share icon in the camera app – that wouldn’t be intuitive any other way (I’m no UX expert, so I’d be happy to be corrected on this). However, the share UI still behaves as though you has swiped in from the right. To be honest, I kind of expected this Windows 8 chrome to be gone for Windows 10, some is clearly still alive and well.

In the new Universal Windows Platform, you can store settings data in many ways. These days, there are multiple cloud options that you can communicate with; alternatively, you can store the settings in the user’s local profile. You can do this locally (that is, the data is stored on the current device against the current user only), or remotely (which means that the data will automatically be shared across all devices where your app is installed for that user). Both of these are stored as KeyValue Pairs.

Local Settings

Local settings are small, local variables. These are accessible even offline. The following code will only work on VS2015 because of the “?.” syntax; however, a null coalesce “??” will work just as well in older versions of VS.

There is, as far as I’m aware, no limit to the amount of data that can be stored in these settings.

Roaming Settings

Roaming settings are a small, out of the box, solution for transferring settings across Windows devices. They aren’t new, and they are very easy to use; the following will return “MySetting” or null (VS2015+ only):

Having recently released my latest app into the store, I noticed that some of the buttons didn’t fit well on the phone version. I’d already come across translations for the HTML/WinJS version of Windows 8 apps, but not the XAML version, and not Windows 10 UWP.

You can do this in Expression Blend

First, double click the view file:

In the States window, you’ll then have the ability to create a new VisualStateGroup:

Create the required states; here’s mine:

If you click the lightning bolt to the side of the group, you should get the following:

If you create an adaptive trigger as above, you’ll be able to set the minimum width or height for the change. I’ve set the minimum width for desktop form factor to 500.

Back to code

What that produces for you (remember that you can alt-tab between Blend and VS and it should deal with the changes relatively gracefully) is a piece of code along the lines of this, within the XAML view:

There’s a number of points here – the first is that you need to name your controls; that’s how they are referenced. If you use Blend and you don’t do this then blend will give them a name; for example, I didn’t give “numericUpDown” a name. If I had another control of the same type then it would just number them.

The second point is the adaptive trigger. 500 and 320 seem to be the generally accepted divisions between desktop and narrow form factor. This approach worked for my specific requirement, although what Blend produces does require some re-work, otherwise it just ends up as a mess.

Something that I spotted today (mainly because my app got ‘notes’ during its submission to the store) is the frame rate counter that is on by default for UWP apps. These are the small numbers down the right hand side of the screen:

Your app will pass if you submit screenshots with these, but they don’t look good and, as I said, you get ‘Notes’.

To remove them, search you project for this line:

this.DebugSettings.EnableFrameRateCounter = true;

And just comment it out. If you need to see it then you can simply re-enable it when you’ve taken the screenshot.