Using the excellent UniFi web interface, I created a few VLANs so I could easily segregate my IoT devices from the rest of the network.

That was all working fine until last Christmas I got myself a Sonos Arc soundbar, and realized that I couldn’t have it on VLAN 20 and access on my Android phone in VLAN 40…

After a lot of googling on this problem, I came to realize that Sonos uses multicasting to “announce” their devices to the network; so as long as I could replay those multicast packages across the VLANs, I should be able to access it on my phone without issues!

I found the multicast-relay from Al Smith on GitHub, which it said to it could be used to “relay broadcast and multicast packets between interfaces”… so just what I needed!

My solution was to SSH into the UDM (this is disabled by default, but you can enable it on the web interface) and execute the following commands to download and run the multicast-relay.py python script:

cd /tmp
wget https://github.com/alsmith/multicast-relay/raw/master/multicast-relay.py
python3 multicast-relay.py --foreground --verbose --noMDNS --interfaces br20 br40

On the final part of the above commands you will notice “br20 br40”, those are my VLANs 20 and 40, so you will have to change those to match your own VLANs.

Once the script started, I could see it relaying the Sonos multicast data across VLANs just as I wanted, and when I opened up the Sonos Android app, it quickly found the device and allowed me to add it to the app!

Now the interesting bit is that after adding the Sonos device to the app, I could just stop the script (hit Ctrl+C) and then delete it, as the app will still work just fine even without seeing those multicast packets ever.

The raw reality is that the work opportunities in Windows Development in the UK have mostly disappeared, and right now, there are no signs of this changing anytime soon!

For the past 2.5 years I’ve been working mostly with .NET Core 3.1, .NET 5, and .NET 6, building backend solutions, running inside Docker containers or as Lambda functions, hosted in Microsoft Azure and/or Amazon Web Services - and I have learned a lot with people who have more experience than I did on this type of work!

On a personal level, I’ve been experimenting a lot more in Home Automation, using Home Assistant, ESPHome, and Zigbee2MQTT.

A couple of months ago I bought an Ender-3 V2 3D printer which I have now heavily modified, and that took me to learn more about CAD modeling, 3D printing, electronics, and start contributing in some related open-source projects - but I’m going to leave that for another post!

As I continue this new phase, I wanted to drop the “Windows Development” moniker on this website and replace it with a more appropriate “Programming and Tinkering”!

One of those is BeardedTinker channel on YouTube, as he provides particularly good step-by-step explanations in his videos - if you are interested on the topic, I do recommend following his YouTube channel!

A few weeks ago he published a video on Smart Home Service monitoring with Home Assistant, where he showed how we can check that a website is working correctly by using curl on the webpage address and then checking for the 200 OK status return code.

I wanted to improve on that by checking a webpage for changes and then creating automations on that!

There are a few ways to achieve this, I will be discussing two of them!

Using the ETag header

First, here is a quick explanation on what the ETag header is (more here):

The ETag HTTP response header is an identifier for a specific version of a resource. It lets caches be more efficient and save bandwidth, as a web server does not need to resend a full response if the content has not changed.

As all we want is the webpage headers, we can use a HEAD request instead of the GET, so here is how the whole thing will work:

sensor:
  - platform: command_line
    name: webpage_monitor
    command: >-
      python3 -c "import requests; response = requests.head('https://www.zigbee2mqtt.io/information/supported_devices.html'); print(response.headers.get('ETag'))"
    scan_interval: 10800

On the above example, we have a sensor called webpage_monitor that will execute a python command to perform a HEAD request on the Zigbee2MQTT Devices webpage, and return the ETag header value.

Now all we need is an automation that will trigger when the state (value) of this sensor changes:

automation:
  - alias: Show notification when webpage_monitor changes
    trigger:
      - platform: state
        entity_id: sensor.webpage_monitor
    action:
      - service: persistent_notification.create
        data:
          message: 'Page changed!'

Using the page content

Not all webpages have an ETag header, and for those cases (or when the ETag somehow changes without the content actually changing), we can instead create a hash of the page content and use that in our automation!

Here is an example with the Home Assistant homepage:

sensor:
  - platform: command_line
    name: webpage_monitor
    command: >-
      python3 -c "import hashlib, requests; response = requests.get('https://www.home-assistant.io/'); print(hashlib.sha256(response.content).hexdigest())"
    scan_interval: 10800

The above will calculate a unique hash of the content of the page and store that in the sensor.

As before, all we need then is to create an automation that will run when the sensor state changes!

I like to use Docker containers for pretty much everything I do, so I wanted to see if I could have a Docker container connect to a WireGuard VPN Server, and then have other containers share that same connection.

Surprisingly, this is not only possible, but it is also amazingly easy to achieve!

Preparation

We will be using the linuxserver/wireguard Docker image. This image works in either WireGuard server or client mode, but we will be using it just as a client.

For this post, I will focus on having the VPN connection isolated from the host system by using a custom bridge network.

We will also be using docker-compose to maintain the full Docker stack.

We will create a folder called “wireguard” that will store all the data from the container. Inside this folder we will place a file called “wg0.conf” that will hold the WireGuard connection settings.

Our final folder structure looks like this:

.\docker-compose.yaml
.\wireguard\wg0.conf

Getting a WireGuard VPN server

There are quite a few VPN Server providers out there that already provide WireGuard servers for you to connect, so if you already have a VPN service subscription, you should probably check there first for WireGuard support!

I’ve been a happy customer of TorGuard for a few years now, and I was quite pleased to see them adding WireGuard support recently.

If you are considering registering for a TorGuard subscription plan, you can use this link and the promo code PL50P to get a lifetime discount of 50% off!

Disclaimer: neither TorGuard nor anyone else sponsored this post, but as I said I’ve been paying and using their products for quite a few years to the point I do recommend them. The link above is an affiliate link and does pay a small commission to me for anyone who does use it with the discount code.

Here is how you can generate the WireGuard connection settings in TorGuard:

1. Login and open the Config Generator
2. Change the ”VPN Tunnel type” to “WireGuard”
3. Select one of the available servers on the ”VPN Server Hostname/IP”
4. Enter your ”VPN Username” and ”VPN Password”
5. Click on “Generate Config”

The last step is to copy the “Config Output” contents to the “wg0.conf” file.

Running WireGuard from Docker

Here is the basic “docker-compose.yaml” file to get the container running:

version: '3.7'

services:
  wireguard:
    image: linuxserver/wireguard
    container_name: wireguard
    restart: unless-stopped
    networks:
      - backbone
    volumes:
      - './wireguard:/config'
      - '/lib/modules:/lib/modules:ro'
    environment:
      - PUID=1000
      - PGID=1000
    cap_add:
      - NET_ADMIN
      - SYS_MODULE
    sysctls:
      - net.ipv4.conf.all.src_valid_mark=1

networks:
  backbone:
    driver: bridge

If you read the Docker image documentation, you will see it requires some special capabilities that need to be enabled for it to work. You can see those on the cap_add and sysctls yaml nodes above.

We are now ready to start, so just enter docker-compose up -d to create the “backbone” bridge network, and create and start the “wireguard” container.

Testing and Validating

Run the following commands now:

curl -w "\n" ifconfig.me

docker exec -it wireguard curl -w "\n" ifconfig.me

The first command will retrieve your real Public IP, matching the one your ISP has provided you with.

The second command will do the same but from inside the Wireguard Docker container, and it should match the connected WireGuard VPN Server IP.

Sharing the connection with other containers

Under the services node of our “docker-compose.yaml” file, add the following service:

# under the existing "services:" node, add the following content
ubuntu:
  depends_on:
    - wireguard
  image: ubuntu
  container-name: ubuntu
  network_mode: service:wireguard
  command: >-
    sleep 10 && curl -w "\n" ifconfig.me

After saving the changes to the file, run docker-compose up -d to start this new container.

The above service will start a new Ubuntu Docker container after the WireGuard one, pause for 10 seconds, and then retrieve the Public IP address; if all goes well, this should match the WireGuard VPN Server IP.

The trick here is to use the network_mode: service:<service-name> to make the new container reuse another container’s network stack!

It’s a great NAS, but it’s the extra features like being able to easily run Docker containers that makes me like it even more!

I recently tried running an AdGuard Home Docker container and with no surprise, it worked perfectly; after setting the NAS IP as the DNS server in my router, all my local DNS requests were sent to AdGuard Home and I could see it doing its job of blocking any known advertisement or tracking hosts.

There was however a small issue: the IP of the client machine was not showing up!

I found a similar issue had previously been open on Pi-hole GitHub repository, but no solution provided.

As I couldn’t find any fix for this problem, I posted the issue to the Synology Community forums, but that didn’t provide a solution either…

At this stage, I tried comparing the Docker iptables on my Synology NAS with the ones in a Raspberry Pi, and that’s when I noticed that the Docker pre-routing rules were missing.

I then SSH‘ed to the Synology NAS and manually added the missing rules:

sudo iptables -t nat -A PREROUTING -m addrtype --dst-type LOCAL -j DOCKER
sudo iptables -t nat -A PREROUTING -m addrtype --dst-type LOCAL ! --dst 127.0.0.0/8 -j DOCKER

Success!!

I could now see the client IPs and hostnames on AdGuard Home:

I was aware that this change to the Synology iptables was not a permanent one and would have to be done on every reboot, so the next step was to get a more permanent solution!

The simplest solution I found was to use the Synology Task Scheduler to run a user-defined script on every reboot

You can check the script and instructions on how to use it here:

Please be aware that these changes to the iptables will probably mess with the Synology Firewall, so just be careful with that if you do use the Firewall!

Also be aware that this goes with WOMM certification, so it works on my machine but there are no guarantees it will work on yours!

Let me just start by saying that Build 2020 was awesome!!

There was a lot of great content going around for everyone, but as I was watching the “From code to scale! Build a static web app in minutes” session showing how easy it is to use Azure Static Web Apps, I couldn’t help but to try that for my own with this website!

My first attempt was to run through the “Tutorial: Publish a Gatsby site to Azure Static Web Apps Preview”, and in the end I was happy to see it created the Azure resources and the a new Github workflow showed up on my repository.

On close analysis of the workflow, I can see there’s a new Azure/static-web-apps-deploy action in use doing all the heavy lifting! Internally, this action is using Oryx build system to identify the type of source code in the repo and compile it.

Once the workflow started and got to the Azure/static-web-apps-deploy action, I quickly came to realize that it wasn’t happy with the fact that my “package.json” file had "yarn": ">=1.22" on the "engines" node… the build image only had yarn 1.17 and so the build failed:

error pedrolamas.com@0.1.0: The engine "yarn" is incompatible with this module. Expected version ">=1.22". Got "1.17.3"
error Found incompatible module.

At this point I edited my “package.json” file, lowered the yarn version requirement to “1.17”, and moved forward.

As expected, pushing this change caused a new workflow to start, but again, this failed:

error Processing /bin/staticsites/ss-oryx/app-int/content/assets/logo.jpg failed

Original error:
/bin/staticsites/ss-oryx/app-int/node_modules/cwebp-bin/vendor/cwebp: **error while loading shared libraries: libGL.so.1: cannot open shared object file: No such file or directory**

This time, the problem was a lot more complicated to fix: the libGL.so.1 library required by Gatsby to process the images was missing from the Oryx docker image!

At this stage I actually thought giving up and went to Twitter to somehow vent my frustration on what I just experienced:

I tried this yesterday with my own GatsbyJs website and unfortunately it failed... First it was Yarn version (had to lower my requirement), but once I fixed that it failed on some native component when processing the images. https://t.co/rnYuwtmYyj

— Pedro Lamas (@pedrolamas) May 21, 2020

John Papa quickly replied to that tweet, and asked me to open an issue on the Azure Static Apps repo.

After some messages exchanged, I followed up on a tip from Annaji Sharma Ganti to compile the source code before the Azure/static-web-apps-deploy action, and make the action point to the compiled static folder (the “public” folder in my case) - this way Orix would just skip the compilation bit and go directly to publishing the artifacts to Azure.

You can see here my changes to the workflow.

Finally, the workflow worked as expected and I could see my static GatsbyJs site hosted as an Azure Static Web App!

I then made a few more changes (like ensuring that GitHub would checkout the submodule with the website images and fixed some missing environment variables), added a custom domain, waited a few minutes for it to generate a valid SSL certificate, and… we are done!!

http://azure-test.pedrolamas.com/

I ran a website speed test with Fast or Slow and got 98 of 100 points, a 2 points improvement over a speed test of this website (which is built and hosted on Netlify with Cloudflare CDN)

Took a bit more of effort than I initially expected, but I’m very happy and very impressed with the result!

The Azure Static Web Apps is currently in “preview” so be aware that changes and improvements will happen before it is ready for production - in the meantime, go and try it out for free!

Microsoft Build 2020, the biggest annual event from Microsoft for Developers by developers, is just around the corner!

In regular times, //build/ is an in-person paid event, but given the current situation with COVID-19, Microsoft announced that this year it will host the event virtually, and completely free!

The event starts on the 19th of May at 16:00 London time with Satya Nadella, followed by 48h of live sessions!

You can register here right now!

As Windows Phone has been dead and buried for a while now, last weekend I uploaded all assets and source-code for my old Windows Phone 7.x and 8.x apps to GitHub, some of them never before published!

Here’s the list of the new repos:

• PedroLamas.JogosSantaCasa
• PedroLamas.OtherSide
• PedroLamas.Quadratic
• PedroLamas.TheBroCode
• PedroLamas.Vencimento
• PedroLamas.WP7.CTTObjectos
• PedroLamas.WP7.MetroNoPorto
• PedroLamas.WP7.UnitConverter

All content is available under MIT license, but please bear in mind that I’ve built these a while back and so I give no guaranties that these are in working order!

Don’t get me wrong here: I still love to work in UWP and will carry on doing so, but reality is that it’s been getting a lot harder to find companies looking for UWP experts to work.

At the same time, I believe there is nothing wrong with expanding your knowledge base by learning new stuff, so here we are!

Since learning React and TypeScript, I’ve fully migrated this website from Jekyll to Gatsby.

I enjoyed Gatsby so much that I have even contributed with a couple of PR’s and created my first Gatsby Plugin gatsby-remark-acronyms (this is also my first npm package ever)!

In my home I have a NanoPi NEO 2 SBC running Home Assistant as an all-in-one home automation solution, so I’ve open-sourced my whole configuration, including the Docker configuration that hosts it.

This gave me the opportunity to improve my Python skills, and so I have already contributed back with a couple of PR’s.

There are a few more projects I’m involved on that I haven’t mentioned above, but the more I learn new stuff, the more I think I should make a change to the site description: ”Windows Development”…

The most important bit to keep from that article is the fact that the default binding Mode for regular bindings is OneWay, while for the compiled ones is OneTime.

Best way to understand this is with some sample code:

<StackPanel>
    <!-- the implicit binding mode here is "OneWay" -->
    <TextBlock Text={Binding Name} />

    <!-- the implicit binding mode here is "OneTime" -->
    <TextBlock Text={x:Bind Name} />
</StackPanel>

Starting Windows 10 version 1607 (Anniversary Update, SDK version 14393), developers can change the default binding Mode by setting the x:DefaultBindMode attribute.

Applying the attribute to an element will make it and all child elements use the same value for binding mode.

Here’s the same sample code again, now with the x:DefaultBindMode attribute added to the root element:

<StackPanel x:DefaultBindMode="OneWay">
    <!-- the implicit binding mode here is "OneWay" -->
    <TextBlock Text={Binding Name} />

    <!-- the implicit binding mode here is "OneWay", as set on the x:DefaultBindMode in the parent element -->
    <TextBlock Text={x:Bind Name} />
</StackPanel>

For the last couple of months, I’ve been working a lot on something quite different from my Windows Development expertise: writing .NET Core micro-services with React and Typescript front-end, running on Docker containers in Kubernetes, hosted on Microsoft Azure!

The thing is that the more I worked with React and Typescript, the more I was enjoying it — to the point that made me think on how I could use my new skills on this blog!

Back in 2017, I migrated my blog from WordPress to Jekyll and hosted on GitHub Pages.

From that moment my blog became blazing fast and I was fairly happy with the arrangement; plus, as far as I am aware, I had near-zero downtime on the blog!

However, I always felt that Jekyll in GitHub Pages was quite limited in what can be achieved (a simple example is that you can’t easily generate a page with all categories or tags).

I started to search for a React-based static site generator, and that’s how I found Gatsby!

Gatsby is a free and open source framework based on React that helps developers build blazing fast websites and apps

A month ago, I started to migrate the blog and today it is all Gatsby based, fully hosted on Netlify (provides free hosting, highly configurable build configuration, custom headers, redirect rules, …)

This very post if the first of many using the new platform!

As far as I can tell, everything is working properly, but if you find any problem, please report it by creating a new issue and I’ll take care of it as soon as possible!

Microsoft is hosting the Insider Dev Tour London on June 18th, 2019 from 8:00 to 17:30 at the Vue Cinema in Leiceiter Square.

You can expect a lot of content around building Microsoft 365 experiences (Windows, Graph, Office, Teams), no matter your skill as a developer.

I will be there to talk about “Developing with the new Edge Browser”, and there will be quite a few familiar faces talking about other topics too!

More details and registration are available here!

<AppBarButton Content="Send" Icon="Send" />

In the above example, the AppBarButton.Icon property above is set to “Send” which is actually a value of the Symbol enumeration.

The Symbol enumeration is quite useful to quickly access glyphs from the Segoe MDL2 Assets font file, but this is a limited subset; a more complete list of the available glyphs can be found here.

If you want to use one of the symbols from that list that is not part of the Symbol enumeration, you need to escape the unicode point by prefixing it with ”&#x” and suffixing with ”;“.

For example, the unicode point for the “WindowsInsider” (Ninja Cat) glyph is “F1AD”, so the complete escaped code is ””

In an ideal world, one would just use it like this:

<!-- this doesn't work! -->
<AppBarButton Content="Ninja Cat" Icon="&#xF1AD;" />

However, you will quickly realize that this doesn’t work!

The correct way is by using the FontIcon class and specifying both the font family name and the escaped glyph unicode point:

<!-- this works! -->
<AppBarButton Content="Ninja Cat">
  <AppBarButton.Icon>
    <FontIcon FontFamily="Segoe MDL2 Assets" Glyph="&#xF1AD;" />
  </AppBarButton.Icon>
</AppBarButton>

MarkupExtension to the rescue!

Introduced in Windows 10 Fall Creators Update (v10.0.16299.0), the MarkupExtension class allows developers to write markup shortcodes just like the native {Binding}, {StaticResource}, or {x:Bind}.

To create a XAML markup extension, create a new class and ensure that it:

• inherits from MarkupExtension
• overrides the MarkupExtension.ProvideValue to provide the implementation
• is marked with the MarkupExtensionReturnTypeAttribute and specifies the return type
• has a name ending in “Extension”.

Following on our example, we can easily create a MarkupExtension that would return a FontIcon instance for a given glyph unicode point:

[MarkupExtensionReturnType(ReturnType = typeof(FontIcon))]
public class FontIconExtension : MarkupExtension
{
    public string Glyph { get; set; }

    protected override object ProvideValue()
    {
        return new FontIcon()
        {
            Glyph = Glyph,
            FontFamily = new FontFamily("Segoe MDL2 Assets")
        };
    }
}

Having this on our code, we can then use it in XAML just like this:

<!-- this works just fine! -->
<AppBarButton Icon="{local:FontIcon Glyph='&#xF1AD;'}" />

In the end, we went from 5 lines of XAML code to just 1!

I couldn’t find any information on this 0x800705AA error, but I eventually tracked this to be caused by the fact Hyper-V was using the machine GPU with RemoteFX!

The easiest way to fix this I found was to just disable RemoteFX; to do so, follow these steps:

• open Hyper-V Manager (just press Win+R, type virtmgmt.msc and hit Enter)
• on the left pane, right-click the machine name and then click “Hyper-V Settings”
• on the tree, select “Physical GPUs”
• untick “Use this GPU with RemoteFX” and click OK

After disabling RemoveFX, remove any Windows 10 Mobile emulator from the “Virtual Machines” list (Visual Studio will re-create these) and just deploy from Visual Studio again and you should now be able to launch the emulator!

TL;DR

My opinion on this subject has evolved to the point I’m now recommending that you should strong-name your assemblies.

Why the change of heart?

2 years ago, I wrote my thoughts about strong-naming assemblies in a post I called “Still Strong-Naming your Assemblies? You do know it’s 2016, right?”.

Coming from all the development related pains in Silverlight and Windows Phone platforms, I knew how strong-named assemblies were a real problem, hence why I wrote that post and said that developers should stop strong-naming their assemblies.

With time, that post somehow became the “canonical answer” for questions in the line of “should I strong-name my assemblies?“.

This would make a good blog post title. There is a lot of confusion in the community on why or why not assemblies should have strong names in 2018! This is still very often cited as the canonical answer all over the place: https://t.co/RblHqL4h48

— bit bonk (@bitbonk) September 4, 2018

Coming to more recent times, I had the chance to revisit this topic while discussing what to do over a strong-naming related issue on the Windows Community Toolkit.

After the discussion and a few quick checks to confirm the information passed, the consensus was to go ahead and strong-name the toolkit assemblies.

Since that moment, I must admit that I changed my mind and I’m now advocating that you should strong-name your assemblies!

Silverlight and Windows Phone are dead

For much that hurts me to say this(!), Silverlight and Windows Phone are dead platforms and thus, the reasoning to not strong-name an assembly as they could become unusable in these platforms, is no longer valid.

Modern frameworks can ignore strong-name information

While Windows 10 UWP and Xamarin completely ignore any strong-name information in the referenced assemblies, .NET Core has mechanisms to automatically redirect all references.

In fact, .NET Core enforces all their assemblies to be strong-named (they even have a document describing this requirement).

NuGet does help by automatically creating binding redirections when you add packages to your project!

The GAC is still very well alive

Yes, against what I thought to be true, Windows 10 still has a GAC that supports side-by-side assemblies for the full .NET Framework!

The GAC requires strong-named assemblies, so there is still a real use case for those in modern days.

Final thoughts

I’m taking a leap of faith that all currently supported frameworks and all future ones will provide mechanisms to ignore strong-name info in assemblies, or just allow to use redirections.

If that proves true, then yes: you should strong-name your assemblies as that will allow more people to use them.

To those still skeptical of strong-naming their assemblies, I propose a compromise solution: do strong-name your assemblies, but only increment the assembly version for major releases! Json.NET has been using this approach to avoid binding redirects since 2014, and as far as I can tell, with relative success!

As a final note to open-source library developers, I strongly recommend that the strong-name key file gets check-in to the project repository so that anyone can easily clone the project and compile a version of the library that works with anyone else’s binaries!

In truth, I started thinking in writing this after seeing my fellow MVP Rudy Huyn CrossUIBinding library.

Nice, but wouldn't it be easier just to override the add & remove of the PropertyChanged event and capture the Dispatcher there? That way all you need is a base viewmodel, no other changes on the view or properties of the viewmodel!

— Pedro Lamas (@pedrolamas) March 16, 2018

Rudy’s solution to this problem requires a wrapper around the properties of the view-models, where as I intend to fix the way view-models notify their event handlers.

But why do I need this?

Well, you will only need this if your application uses multiple windows and you want to share the same view-model instance between them!

if that is the case, then you must ensure you raise the INotifyPropertyChanged.PropertyChanged event on the correct thread as each window as its own separate UI thread!

I strongly recommend a look at the great document that Rudy has written around the CrossUIBinding as it has a lot of valuable information with some great visualizations!

So how do we solve this?

We can ensure we raise the PropertyChanged event in the correct UI thread by capturing the dispatcher instance when an event handler is added!

That can easily be achieved by defining custom add and remove event accessors that will get invoked when client code subscribes and unsubscribes respectively to the event:

public abstract class MultiWindowBaseViewModel : INotifyPropertyChanged
{
    public event PropertyChangedEventHandler PropertyChanged;
    {
        add
        {
            // add code goes here
        }
        remove
        {
            // remove code goes here
        }
    }
}

All we now need is to ensure we capture the CoreDispatcher when the add method runs, and store that with the handler reference.

After my first post, Daniel Vistisen correctly pointed out that we can use SynchronizationContext instead of CoreDispatcher thus making the whole thing .NET Standard compliant:

Why not just use SynchronizationContext? Works with .netstandard

— Daniel Vistisen (@DanielVistisen) March 28, 2018

He is absolutely right, so that is what we will now do!

We will use a Dictionary<SynchronizationContext, PropertyChangedEventHandler> to keep a collection of event handlers for each SynchronizationContext.

In the end, this is what I got to:

public class MultiWindowViewModelBase : INotifyPropertyChanged
{
    private readonly object _lock = new object();
    private readonly Dictionary<SynchronizationContext, PropertyChangedEventHandler> _handlersWithContext = new Dictionary<SynchronizationContext, PropertyChangedEventHandler>();

    public event PropertyChangedEventHandler PropertyChanged
    {
        add
        {
            if (value == null)
            {
                return;
            }

            var synchronizationContext = SynchronizationContext.Current;

            lock (_lock)
            {
                if (_handlersWithContext.TryGetValue(synchronizationContext, out PropertyChangedEventHandler eventHandler))
                {
                    eventHandler += value;

                    _handlersWithContext[synchronizationContext] = eventHandler;
                }
                else
                {
                    _handlersWithContext.Add(synchronizationContext, value);
                }
            }
        }
        remove
        {
            if (value == null)
            {
                return;
            }

            var synchronizationContext = SynchronizationContext.Current;

            lock (_lock)
            {
                if (_handlersWithContext.TryGetValue(synchronizationContext, out PropertyChangedEventHandler eventHandler))
                {
                    eventHandler -= value;

                    if (eventHandler != null)
                    {
                        _handlersWithContext[synchronizationContext] = eventHandler;
                    }
                    else
                    {
                        _handlersWithContext.Remove(synchronizationContext);
                    }
                }
            }
        }
    }

    protected void OnPropertyChanged([CallerMemberName] string propertyName = null)
    {
        KeyValuePair<SynchronizationContext, PropertyChangedEventHandler>[] handlersWithContext;

        lock (_lock)
        {
            handlersWithContext = _handlersWithContext.ToArray();
        }

        var eventArgs = new PropertyChangedEventArgs(propertyName);

        foreach (var handlerWithContext in handlersWithContext)
        {
            var synchronizationContext = handlerWithContext.Key;
            var eventHandler = handlerWithContext.Value;

            synchronizationContext.Post(o => eventHandler(this, eventArgs), null);
        }
    }
}

Now all we need is to ensure that any view-model used on multiple windows, inherits from this base class.

Here’s a really simple example:

public class MainViewModel : MultiWindowViewModelBase
{
    private string _text;

    public string Text
    {
        get { return _text; }
        set
        {
            if (_text == value) return;

            _text = value;
            OnPropertyChanged();
        }
    }
}

Final thoughts

The ApplicationView.Consolidated event should be monitored to allow for proper cleaning, so that no memory leaks occur.

Here’s an example of how this can be achieved:

public sealed partial class MainPage : Page
{
    public MainViewModel ViewModel => App.MainViewModel;

    public MainPage()
    {
        DataContext = ViewModel;

        this.InitializeComponent();

        ApplicationView.GetForCurrentView().Consolidated += ApplicationView_OnConsolidated;
    }

    private void ApplicationView_OnConsolidated(ApplicationView s, ApplicationViewConsolidatedEventArgs e)
    {
        if (e.IsAppInitiated || e.IsUserInitiated)
        {
            s.Consolidated -= ApplicationView_OnConsolidated;

            DataContext = null;

            // this is only required if you are using compiled bindings (x:Bind)
            Bindings.StopTracking();
        }
    }
}

I’ve also made available a full sample on GitHub so you can see and test the whole solution! :)

Knowing this, please look at the following view-model:

// Basic implementation of the INotifyPropertyChanged interface

public abstract class BaseViewModel : INotifyPropertyChanged
{
    public event PropertyChangedEventHandler PropertyChanged;

    protected void OnPropertyChanged([CallerMemberName] string propertyName = null)
    {
        PropertyChanged?.Invoke(this, new PropertyChangedEventArgs(propertyName));
    }
}

// The main view-model

public class MainViewModel : BaseViewModel
{
    private string _result;

    public string Result
    {
        get { return _result; }
        set
        {
            _result = value;
            OnPropertyChanged("Result");
        }
    }

    public async Task RetrieveData()
    {
        var data = await GetDataFromSomeWebsite()
            .ConfigureAwait(false);

        Result = data;
    }

    // More code will go here...
}

The BaseViewModel is just a basic implementation of the INotifyPropertyChanged interface with a helper method that will raise the PropertyChanged event - all quite standard for any MVVM based application!

Now let us say that in the view we have a TextBox control, and that the Text property is binded to the MainViewModel.Result property.

Given this, you will probably notice a problem with the MainViewModel.RetrieveData method: after awaiting the call to GetDataFromSomeWebsite method, most likely we will not be on the UI thread due to the .ConfigureAwait(false) (if you dont know what ConfigureAwait is, please read this post). So, when we set the Result property on the next line which in turn will notify the UI that the property value has changed, that will cause an exception!

To fix it, we can use CoreApplication.MainView.Dispatcher to retrieve a CoreDispatcher instance that will then allow us to execute code in the UI thread.

With some minor changes, the MainViewModel.RetrieveData method now looks something like this:

public async Task RetrieveData()
{
    var data = await GetDataFromSomeWebsite()
        .ConfigureAwait(false);

    CoreApplication.MainView.Dispatcher(CoreDispatcherPriority.Normal, () =>
    {
        Text = data;
    });
}

For small view-models this approach is perfectly fine, but for bigger ones where multiple developers are working on, you might end up losing track of which properties you need to update in the UI thread and the ones you do not.

Wouldn’t it be great if you just didn’t have to worry about this?

To make our view-models completely oblivious of what is the current thread, we will need to make some changes to their base view-model!

The easiest way will be to capture the CoreDispatcher at start, and on the OnPropertyChanged method (or whatever you called your PropertyChanged event raising helper method), check if we need to dispatch the call or just raise the property regularly.

Here is our new and improved BaseViewModel:

public abstract class DispatcherAgnosticBaseViewModel : INotifyPropertyChanged
{
    public event PropertyChangedEventHandler PropertyChanged;

    private CoreDispatcher _dispatcher = CoreApplication.MainView.Dispatcher;

    protected void OnPropertyChanged([CallerMemberName] string propertyName = null)
    {
        if (_dispatcher.HasThreadAccess)
        {
            PropertyChanged?.Invoke(this, new PropertyChangedEventArgs(propertyName));
        }
        else
        {
            _dispatcher.RunAsync(CoreDispatcherPriority.Normal, () =>
            {
                PropertyChanged?.Invoke(this, new PropertyChangedEventArgs(propertyName));
            });
        }
    }
}

Notice that the first this we do is to check the CoreDispatcher.HasThreadAccess property; this property will return true if we are now on the UI thread, or false if we are not.

If we are, we can just raise the PropertyChanged event directly, but when we are not, we will do it by dispatching the call through the UI thread.

Now all we now need is to have every single view-model to inherit from this base class and we will never have to worry again about the dispatcher!

Well… not interely accurate, but I’ll leave that for another post ;)

The earlier article focused on a really nasty bug with the compiled bindings ignoring the FallbackValue when the binding path didn’t resolve.

It now seems that Microsoft finally fixed this bug on the Windows 10 SDK Preview Build 17069, and this fix will eventually make it’s way to the next stable release of the Windows 10 SDK!

There is, however, a small requirement to make this work: the compiled binding expression must have the FallbackValue set.

To better understand it, please check this line of code taken from the example in the part II article:

<TextBlock Style="{StaticResource BodyTextBlockStyle}" Text="{x:Bind ViewModel.CurrentTime.CurrentTimeTicks, Mode=OneWay}" />

On the above, we will now add FallbackValue={x:Null} to the binding expression:

<TextBlock Style="{StaticResource BodyTextBlockStyle}" Text="{x:Bind ViewModel.CurrentTime.CurrentTimeTicks, Mode=OneWay, FallbackValue={x:Null}}" />

This will ensure that this TextBlock gets the text cleared when the binding can’t resolve the path or source!

A classic binding does this by default (when FallbackValue isn’t set, it will just use null), but for compiled bindings, we need to specify a value.

More “hard work”, but a solution to the problem, nevertheless!

You know, that “old” XAML technology that started back when Windows XP was still a thing!

The interesting bit is that all my previous experience developing for Windows Phone did give me a lot of knowledge on how to write performant non-blocking code - and I am still learning something new every day!

These are some of my personal coding tips to help keep your app as responsive as possible!

Execute CPU bound code on a separate thread

Consider the following example:

private void CalculateButton_OnClick(object sender, RoutedEventArgs e)
{
    var total = MyLongRunningOperation();

    ResulTextBlock.Text = total.ToString();
}

The above code sample will run on the UI thread, and as it takes a while to run the MyLongRunningOperation method, it will make the app unresponsive until it finishes.

This is a perfect example of what CPU bound code is: code that should execute on a separate thread as to avoid blocking the UI thread while it runs.

There are a few ways to fix this problem and the easiest one is to just use Task.Run.

Now look at this alternative:

private async void CalculateButton_OnClick(object sender, RoutedEventArgs e)
{
    var total = await Task.Run(() => MyLongRunningOperation());

    ResulTextBlock.Text = total.ToString();
}

On the above code sample, we wrapped the call to MyLongRunningOperation method with a Task.Run that will force it to execute on a new separate thread, and then awaited for it to complete.

Note: Libraries should not lie about what they are doing! The UI thread is the only one that needs the asynchronous API, so it should be up to the end developer to decide when to use this, not 3rd party libraries ones!

Avoid using task.Result or task.Wait()

If use task.Result or call task.Wait() you will be blocking the current thread until that task completes, which is not ideal especially if the thread is the main UI thread!

A particular situation I see people doing this is for constructors; here’s an example:

public class TestClass
{
    private int _initialValue;

    public TestClass()
    {
        _initialValue = GetInitialValueTask().Wait(); // don't do this!
    }

    public int GetInitialValueDoubled()
    {
        return _initialValue * 2;
    }

    // other code...
}

The whole point of the .NET asynchronous model is to use the async and await keywords!

To avoid this issue, one could write the code like this:

public class TestClass
{
    private Task<int> _initialValueTask;

    public TestClass()
    {
        _initialValueTask = GetInitialValueTask(); // store the async task
    }

    public async Task<int> GetInitialValueDoubled()
    {
        var value = await _initialValueTask;

        return value * 2;
    }

    // other code...
}

Instead of blocking the thread like we did before, we just store the asynchronous task and when we need it, we ensure we access it from an async method so we can await on it!

Use task.ConfigureAwait(false) whenever possible

Developers should assume that the await keyword will make any call return to calling thread.

Consider the following sample code:

private async void CalculateButton_OnClick(object sender, RoutedEventArgs e)
{
    await IoBoundOperation();

    await AnotherIoBoundOperation();

    ResultTextBlock.Text = "Done!";
}

Both IoBoundOperation and AnotherIoBoundOperation have IO bound code, so they will most likely execute on separate threads.

Once these awaited calls finish and return, execution might resume on the calling thread, which in this case is the UI thread.

However, most likely this isn’t required, and we could just carry on execution on the same background thread.

Now look at the modified version of the sample code:

private async void CalculateButton_OnClick(object sender, RoutedEventArgs e)
{
    await IoBoundOperation()
        .ConfigureAwait(false);

    await AnotherIoBoundOperation()
        .ConfigureAwait(false);

    Dispatcher.RunAsync(CoreDispatcherPriority.Normal, () =>
    {
        ResulTextBlock.Text = total.ToString();
    });
}

We have now added .ConfigureAwait(false) to each awaited call as to avoid marshaling back to the calling thread.

Any code that needs to run on the UI thread (normally, to update the UI) can do so by using the Dispatcher.RunAsync method as seen above.

Consider using Deferred Events for your custom events

The rule of thumb on the asynchronous code is to avoid async void methods as much as possible, but for event handlers, there is no way to bypass this.

A while back I created the DeferredEvents NuGet package to mitigate this issue; at the time, I wrote an article that I now recommend reading to further understand the problem and my proposed solution.

The event will start with a keynote by Kevin Gallo and members of the Windows engineering team, followed by a live-streamed Q&A session and several streaming sessions diving deeper into what’s new for developers in the Windows 10 Fall Creators Update.

You might also want to check if there’s a viewing party in your area (check on the bottom of this post).

And if you’re around London on the next day…

… come to the next Windows Apps London meetup at 6:30 PM on October 11 and meet the Windows engineering team!

This is a relaxed in-person event, where you’ll get to ask a few more questions after the main Windows Developer Day!

Please check here for more details and registration.

A couple of weeks ago I decided to enroll into Xamarin University and after a few classes and a final exam, I’m now a Xamarin Certified Mobile Developer!

I love Windows Development and make no mistake: I intend to keep writing and working with full native UWP!!

But at this time it makes complete sense for someone who works with XAML and C# to also learn Xamarin, as this is the best Microsoft has for cross-platform development!

Xamarin University was a really good experience and I can definitely recommend it to everyone: people that just started coding with .NET and C#, experienced developers who want to learn Xamarin, or professional developers that just want to get Xamarin certified!

Over the last few months years quite a few people have written about the Windows Phone demise.

However, according to Microsoft’s Support Page for product life cycle, the “Mainstream Support End Date” for Windows Phone 8.1 is July 11, 2017… so that’s basically, tomorrow!

Microsoft’s last update for the WP8.x operating system (dubbed “Update 2”) was more than 2 years ago… so even if the “official” support only now ended, I think we can all agree that unofficially Microsoft abandoned the OS a long time ago (mostly when they replaced it with Windows 10 Mobile).

My own experience with Windows Phone

Microsoft announced Windows Phone 7 at the Mobile World Congress in Barcelona, Spain, on February 15, 2010; I remember that the more I saw those screens and learned about the promised capabilities and technical details, the more I knew that I wanted to build apps for it, both as a hobby and professionally - and do so I did!!

When they released the first Windows Phone devices on October 21, 2010 in Europe, I went straight to a local shop and bought my very first Windows Phone: the magnificent Samsung Omnia 7.

Soon after that, Microsoft and Nokia got into a partnership to boost the operating system footprint, and as a consequence I ended up leaving Portugal and moving to Bristol UK to join the Nokia Music division, later known as MixRadio!

Nokia’s first Windows Phone was the Lumia 800, one of the best phones I have ever owned (I actually kept one of these as a souvenir)

By my account, throughout the years I owed and used at least 12 different Windows Phone devices, mostly due to my time as Nokia employee.

I also got to do a lot tech-talks on Windows Phone development, and participated in a few hackathons, helping the young and brightest with their projects.

“The King is dead, long live the King!”

Microsoft arrived late to the “mobile party” and made lots of mistakes (the lack of software upgrades for “older” devices, some less than a year old, being the biggest), but it was the lack of true first-party apps that caused users to lose interest in the phones and doomed the mobile operating system.

Windows 10 makes good on the promise of “one Windows for all devices”, but the mobile flavor never did get the same praise as the Windows Phone did - and I strongly agree with that!

I enjoyed all my Windows Phone devices, and I will miss using them a lot… but life goes on!

Farewell, Windows Phone.

Yesterday I released Cimbalino Toolkit version 2.5.0!

Here’s what’s changed on this version:

• Cimbalino.Toolkit.Core now targets the .NET Standard 1.0
• Cimbalino.Toolkit.Core will now behave as the rest of the toolkit in regards to throwing NotImplementedExceptions only on specific cases
• Exposed overrideable async methods in ExtendedPageBase
• Other fixes and improvements

From the above, I’d like to emphasise the huge advantage of supporting .NET Standard 1.0: this means you can now use Cimbalino.Tookit.Core in all .NET platforms: .NET Framework, .NET Core, and Mono!

Well, things haven’t changed much since then, and the information in that article still stands today!

However, Microsoft has since open-sourced the .NET Core Runtime (CoreRT), and that allowed me to take a peek under the hood to understand what is going on.

While looking at the CultureInfo.cs code, I noticed the following comment on the CurrentCulture property:

We use the following order to return CurrentCulture and CurrentUICulture

• Use WinRT to return the current user profile language
• Use current thread culture if the user already set one using CurrentCulture/CurrentUICulture
• Use thread culture if the user already set one using DefaultThreadCurrentCulture or DefaultThreadCurrentUICulture
• Use NLS default user culture
• Use NLS default system culture
• Use Invariant culture

This confirms our findings!

Looking on the CultureInfo.Windows.cs partial class, I noticed the #if ENABLE_WINRT on the top, which forces the first rule on that comment!

Further down in the same file, we find a GetUserDefaultCulture method which uses the GetLocaleInfoEx Win32 API to retrieve the locale name.

This Win32 API is actually allowed for apps published to the Windows Store!

Retrieving the “proper” CurrentCulture, the proper way!

In my previous article on this subject, I found a hack where one could retrieve the “proper” CurrentCulture using the DateTimeFormatter class.

But with all this new information, I have now created a non-hacky way of doing the same:

using System.Globalization;
using System.Runtime.InteropServices;
using System.Text;

public class CultureInfoHelper
{
    [DllImport("api-ms-win-core-localization-l1-2-0.dll", CharSet = CharSet.Unicode)]
    private static extern int GetLocaleInfoEx(string lpLocaleName, uint LCType, StringBuilder lpLCData, int cchData);

    private const uint LOCALE_SNAME = 0x0000005c;
    private const string LOCALE_NAME_USER_DEFAULT = null;
    private const string LOCALE_NAME_SYSTEM_DEFAULT = "!x-sys-default-locale";

    private const int BUFFER_SIZE = 530;

    public static CultureInfo GetCurrentCulture()
    {
        var name = InvokeGetLocaleInfoEx(LOCALE_NAME_USER_DEFAULT, LOCALE_SNAME);

        if (name == null)
        {
            name = InvokeGetLocaleInfoEx(LOCALE_NAME_SYSTEM_DEFAULT, LOCALE_SNAME);

            if (name == null)
            {
                // If system default doesn't work, use invariant
                return CultureInfo.InvariantCulture;
            }
        }

        return new CultureInfo(name);
    }

    private static string InvokeGetLocaleInfoEx(string lpLocaleName, uint LCType)
    {
        var buffer = new StringBuilder(BUFFER_SIZE);

        var resultCode = GetLocaleInfoEx(lpLocaleName, LCType, buffer, BUFFER_SIZE);

        if (resultCode > 0)
        {
            return buffer.ToString();
        }

        return null;
    }
}

All you need is to copy the above to a file in your UWP project, and then call CultureInfoHelper.GetCurrentCulture().

I strongly advise using this new method instead of the “hack” I used in my previous article, as this is the same one that the .NET Framework relies on to retrieve the CurrentCulture information!

While these two configurations are enough for most projects, some might actually require custom build configurations that will support different environments, alternative build targets, etc..

Until now we could use Visual Studio Configuration Manager to easily create a copy an existing configuration setup, and then change small bits to match our specifications.

But now there’s a new csproj format for .NET Core, and while it includes the expected Debug and Release build configurations, the “copy configuration” process doesn’t work anymore!

The problem is that the new project format is based in quite a few implicit defaults, so Visual Studio Configuration Manager can’t actually create a copy of the existing build configurations with all the properties set.

Introducing the MSBuild Configuration Defaults

As I couldn’t find a way to “inherit” from the base Debug and Release build configurations, I tried to understand what properties were actually required on each of them, and then create some build scripts that would set them for me!

Those MSBuild scripts are available here and can easily be installed by running Install-Package MSBuildConfigurationDefaults on the Package Manager Console, or added with the Visual Studio NuGet Packages Manager.

After adding the NuGet package, I recommend closing and re-opening the solution to ensure that the build scripts are correctly loaded.

Usage

Once installed, any custom build configuration name starting or ending on “Debug” will have the following build properties set by default:

<DefineConstants>$(DefineConstants);DEBUG;TRACE</DefineConstants>
<DebugSymbols>true</DebugSymbols>
<DebugType>full</DebugType>
<Optimize>false</Optimize>

Similarly, any custom build configuration name starting or ending on “Release” will have the following build properties set by default:

<DefineConstants>$(DefineConstants);RELEASE;TRACE</DefineConstants>
<DebugSymbols>false</DebugSymbols>
<DebugType>portable</DebugType>
<Optimize>true</Optimize>

If any of these properties are set on the project, those values will have override the defaults above.

If you don’t want to name your custom build definition according to the rules above, just add a ConfigurationGroup property and set the value to Debug or Release to ensure those build definitions get the appropriate default properties set.

The following is an example of a custom build configuration called “Production”, that has the ConfigurationGroup set to “Release” (so it gets the default property values set as for the a “Release” build configuration), but also overrides the DebugSymbols property default value:

<PropertyGroup Condition="'$(Configuration)' == 'Production'">
  <ConfigurationGroup>Release</ConfigurationGroup>
  <DebugSymbols>true</DebugSymbols>
</PropertyGroup>

Developers should avoid async void methods, but there are some situations where this is a “necessary evil”, and event handlers are one of those cases.

If one needs to use the await keyword inside an event handler code, the method itself must be async void

The following is an example of this:

public sealed partial class MainPage : Page
{
    public MainPage()
    {
        InitializeComponent();

        Loaded += MainPage_Loaded;
    }

    private async void MainPage_Loaded(object sender, Windows.UI.Xaml.RoutedEventArgs e)
    {
        await DoSomethingAsync();

        await DoSomethingMoreAsync();
    }
}

On the above example, the MainPage_Loaded is an async void method that will as it needs to await for the completion of some of its calls, but sometimes we also need to allow the event invoker to wait for all handlers to complete.

Inspired on how the background tasks use a deferral approach to solving this problem (as they too are void methods), I came up with a similar approach!

Introducing the Deferred Events

A “deferred event” is basically an event that allows the invoker to wait for the completion of all event handlers.

My personal implementation is available on the DeferredEvents NuGet package that you can install by running Install-Package DeferredEvents on the Package Manager Console, or add with Visual Studio NuGet Packages Manager.

This is a .NET Standard 1.0 package, so you should be able to use it on any .NET project!

If you want to take a look at what’s inside, the full source code is available here.

Usage

Here is an example of a deferred event:

public event EventHandler<DeferredEventArgs> MyEvent;

The only difference here to a regular event is that the event arguments have to be of type DeferredEventArgs (or a custom class inheriting from them), and that’s what allows the whole thing to work!

Now take a look at how we raise this event:

await MyEvent.InvokeAsync(sender, new DeferredEventArgs());

The InvokeAsync() is an extension method that will wait for all event handlers to finish their work before we proceed.

And finally, here’s how our event handler looks like:

public async void OnMyEvent(object sender, DeferredEventArgs e)
{
    var deferral = e.GetDeferral();

    await DoSomethingAsync();

    deferral.Complete();
}

The trick here is to call e.GetDeferral() to retrieve a deferral object, and just before we exit the method, we do deferral.Complete() to notify the invoker that we have completed our work!

There are a few rules that you have to be aware of:

• You only need to call e.GetDeferral() if you actually want to the event caller to wait for the completion of the event handler; if you don’t call it, it will just behave as a regular event handler.
• You must call e.GetDeferral() to get an EventDeferral instance before any await call in your code to ensure that the event caller knows that it should wait for deferral.Complete(); ideally, it should be the first thing you do in the event handler code.
• If you have indeed called e.GetDeferral(), then you must call deferral.Complete() to signal that the event handler has finished.

To ensure the correct usage of the deferred events, use the following as a template for your event handlers:

public async void OnMyEvent(object sender, DeferredEventArgs e)
{
    var deferral = e.GetDeferral();

    try
    {
        // awaiteable code
    }
    finally
    {
        deferral.Complete();
    }
}

Alternatively, you can also use the using pattern like this:

public async void OnMyEvent(object sender, DeferredEventArgs e)
{
    using (e.GetDeferral())
    {
        // awaiteable code
    }
}

That’s quite easy to do if you only use Windows.Web.Http.HttpClient as there’s a managed property for that purpose: HttpClient.DefaultRequestHeaders.UserAgent.

Similarly, the same applies for System.Net.Http.HttpClient and the HttpClient.DefaultHeader.UserAgent property.

The real problem is if you need to use the WebView control to present web content, as there’s no managed property to change the user-agent!

It is possible to create a HttpRequestMessage instance, set a custom user-agent string in it, and then call the WebView.NavigateWithHttpRequestMessage method, but that will only work for that specific navigation request.

Any requests invoked from inside the webview (like a form post) will use the system default user-agent string.

So what’s the solution?

The solution comes in the form of a Win32 API called UrlMkSetSessionOption.

Amongst other things, this API allows you to set the default user-agent string for the current internet session!

Here’s an example of how to use it; first, add the following class to your app:

public class UserAgentHelper
{
    [DllImport("urlmon.dll", CharSet = CharSet.Ansi, ExactSpelling = true)]
    private static extern int UrlMkSetSessionOption(int dwOption, string pBuffer, int dwBufferLength, int dwReserved);

    private const int URLMON_OPTION_USERAGENT = 0x10000001;

    public static void SetDefaultUserAgent(string userAgent)
    {
        UrlMkSetSessionOption(URLMON_OPTION_USERAGENT, userAgent, userAgent.Length, 0);
    }
}

Now load your App.xaml.cs file and ensure you call the UserAgentHelper.SetDefaultUserAgent() method inside the App class constructor:

public App()
{
    // remaining code

    UserAgentHelper.SetDefaultUserAgent("MyApp/1.0");
}

From that point on, any webview inside your app will use the specified user-agent string (“MyApp/1.0” in our example above)!

One final note: only a few Win32 API’s are actually allowed in apps published to the Windows Store (you can check the complete list here)!

The Windows Store recently allowed for apps to use the UrlMkSetSessionOption API, but if you look at the list above you will notice that it’s not yet listed; that should change once Microsoft updates the list on that page.

Kudos to Hermit Dave for pointing me in the right direction for a solution for this problem!

Last week I noticed that the blog was down, and when I opened GoDaddy’s shared hosting administration area, I got a database connection error message.

I then did what anyone in this situation would do: get help!

However, contacting GoDaddy support proved completely useless, as all I got was something along the lines of “yes, there’s a problem and we’re working on to fix it; no, we don’t know when it’s gonna be fixed, so please try later”…

Just had a chat with @GoDaddy support, their server is down and all I got was "we know it's down, just try later..." #fail @GoDaddyHelp

— Pedro Lamas (@pedrolamas) March 7, 2017

After some 5 hours, the blog was back up and running… but there was a big problem: some content had disappeared!

I’m guessing they had some problem with the database server, and their “fix” involved recovering the databases from an old backup.

Seems @GoDaddy hosting admins "fix" was to RECOVER AN OLD DATABASE BACKUP, so all my latest changes have been lost... @GoDaddyHelp https://t.co/ROROWqxfQP

— Pedro Lamas (@pedrolamas) March 10, 2017

That was the final reason I needed to completely ditch WordPress and GoDaddy, and migrate to something faster and more recent: this blog is now fully powered by Jekyll and hosted in GitHub Pages!

Major advantages of this approach are:

• No more MySQL or any other database server involved
• full control over rendered content
• everything is statically generated on every commit of the git repo, so it’s blazing fast!
• I can host it for free in GitHub Pages and add some nice features like allowing other people to send me Pull Requests with fixes and improvements (or just to correct my recurrent typos!)

This right now is actually the first post I write in the new platform! :)

There are still a few quirks to fix, so if you find any problem please report it by creating a new issue and I’ll take care of it as soon as possible!

It is with great pride that I received the Microsoft Most Valuable Professional (MVP) Award 2017 for Windows Development!

From the Microsoft MVP award overview page:

“…the Microsoft MVP Award is our way of saying “Thanks!” to outstanding community leaders.”

This is my first MVP Awards and to me feels like the top recognition for all the work I’ve been doing for the past few years with the community around Microsoft Technologies, particularly in Windows and Windows Phone development.

I consider this award as a personal achievement, but it is one that I could not have accomplished without the help and support of some people, specifically:

• Scott Lovegrove, Joost van Schaik, Glenn Versweyveld, Hermit Dave, Sébastien Lachance, Bart Lannoeye, and quite a few other distinguished MVP’s!
• Alberto Silva, Sandro Pereira, Tiago Pascoal, Paulo Morgado, and other fellow Portuguese MVP’s!
• Luis Calado, João Pedro Martins, Clint Rutkas, and quite a few other Microsoft employees!
• my wife, Joana, who has the patience to put up with me doing “geeky” stuff all the time!

…and finally but most importantly, the whole community, who reads my blog, follows me on twitter, checks my code contributions, downloads my apps, and gives me the opportunity to carry on doing what I’ve done so far and that will continue to improve in the future!

Thanks! :)

Adaptive triggers will not work if you are trying to change a control whose instance name is the same as one of the VisualStates of any control on the page, so make sure you name your controls accordingly!

The long run…

I recently came to discover what I believe to be a UWP platform bug related to how one names the instance controls and how these may collided with the VisualState names!

Let’s take the following sample code for a simple AdaptiveTrigger usage example:

<Grid Background="{ThemeResource ApplicationPageBackgroundThemeBrush}">
    <Button x:Name="MyButton" Content="I don't do anything!" />

    <VisualStateManager.VisualStateGroups>
        <VisualStateGroup x:Name="VisualStateGroup">
            <VisualState x:Name="VisualStateNarrow">
                <VisualState.StateTriggers>
                    <AdaptiveTrigger MinWindowWidth="0" />
                </VisualState.StateTriggers>
                <VisualState.Setters>
                    <Setter Target="MyButton.Background" Value="Red" />
                </VisualState.Setters>
            </VisualState>

            <VisualState x:Name="VisualStateNormal">
                <VisualState.StateTriggers>
                    <AdaptiveTrigger MinWindowWidth="600" />
                </VisualState.StateTriggers>
                <VisualState.Setters>
                    <Setter Target="MyButton.Background" Value="Green" />
                </VisualState.Setters>
            </VisualState>
        </VisualStateGroup>
    </VisualStateManager.VisualStateGroups>
</Grid>

Here we can see we have a Button called “MyButton”, who’s background color will change accordingly to the window size: if the window width is above 600, the button will be green, and if it is below 600, it will be red.

Now here’s how it looks when we run the sample code:

Works exactly as expected! :)

If you take a look at the Button styles and templates, you will find out that the Button control contains the following named VisualStates: “Normal”, “PointerOver”, “Pressed”, “Disabled”.

Given this information, let’s rename our button from “MyButton” to “Pressed”:

<Grid Background="{ThemeResource ApplicationPageBackgroundThemeBrush}">
    <Button x:Name="Pressed" Content="I don't do anything!" />

    <VisualStateManager.VisualStateGroups>
        <VisualStateGroup x:Name="VisualStateGroup">
            <VisualState x:Name="VisualStateNarrow">
                <VisualState.StateTriggers>
                    <AdaptiveTrigger MinWindowWidth="0" />
                </VisualState.StateTriggers>
                <VisualState.Setters>
                    <Setter Target="Pressed.Background" Value="Red" />
                </VisualState.Setters>
            </VisualState>

            <VisualState x:Name="VisualStateNormal">
                <VisualState.StateTriggers>
                    <AdaptiveTrigger MinWindowWidth="600" />
                </VisualState.StateTriggers>
                <VisualState.Setters>
                    <Setter Target="Pressed.Background" Value="Green" />
                </VisualState.Setters>
            </VisualState>
        </VisualStateGroup>
    </VisualStateManager.VisualStateGroups>
</Grid>

This is the result if you run the code again:

What you see here is that the initial state was in fact applied, but it failed to change once we started to change the window size as it was supposed to!

Further testing made me aware that this is not only influenced by the visual states of the control we are manipulating, but by all controls on the page!

As an example of this, on the following code we have now added a ComboBox control, which will also fail the adaptive changes as I named our button Focused which matches one of the ComboBox visual states:

<Grid Background="{ThemeResource ApplicationPageBackgroundThemeBrush}">
    <Button x:Name="Focused" Content="I don't do anything!" />
    <ComboBox />

    <VisualStateManager.VisualStateGroups>
        <VisualStateGroup x:Name="VisualStateGroup">
            <VisualState x:Name="VisualStateNarrow">
                <VisualState.StateTriggers>
                    <AdaptiveTrigger MinWindowWidth="0" />
                </VisualState.StateTriggers>
                <VisualState.Setters>
                    <Setter Target="Focused.Background" Value="Red" />
                </VisualState.Setters>
            </VisualState>

            <VisualState x:Name="VisualStateNormal">
                <VisualState.StateTriggers>
                    <AdaptiveTrigger MinWindowWidth="600" />
                </VisualState.StateTriggers>
                <VisualState.Setters>
                    <Setter Target="Focused.Background" Value="Green" />
                </VisualState.Setters>
            </VisualState>
        </VisualStateGroup>
    </VisualStateManager.VisualStateGroups>
</Grid>

I’ve reported this issue to Microsoft, so for now all we can do is to be aware of it and make sure we name our controls so not to use the same names as any of their visual states!

I know the blog as been quite a bit quiet for the last couple of months, but I just wanted to let you know that Cimbalino Toolkit version 2.4.0 is now available!

As I didn’t put a blog post for the previous version, here’s the complete change log for everything since 2.2.0 till the current 2.4.0:

• Now targeting SDK 14393 (Windows 10 Anniversary edition)
• New MasterDetailView control (UWP only)
• New ExtendedPageBase class, IHandleNavigatingFrom, IHandleNavigatedFrom and IHandleNavigatedTo interfaces (allows handling of Page.OnNavigatingFrom(), Page.OnNavigatedFrom() and Page.OnNavigatedTo() methods from inside view models)
• New BooleanToObjectConverter, CollectionCountToObjectConverter, ComparableToObjectConverter, EmptyCollectionToObjectConverter, and EmptyStringToObjectConverter
• Added CancellationToken support to IMessageBoxService and ILocationService
• HamburgerMenuButton will now allow parameter check for button highlighting
• Improvements over the INavigationService interface and implementation
• Other fixes and improvements

If you have a Raspberry Pi 3 running Windows 10 Core IoT and the 7” touch display, then this post is for you!

Assuming you already installed the Windows 10 IoT in your Pi 3 and that it is currently up and connected to the network, you can open the Windows 10 IoT Core Dashboard, go to the “My Devices” tab and find your device listed there.

If you now click the “Open in Device Portal” option, the browser will launch, ask you to login with your credentials, and then show you the “Home” page of the Device Portal.

On the bottom you will find the “Display Orientation” option:

Given my touch screen is placed upside down, I changed this setting to “Landscape (Flipped)”, and after rebooting the device I noticed that it flipped the touch screen display as requested, but it didn’t also flip the touch targets (so you’ll need to mentally rotate every point you touch on the screen to make it do what it is supposed to do)!

Under the hood, what this setting is doing is adding display_rotation=2 to the Raspberry Pi “config.txt” file, but that’s not the proper way of doing this for the touch screen!

After reading the Raspberry Pi Display troubleshooting, I realized that one should use lcd_rotate=2 instead, which will rotate the lcd display and touch targets!

So the fix is quite easy: just open the \\<your-pi-ip-address>\c$ network share, go to the “EFIESP” folder and inside of it, find and edit the “config.txt” file!

Remove any display_rodate entry and add lcd_rotate=2 to the end of the file, save, reboot the Pi, and that should fix the problem completely! :)

Update: there was a packaging error in 2.2.0 which I already fixed and so the most current version is now 2.2.1!

Cimbalino Toolkit version 2.2.0 is now available!

This new version includes improved support for Windows Phone Silverlight 8.1 (WP81) so that developers can take advantage of its specific API’s (such as the FileOpenPicker)

This brings the total number of supported platforms to 5:

• Windows Phone Silverlight 8.0 apps (WP8)
• Windows Phone Silverlight 8.1 apps (WP81)
• Windows Phone 8.1 apps (WPA81)
• Windows Store 8.1 apps (Win81)
• Windows 10 UWP apps (UAP)

Here’s the full change log for version 2.0.0:

• Improved compatibility with Windows Phone Silverlight 8.1 (WP81)
• New Cimbalino.Toolkit.Controls library (includes the HamburgerFrame for Windows 10)
• New IFilePickerService to handle the file picker (when available)
• Improvements over the INavigationService implementation
• Other fixes and improvements

Most Windows 10 native apps already show this new pattern, even a classic like the Calculator app!

However, for reasons unknown, Microsoft didn’t provide any Hamburger related control on the SDK base controls… frankly, this move brings back to memory when Windows Phone 7 SDK was launched without the Panorama and Pivot controls, the foundation of the whole “Metro” design guidelines!

The only alternative I’ve found is to use the Template 10, a “set of Visual Studio project templates”!

However, I’ve found that Template 10 version for Hamburger adds a bit of too much “fat” for my own taste, hence why I’ve been working on an alternative for the past last few weeks!

Introducing the Cimbalino Toolkit Controls

Starting with version 2.2.0 (currently still in beta 1), the Cimbalino Toolkit will feature a new package called Cimbalino.Toolkit.Control, and as the name suggests, it’s a control library for app developers.

Currently, the package features 3 controls:

• HamburgerFrame
• HamburgerTitleBar
• HamburgerMenuButton

HamburgerFrame

Starting from the top, the HamburgerFrame control is a full replacement for the native Frame root control used in the app.xaml.cs file.

The control provides 3 content containers represented by the Header, SubHeader, and Pane properties, and on the center, it will show the navigated content:

Obviously, you can specify content for this containers however you would like, or just leave them blank!

The Header allows content to be presented above the Pane, so it will never be hidden by it:

The SubHeader allows content to be presented on the right side of the Pane. This means that if the pane is in one of the “overflow” modes it will show on top of this container, hiding the content behind it:

The control also provides background properties for all these containers (HeaderBackground, SubHeaderBackground, and PaneBackground).

To make the life easier of developers, I’ve “borrowed” the VisualStateNarrowMinWidth, VisualStateNormalMinWidth, and VisualStateWideMinWidth properties from Template 10, which allow to specify the break points where the pane state and location will readjust. If you don’t want to use these, you can always do it manually with the exposed pane related properties (IsPaneOpen, DisplayMode, OpenPaneLength, CompactPaneLength, …).

HamburgerTitleBar

The HamburgerTitleBar control provides a basic Hamburger button on the left side (can be hidden with the MenuButtonVisibility property), and a Title property.

This is a quite rudimentar and easy to use control, yet developers might want to just go ahead and create their own version of this control and place it on their apps!

HamburgerMenuButton

Finally, the HamburgerMenuButton is the button you’ll be using in the pane to indicate the available menu options!

This control shows a left-side icon and an optional label (through the Icon and Content properties):

The regular approach here will be to just place all the HamburgerMenuButton controls inside a vertical StackPanel, but one can also stack them horizontally, and in this case, we would only show the icon and hide the label (using the provided LabelVisibility property).

The NavigationSourcePageType property allow developers to specify the destination page type for navigation purposes. If the property is set, the button will automatically highlight anytime the page is the frame current navigation content.

So how can I use these in my app?

First step is to add the Cimbalino.Toolkit.Controls NuGet package to the project!

Then, create a new user control to define your menu; in it, add as many HamburgerMenuButton instances as the number of options you want to present!

Here’s how your menu might look like:

<UserControl x:Class="App1.View.HamburgerPaneControl"
             xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
             xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
             xmlns:controls="using:Cimbalino.Toolkit.Controls"
             xmlns:d="http://schemas.microsoft.com/expression/blend/2008"
             xmlns:mc="http://schemas.openxmlformats.org/markup-compatibility/2006"
             xmlns:view="using:App1.View"
             d:DesignHeight="300"
             d:DesignWidth="400"
             mc:Ignorable="d">

    <Grid>
        <Grid.RowDefinitions>
            <RowDefinition />
            <RowDefinition Height="Auto" />
        </Grid.RowDefinitions>

        <StackPanel>
            <controls:HamburgerMenuButton Content="Home" NavigationSourcePageType="view:MainPage">
                <controls:HamburgerMenuButton.Icon>
                    <FontIcon FontSize="16" Glyph="& #xE80F;" />
                </controls:HamburgerMenuButton.Icon>
            </controls:HamburgerMenuButton>

            <controls:HamburgerMenuButton Content="Details" NavigationSourcePageType="view:DetailsPage">
                <controls:HamburgerMenuButton.Icon>
                    <FontIcon FontSize="16" Glyph="& #xE8BC;" />
                </controls:HamburgerMenuButton.Icon>
            </controls:HamburgerMenuButton>
        </StackPanel>

        <controls:HamburgerMenuButton Grid.Row="1"
                                  Content="Settings"
                                  NavigationSourcePageType="view:SettingsPage">
            <controls:HamburgerMenuButton.Icon>
                <FontIcon FontSize="16" Glyph="& #xE713;" />
            </controls:HamburgerMenuButton.Icon>
        </controls:HamburgerMenuButton>
    </Grid>
</UserControl>

Next, open the app.xaml.cs file and replace this line:

rootFrame = new Frame();

with this:

rootFrame = new Cimbalino.Toolkit.Controls.HamburgerFrame()
{
    Header = new Cimbalino.Toolkit.Controls.HamburgerTitleBar()
    {
        Title = "App1"
    },
    Pane = new View.HamburgerPaneControl()
}

Congratulation: your app now has a universal Hamburger menu with a nice title bar! :)

Next steps might be to create a separate user control to hold the HamburgerTitleBar, which will then allow you to bind the Title property to view model (making it easier to update on a page by page basis).

To make things easier, I’ve provided the source code for a simple app using these controls!

Update: Though the information and concerns in this blog post are still very true, I’ve actually had a change of heart and I’m now advocating to Start Strong-Naming your Assemblies!!

For far to long, Strong-Named Assemblies have been a huge rock in the shoe of 3rd party library developers, but people: it’s 2016, so why are you still using it?

How it all started…

The year was 2002 (or so I believe!), Microsoft had just released the .NET Framework, and one of the main enterprise focused features was the ability to sign an assembly with a strong-name.

Back then, Strong-Named Assemblies had some great advantages, as indicated in this MSDN article:

• You want to enable your assemblies to be referenced by strong-named assemblies, or you want to give friend access to your assemblies from other strong-named assemblies.
• An app needs access to different versions of the same assembly. This means you need different versions of an assembly to load side by side in the same app domain without conflict. For example, if different extensions of an API exist in assemblies that have the same simple name, strong-naming provides a unique identity for each version of the assembly.
• You do not want to negatively affect performance of apps using your assembly, so you want the assembly to be domain neutral. This requires strong-naming because a domain-neutral assembly must be installed in the global assembly cache.
• When you want to centralize servicing for your app by applying publisher policy, which means the assembly must be installed in the global assembly cache.

So strong-named assemblies are uniquely identified, which is a good thing, until it starts to work against you…

Let’s look at a real example: a few years back, JSON.net was actually a strongly-signed assembly. Now let’s assume we have a project that depends on “LibraryA” and “LibraryB”, and each of these require a different version of JSON.net.

If you build the project as it currently is, there will be a conflict as you can only have a single version of JSON.net on the output folder, but the libraries require different versions…

To fix this issue, .NET provided a mechanism called Assembly Binding Redirection to ensure that only one specific assembly would be used, regardless of the required version.

In comes Silverlight and Windows Phone

Unfortunately, neither Silverlight nor Windows Phone support Assembly Binding Redirection… and that is where the true problems started.

There are quite a few threads around this issue over the internet, and in the end, a lot of 3rd party library developers just decided to stop strong-naming their assemblies!

Others, followed the advice of the MSDN article I pointed above:

If you are an open-source developer and you want the identity benefits of a strong-named assembly, consider checking in the private key associated with an assembly into your source control system.

Obviously, for this to work you would have to build your own versions of your project dependencies… and let’s be honest here: that will eventually be more of a problem that a solution.

A few years ago, I personally felt this pain while developing a Windows Phone app, and so I went to the Windows Phone Developers UserVoice website and requested the support for Assembly Binding Redirection on Windows Phone… almost a year after the request, I got an update indicating it was “on the backlog”, and seems it has stayed like that till now…

If it is such a bad thing, why are people still doing it?

Developers seem to have the wrong notion that they should strong-name their assemblies as a security feature, but this could not be further away from the truth!

Granted, that does provide a basic insurance that an assembly hasn’t been tampered/altered, but in any case one can always use binding redirection (when available) to bypass the whole thing, so that is just a lame excuse to not buy a proper Code Signing Certificate and apply Authenticode to the assembly (which will prevent tampering AND impersonation, the right way!).

What about the Universal Windows Platform?

Unfortunately, as far as I know there is no support for Assembly Binding Redirection in UWP…

A couple of weeks ago, Microsoft open-sourced the XAML Behaviors and guess what? Yes you guessed correctly: they strongly-signed it!

Fortunately, after a long debate on that same thread, they realized that it made no sense to do that, and removed the strong-name signing on the latest version!

Bottom line

With this article I tried to make the point that Strong-Named Assemblies are just legacy of the “old” .NET Framework days, and have no place in the modern Universal Windows Platform.

Hopefully, 3rd party developers will continuously provide non-strongly-named assemblies which will make a lot of developers happy.

Among other changes, this version contains two fixes that I personally contributed for issues found in the EventTriggerBehavior:

• Ensured EventTriggerBehavior unregisters the event handler
• Properly check for Windows Runtime events in EventTriggerBehavior

The NuGet package has been updated so if you’re using the Xaml Behaviors in your app, all you need is to let NuGet take the latest version of the package!

In the next days I’ll be releasing a new version of the Cimbalino Toolkit to take this updated Xaml Behaviors package.

Update 24/02/2016:

I forgot to mention a massive difference on the new version of the XAML Behaviors:

If you use PowerShell to output the Assembly Full Name from the current and previous versions of the XAML Behaviors, this is what you will get:

Notice the different PublicKey value?

Well, after a long discussion about it, seems Microsoft has finally decided in removing the StrongName signing!

Though this might not sound as an important change, it is fundamentally a sign of ditching the “old” legacy .NET Framework stuff.

But I’ll leave that for a next post… ;)

Asynchronous code is a modern abstraction of multi-threading execution, and as you hopefully are aware, in .NET land, this is achieved with the async and await keywords.

For the Universal Windows Platform, we can also count on the CoreDispatcher class to marshal execution back to the main thread, from which we can update the UI of our apps.

Here’s a simple example of how to use it:

public async void DoStuff()
{
    var dispatcher = CoreApplication.MainView.CoreWindow.Dispatcher;

    await dispatcher.RunAsync(CoreDispatcherPriority.Normal, () =>
    {
        UpdateUI();
    });

    DoOtherStuff();
}

Assuming we are on a background thread when the DoStuff() method is invoked, we will retrieve a CoreDispatcher instance from the CoreWindow.CoreDispatcher property, call and await for the execution of dispatcher.RunAsync() method, which in turn will invoke the UpdateUI() method on the main thread, and then code execution will continue in the background thread by invoking the DoOtherStuff() method.

As it is right now, we know that DoOtherStuff will only execute after the UpdateUI() method finishes, but now let’s assume that we replace the UpdateUI() synchronous method with an asynchronous version of it, called UpdateUIAsync():

public async void DoStuff()
{
    var dispatcher = CoreApplication.MainView.CoreWindow.Dispatcher;

    await dispatcher.RunAsync(CoreDispatcherPriority.Normal, async () =>
    {
        await UpdateUIAsync();
    });

    DoOtherStuff();
}

In this new version of the code, you’ll notice that the DoOtherStuff() method will eventually run before the UpdateUIAsync() has finished, which might not be what you intended to in the first place when you await’ed for the dispatcher.RunAsync() method!

This is due to the fact that the CoreDispatcher.RunAsync method has a DispatchedHandler callback which is not asynchronous:

public delegate void DispatchedHandler()

The fact that we’ve added the async/await keywords to the callback doesn’t ensure that the caller will await for it to execute!

There are a few ways suspend the background thread execution until the foreground thread signals for it to continue, and using a TaskCompletionSource<T> is one of the easiest:

public async void DoStuff()
{
    var dispatcher = CoreApplication.MainView.CoreWindow.Dispatcher;
    var taskCompletionSource = new TaskCompletionSource<bool>();

    await dispatcher.RunAsync(CoreDispatcherPriority.Normal, async () =>
    {
        await UpdateUIAsync();

        taskCompletionSource.SetResult(true);
    });

    await taskCompletionSource.Task;

    DoOtherStuff();
}

In this version of the code, once the execution returns from await’ing the dispatcher.RunAsync() call, the background thread will carry on execution, but will then await for the taskCompletionSource.Task to finish, which will only happen after the taskCompletionSource.SetResult(true) call that we make in the main thread!

I’ve written a few CoreDispatcher extension methods to help around this issue, and added them to the next version of the Cimbalino Toolkit, but you can access them right now if you wish so! ;)

A few months ago I wrote my first Compiled Bindings considerations article, and seems that time has come to write some more, only this time I’m bearer of some bad news…

TL;DR

Compiled Bindings have a bug, noticeable in some scenarios, specifically when a binding has a fallback value of null (which is the default)!

Make sure to thoroughly test your app if you use compiled bindings!

So what is the big deal?

To illustrate the problem, I’ve written a small demo app!

Let’s start by checking the view models code:

public abstract class ViewModelBase : INotifyPropertyChanged
{
    public event PropertyChangedEventHandler PropertyChanged;

    protected virtual void OnPropertyChanged([CallerMemberName] string propertyName = null)
    {
        PropertyChanged?.Invoke(this, new PropertyChangedEventArgs(propertyName));
    }
}

public class MainViewModel : ViewModelBase
{
    private CurrentTimeViewModel _currentTime;

    public CurrentTimeViewModel CurrentTime
    {
        get { return _currentTime; }
        set
        {
            _currentTime = value;
            OnPropertyChanged();
        }
    }
}

public class CurrentTimeViewModel : ViewModelBase
{
    private string _currentTimeTicks;

    public string CurrentTimeTicks
    {
        get { return _currentTimeTicks; }
        set
        {
            _currentTimeTicks = value;
            OnPropertyChanged();
        }
    }

    public CurrentTimeViewModel()
    {
        Update();
    }

    public void Update()
    {
        CurrentTimeTicks = DateTime.Now.Ticks.ToString();
    }
}

Our view model is composed of 3 classes:

• ViewModelBase is just a standard implementation for the INotifyPropertyChanged interface, providing an OnPropertyChanged helper method to its inheritors.
• MainViewModel will be used as the main view model for our sample and has a single property, CurrentTime.
• CurrentTimeViewModel has a single CurrentTimeTicks property which will contain a string representing the current time in ticks; an Update helper method has also been added to this view model.

Now let’s take a look at the MainPage view:

<Page x:Class="CompiledBindings2.MainPage"
      xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
      xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
      xmlns:d="http://schemas.microsoft.com/expression/blend/2008"
      xmlns:local="using:CompiledBindings2"
      xmlns:mc="http://schemas.openxmlformats.org/markup-compatibility/2006"
      mc:Ignorable="d">

    <Grid Background="{ThemeResource ApplicationPageBackgroundThemeBrush}">
        <Grid.RowDefinitions>
            <RowDefinition />
            <RowDefinition Height="Auto" />
        </Grid.RowDefinitions>

        <StackPanel Margin="12">
            <TextBlock Style="{StaticResource CaptionTextBlockStyle}" Text="Current Time Ticks (Binding)" />
            <TextBlock Style="{StaticResource BodyTextBlockStyle}" Text="{Binding CurrentTime.CurrentTimeTicks}" />

            <TextBlock Style="{StaticResource CaptionTextBlockStyle}" Text="Current Time Ticks (x:Bind)" />
            <TextBlock Style="{StaticResource BodyTextBlockStyle}" Text="{x:Bind ViewModel.CurrentTime.CurrentTimeTicks, Mode=OneWay}" />
        </StackPanel>

        <StackPanel Grid.Row="1">
            <Button HorizontalAlignment="Stretch"
                    Click="CreateChildViewModelButton_OnClick"
                    Content="Create CurrentTimeViewModel" />
            <Button HorizontalAlignment="Stretch"
                    Click="UpdateCurrentTimeViewModelButton_OnClick"
                    Content="Update CurrentTimeViewModel" />
            <Button HorizontalAlignment="Stretch"
                    Click="DestroyCurrentTimeViewModelButton_OnClick"
                    Content="Destroy CurrentTimeViewModel" />
        </StackPanel>
    </Grid>
</Page>

The MainPage view is composed of the following:

• a TextBlock with its Text property binded to CurrentTimeViewModel.CurrentTimeTicks, using “classic” bindings
• a TextBlock with its Text property binded to CurrentTimeViewModel.CurrentTimeTicks, using compiled bindings
• a Button to create a new CurrentTimeViewModel instance
• a Button to update the current CurrentTimeViewModel instance
• a Button to destroy the current CurrentTimeViewModel instance

Finally, here’s the code behind for the MainPage view:

public sealed partial class MainPage : Page
{
    private readonly MainViewModel _viewModel;

    public MainPage()
    {
        this.InitializeComponent();

        _viewModel = new MainViewModel();

        this.DataContext = _viewModel;
    }

    public MainViewModel ViewModel
    {
        get { return _viewModel; }
    }

    private void CreateChildViewModelButton_OnClick(object sender, RoutedEventArgs e)
    {
        _viewModel.CurrentTime = new CurrentTimeViewModel();
    }

    private void UpdateCurrentTimeViewModelButton_OnClick(object sender, RoutedEventArgs e)
    {
        if (_viewModel.CurrentTime != null)
        {
            _viewModel.CurrentTime.Update();
        }
    }

    private void DestroyCurrentTimeViewModelButton_OnClick(object sender, RoutedEventArgs e)
    {
        _viewModel.CurrentTime = null;
    }
}

As you can see above, we create a new MainViewModel instance, set it as the page DataContext property, and then we have the three click event handlers, one for each of the buttons on the view.

We’ve also added a MainPage.ViewModel property to expose the current MainViewModel instance to the compiled bindings (we can’t use the DataContext property as its type is object and compiled bindings require strong-typed properties to work).

This is what you’ll get if you run the app and tap the buttons in succession:

As you can see, the 2nd TextBlock (the one using compiled bindings) never gets the text cleared when we tap the “Destroy CurrentTimeViewModel” button!

The expected behavior is the one shown in the 1st TextBlock: if the binding value is null or unavailable, the TextBlock.Text property will set to the Binding.FallbackValue (which is null by default).

So after checking the documentation for compiled bindings, one can say without that compiled bindings are ignoring the fallback value when its value is null, and that is quite a nasty bug in the compiled bindings!

This bug has already been reported to Microsoft but as we don’t know when it will get fixed, all we can do right now is be aware of the whole issue and make sure to test our apps thoroughly to ensure we don’t end up with these problems after migrating to compiled bindings!

.NET Native behaves just like that expensive restaurant you love to got to: you have to wait until you finish the meal to see how much it will cost you - and it will definitely cost you!

Last weekend I was confronted with a bug in Cimbalino Toolkit MultiBindingBehavior, which caused apps using it to crash when they were built in Release mode!

I built a small test app and after a couple of minutes debugging it I noticed a MissingMetadataException getting raised; the culprit was found: .NET Native!

If you’re working with Universal Windows Apps (UWP) and don’t know what .NET Native is, I strongly advise you to start by reading the following excellent articles written by Morgan Brown, “a Software Development Engineer on the .NET Native team”:

• .NET Native Deep Dive: Dynamic Features in Static Code
• .NET Native Deep Dive: Help! I Hit a MissingMetadataException!
• .NET Native Deep Dive: Help! I Didn’t Hit a MissingMetadataException!
• .NET Native Deep Dive: Making Your Library Great
• .NET Native Deep Dive: Optimizing with Runtime Directives

Here’s the situation right now: when you build a UWP app, the compiler will do some “smart stuff” with your code (let’s skip the technicals here!), squeezing every little bit it can to make sure the compiled result will perform better and faster!

But there is a catch: if your code uses any type of dynamic coding features such as reflection or serialization, you might need to instruct the compiler that certain types in your application will be used as such, in order to avoid the exceptions like the MissingMetadataException you see above.

To avoid such problems, you can add specially built rd.xml files to your project - once again, check the articles above for more information on this subject!

The MultiBindingBehavior works by using the AssociateObject property value to reflect and dynamically create a binding expression, so what I needed was to ensure that it would be able to reflect any object passed to this property.

With this requirement in mind, I created a new Cimbalino.Toolkit.rd.xml file, set its Build Action to Embedded Resource, and set the content to the following:

<?xml version="1.0" encoding="utf-8"?>
<Directives xmlns="http://schemas.microsoft.com/netfx/2013/01/metadata">
  <Library Name="Cimbalino.Toolkit">
    <Type Name="Cimbalino.Toolkit.Behaviors.MultiBindingBehavior">
      <Property Name="AssociatedObject" Serialize="Included" />
    </Type>
  </Library>
</Directives>

Aaand… this didn’t work! I started getting a build error message stating that it couldn’t find any AssociatedObject property in the Cimbalino.Toolkit.Behaviors.MultiBindingBehavior.

Granted, the property does not exist directly in this class, but rather in the Behavior<T> base class, so I guess one say that .NET Native compilation completely forgot a completely basic feature of .NET and most object oriented languages: Class Inheritance!

Taking this into account, I made a couple of changes in the file and here’s what in the end made it work:

<?xml version="1.0" encoding="utf-8"?>
<Directives xmlns="http://schemas.microsoft.com/netfx/2013/01/metadata">
  <Library Name="Cimbalino.Toolkit" />
  <Library Name="Microsoft.Xaml.Interactions">
    <Type Name="Microsoft.Xaml.Interactivity.Behavior{T}">
      <Property Name="AssociatedObject" Serialize="Included" />
    </Type>
  </Library>
</Directives>

So here’s what I learned in the past weekend:

• When working with Universal Windows Apps, make sure to build the app in Release mode and test it thoroughly!
• Keep an eye out on the build warnings for any problems with your rd.xml files.
• If you’re working with MVVM or have Model representation classes, it might make sense to put these in a separate assembly, or at least in a separate namespace from the rest of the code - this will allow you to easily target these files in a rd.xml for .NET Native optimization exclusion.

They were kind enough to keep me in the loop and that allowed me to prepare for the incoming changes! ;)

Cimbalino Toolkit 2.1.0

Version 2.1.0 of the Cimbalino Toolkit is a basic update of the toolkit with a few improvements and bug fixes, but takes into account the new XAML Behaviors:

• UWP apps it now will pull the XAML Behaviors Managed NuGet package to the projects
• non-UWP apps will still use the NuGet PowerShell scripts to add the Behaviors SDK

A few weeks ago I introduced the MonitoredInteraction class from Cimbalino Toolkit 2.0.0 to “prevent memory leaks in behaviors”, and I’m happy to say that those changes made it’s way to the XAML Behaviors code! :)

Do notice that while the Interaction class in the XAML Behaviors now performs the proper attach/detach pattern, the same can’t be said for the Behaviors SDK Extension for non-UWP apps, so I strongly advise you to keep using the MonitoredInteraction class for those projects!

One final note: if you actually want to use the XAML Behaviours, you will have to actually manually add the NuGet package to your project… this is due to the new Transitive Dependencies feature of NuGet 3.x, and as far as I know, there is no way of going around this extra step!

Since the very first versions of the .NET Framework, developers had the System.Globalization namespace “containing classes that define culture-related information, including language, country/region, calendars in use, format patterns for dates, currency, and numbers, and sort order for strings.”

One of the most useful classes in this namespace is the CultureInfo class!

To demonstrate the usage of this class, take a look at this really simple console app code:

using System;
using System.Globalization;

class Program
{
    static void Main(string[] args)
    {
        Console.WriteLine("CurrentCulture: {0}", CultureInfo.CurrentCulture);
        Console.WriteLine("CurrentUICulture: {0}", CultureInfo.CurrentUICulture);
    }
}

If you run the above code with different system configurations, this is what it would output:

// Display Language = "English (US)", Location = "United States", Regional Settings = "English (US)"
CurrentCulture: en-US
CurrentUICulture: en-US

// Display Language = "English (US)", Location = "United States", Regional Settings = "Portuguese (Portugal)"
CurrentCulture: pt-PT
CurrentUICulture: en-US

// Display Language = "English (United Kingdom)", Location = "Spain", Regional Settings = "Portuguese (Angola)"
CurrentCulture: pt-AO
CurrentUICulture: en-GB

As you can see from the above results, the CurrentCulture and CurrentUICulture property values are inferred respectively from Regional Settings and Display Language; the Location however, doesn’t seem to have any effect over these two properties.

This feature allowed any app to show data using the proper currency, date, and number formats, even if the app itself wasn’t localized for those cultures!

But then came WinRT with the Windows.Globalization namespace as a replacement, and that apparently affected the way the CultureInfo class behaved…

To show the differences, I’ve created a blank Windows 8 app, and set the following code in the MainView.xaml.cs file:

using System;
using System.Globalization;
using Windows.UI.Popups;
using Windows.UI.Xaml.Controls;

public sealed partial class MainPage : Page
{
    public MainPage()
    {
        this.InitializeComponent();

        this.Loaded += MainPage_Loaded;
    }

    private void MainPage_Loaded(object sender, Windows.UI.Xaml.RoutedEventArgs e)
    {
        var messageDialog = new MessageDialog(string.Format("CurrentCulture: {0}" + Environment.NewLine + "CurrentUICulture: {1}",
            CultureInfo.CurrentUICulture,
            CultureInfo.CurrentCulture));

        messageDialog.ShowAsync();
    }
}

These are the results of running the above code:

// Display Language = "English (US)", Location = "United States", Regional Settings = "English (US)"
CurrentCulture: en-US
CurrentUICulture: en-US

// Display Language = "English (US)", Location = "United States", Regional Settings = "Portuguese (Portugal)"
CurrentCulture: en-US
CurrentUICulture: en-US

// Display Language = "English (United Kingdom)", Location = "Spain", Regional Settings = "Portuguese (Angola)"
CurrentCulture: en-GB
CurrentUICulture: en-GB

As you can see here, both the CurrentCulture and CurrentUICulture property values are now based on the selected Display Language!

In my personal opinion, this change of behavior is wrong for various reasons, but mostly because it breaks the expected known behavior of the CultureInfo class properties.

Right now you might be thinking that the impact of this change is really small, but it might actually be bigger than expect due to a specific feature: Cortana!

As of today, Cortana is still only available in a few locations, and as such, most users have “faked” their location in order to get Cortana active on their devices, but maintained the Regional Settings matching their real location!

Retrieving the “proper” CurrentCulture

One could use the Windows API GetUserDefaultLocaleName to retrieve the Regional Settings, but this only works on full Windows 10, so it’s not a “universal” way of doing it!

However, I’ve found that if you create a DateTimeFormatter instance with “US” as language, you can retrieve the culture name from the DateTimeFormatter.ResolvedLanguage property!

And here is a simple code example demonstrating how to do it:

using Windows.Globalization.DateTimeFormatting;

public class CultureInfoHelper
{
    public static CultureInfo GetCurrentCulture()
    {
        var cultureName = new DateTimeFormatter("longdate", new[] { "US" }).ResolvedLanguage;

        return new CultureInfo(cultureName);
    }
}

I honestly still don’t know how or why does this work with that Magic String™ (others might also do the trick though), but it does, and at this stage all I care are positive results!

So there you go, this is a nice hack to retrieve a CultureInfo instance for the Regional Settings, which you can then use to parse and format values in your UWP (and WinRT) app! :)

I’ve seen quite a few fixes for them (like this one from MVP Joost Van Schaik), though none proved to be truly “universal” and final!

To demonstrate the problem, let’s take a practical example:

• create an app with two pages
• page 1 will have a button to navigate to page 2
• page 2 will have a button that when clicked, will navigate back to page 1 after a pause of 2 seconds

Here’s the view model for page 2, Page2ViewModel:

public class Page2ViewModel
{
    public event EventHandler GoBack;

    public ICommand DelayedGoBackCommand { get; private set; }

    public MainViewModel()
    {
        DelayedGoBackCommand = new CustomCommand(OnDelayedGoBackCommand);
    }

    private async void OnDelayedGoBackCommand()
    {
        await Task.Delay(2000);

        GoBack?.Invoke(this, EventArgs.Empty);
    }
}

The code is really simple: when the DelayedGoBackCommand gets invoked, we will make a 2 seconds pause, and then raise the GoBack event.

Now lets say that all view models have been registered as singletons in the App class, something like this:

sealed partial class App : Application
{
    public static Page2ViewModel Page2ViewModel { get; } = new Page2ViewModel();

    // remaining code
}

This is the code behind for page 2, where we will set the page view model:

public class Page2
{
    public Page2()
    {
        InitializeComponent();

        DataContext = App.Page2ViewModel;
    }
}

And this is the view we will be using for page 2:

<Page x:Class="MyApp.Page2"
      xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
      xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
      xmlns:core="using:Microsoft.Xaml.Interactions.Core"
      xmlns:d="http://schemas.microsoft.com/expression/blend/2008"
      xmlns:i="using:Microsoft.Xaml.Interactivity"
      xmlns:mc="http://schemas.openxmlformats.org/markup-compatibility/2006"
      x:Name="PageRoot"
      mc:Ignorable="d">

    <StackPanel Background="{ThemeResource ApplicationPageBackgroundThemeBrush}">
        <i:Interaction.Behaviors>
            <core:EventTriggerBehavior EventName="GoBack"
                                       SourceObject="{Binding}">
                <core:CallMethodAction MethodName="GoBack"
                                       TargetObject="{Binding Frame,
                                                              ElementName=PageRoot}" />
            </core:EventTriggerBehavior>
        </i:Interaction.Behaviors>

        <Button Command="{Binding DelayedGoBackCommand,
                                  Mode=OneTime}"
                Content="Go Back" />
    </StackPanel>
</Page>

As you can see above, the button is binded to the Page2ViewModel.DelayedGoBackCommand. Also, we will be using an EventTriggerBehavior to monitor the Page2ViewModel.GoBack event, and when it gets raised, we will use the CallMethodAction to invoke the Page2.Frame.GoBack method.

Now here’s the catch: while behaviors have a way of being notified when they are to be detached, that never happens!! Not when you leave the page, not when the page gets unloaded, and not even when garbage collection runs.

As such, when we navigate back from page 2, Page2ViewModel.GoBack event will still hold a reference to the EventTriggerBehavior, leading to a memory leak!

But things get even worse in this example: everytime we navigate to page 2, we will subscribe over and over again the GoBack event, so multiple invocations will eventually occur - definitely not what we wanted!

Introducing the MonitoredInteraction class

The Cimbalino Toolkit now has the MonitoredInteraction class to solve this issue!

The MonitoredInteraction was built as a direct replacement of the Microsoft.Xaml.Interactivity.Interaction, and will monitor the attached object Loaded and Unloaded events and call for the attachment and detachment of all behaviors it contains!

Here’s how page 2 view would look if put it to use:

<Page x:Class="MyApp.Page2"
      xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
      xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
      xmlns:core="using:Microsoft.Xaml.Interactions.Core"
      xmlns:d="http://schemas.microsoft.com/expression/blend/2008"
      xmlns:mc="http://schemas.openxmlformats.org/markup-compatibility/2006"
      xmlns:behaviors="using:Cimbalino.Toolkit.Behaviors"
      x:Name="PageRoot"
      mc:Ignorable="d">

    <StackPanel Background="{ThemeResource ApplicationPageBackgroundThemeBrush}">
        <behaviors:MonitoredInteraction.Behaviors>
            <core:EventTriggerBehavior EventName="GoBack"
                                       SourceObject="{Binding}">
                <core:CallMethodAction MethodName="GoBack"
                                       TargetObject="{Binding Frame,
                                                              ElementName=PageRoot}" />
            </core:EventTriggerBehavior>
        </behaviors:MonitoredInteraction.Behaviors>

        <Button Command="{Binding DelayedGoBackCommand,
                                  Mode=OneTime}"
                Content="Go Back" />
    </StackPanel>
</Page>

Really, really simple, yet it will finally ensure that behaviors do get detached when one navigates away of a page, and re-attached when navigating in!

Hopefully someone from the Behaviors SDK team will read this, and take some of the suggestions here to fix this well known issue that’s been around for quite a while! ;)

And as the name might suggest, compiled bindings are a way the compiler uses to generate static code for a binding instead of using a reflection based solution, as regular bindings do.

The main advantage is quite obvious: there will be a performance gain for using static compiled code instead of using reflection!

Let’s take a look at a simple regular binding example:

<TextBlock Text="{Binding Name}" />

This binding will set the TextBlock.Text property to the value of the Name and will update it every time the Name property changes (assuming that the data context implements and raises the necessary INotifyPropertyChanged.PropertyChanged event)

To take advantage of the compiled bindings, one would rewrite it like this:

<TextBlock Text="{x:Bind Name, Mode=OneWay}" />

Notice that I added the Mode=OneWay on the expression above?

Well, that is actually required due to a fundamental difference between regular bindings and compiled bindings: while the regular bindings default mode is OneWay, compiled bindings default mode is OneTime!

This is a really important piece of information that I’ve seen a lot of developers not taking notice, so make sure to fix those binding expressions correctly when you migrate to compiled bindings!

Bring out the champagne, because Cimbalino Toolkit version 2.0.0 has gone “gold” and is now production ready! :)

As previously stated, the focus for this new version was to add support for UWP (Universal Windows Platform), thus making the toolkit support a total of 4 platforms:

• Windows Phone Silverlight 8.0 and 8.1 apps (WP8)
• Windows Phone 8.1 apps (WPA81)
• Windows Store 8.1 apps (Win81)
• Windows 10 UWP apps (Universal Windows Platform)

Please remember to manually add the Behaviors SDK to your UWP apps if you use Cimbalino! The other platforms will have it added automatically, but due to changes in the way NuGet works this is not possible for UWP.

Assuming you don’t live in a planet where you don’t get internet (and I know that’s not the case as you’re reading this!), by now you know that Windows 10 has officially launched!

So did Visual Studio 2015 and NuGet 3.x, so pretty much everything you need to develop new Windows 10 universal apps, right? Not quite! ;)

Presenting the new and improved version 2.0.0-beta1 of the Cimbalino Toolkit, and as you already suspect, it is fully compatible with UWP (Universal Windows Platform)!

Proper kudos is owed to MVP Scott Lovegrove as he has done pretty good job for the last couple of weeks to get the toolkit up and running in Windows 10! :)

There is a breaking change on using the toolkit from previous versions: NuGet has removed the functionality of running Powershell scripts when you install a package, and Cimbalino Toolkit required that to add the Behaviors SDK to your projects… that said, please make sure that you manually add the Behaviors SDK to any project using the Cimbalino.Toolkit NuGet package!

On a final now, remember that this new version is still a beta as the code and documentation will be reviewed and tested during the next weeks, so do expect to find some issues and bugs! If you find any, please do report them directly on GitHub!

Full disclosure: though I’ve been a Microsoft employee for a short while, I currently have no professional (or other type of) connection with the company.

Now that we have got that out of the way, I do believe that there has never been a better time to be a Microsoft developer than today! :)

Ok, I’ll bite… why do you think that?

Microsoft Build Developers Conference was held last week in San Francisco. On it, Microsoft showed it’s vision for the future, and it is a bright one!

Though this article only scratches the surface on all that was shown, these were my personal highlights of the event!

Windows 10 everywhere!

Yes, Windows 10 will be everywhere, from PC’s, Laptops and Tablets, the Xbox One and Hololens, and also powering IoT devices like the Raspberry Pi 2.

For developers this translates in the fact that apps you develop for Windows 10, will also run in any other device! Functionality may obviously differ from device to device given their capabilities (touch screen on a tablet, augmented reality in Hololens, sensors on IoT devices, etc.), but in the end it will be the same Windows 10 app running on all of them!

Open-source initiative

The amount of code made available over the last couple of weeks in Microsoft’s GitHub page is truly astonishing!

Microsoft went from a closed-source software company to open-source a big chunk of their code in order to get contributions from the community (comments, reviews, code contributions, etc.), just like in any other GitHub repository!

Going cross-platform

Say goodbye to the Microsoft you’ve know for years as a Windows and Office only company; “Mobile first, cloud first” is the new motto, and there was enough proof of that in Build conference.

If you’re a web developer, you should definitely give Visual Studio Code a spin - and here’s the twist: it runs not only in Windows, but also in Mac and Linux, as Visual Studio Code is itself built on top of open-source technologies!

The whole CoreCLR (.NET Core Runtime) was built for Windows but now runs in Mac and Linux machines, meaning you can run the same .NET based code in all these platforms!

iOS and Android apps are welcome!

Develop apps for iOS or Android? Well, there’s some good news for you too: with Project Islandwood and Project Astoria, you’ll be able to make those apps run in Windows 10 with just a few modifications, and even sell them through the Windows Store and make some money out of it!

Targeting the Windows platform is definitely a smart move, as it will enable you to reach more users and increase potential revenue from your apps.

All apps are now Windows Apps

The “older” .NET and Win32 desktop apps we use all day long will now have a place in the Windows Store, making life easier for users to find, download and use them!

Just package those apps as a Windows 10 app, ship it to the store, and you’re done!

One more thing

Hololens! If you don’t know what it is by now, then you definitely should!!

While other companies are investing Virtual Reality, Microsoft took a different approach with Hololens and went with Augmented Reality.

As the name might suggest, “Augmented Reality” adds information to your real environment, and it’s usages are quite diverse. Microsoft showed a couple of demos of usage for construction and health that I believe made some jaw’s drop!

“DEVELOPERS, DEVELOPERS, DEVELOPERS!!”

No one said it, but I’m sure a lot of people remembered this while watching Build 2015:

https://www.youtube.com/watch?v=Vhh_GeBPOhs

The biggest request (and at the same time, the biggest complaint) I always had about Cimbalino Toolkit was to get some proper documentation about what the toolkit actually contains!

That has now changed, as the documentation is live at http://cimbalino.org/help

The whole documentation was generated from the inline XML Documentation with the help of SandCastle, so it’s still a bit minimum but I expect it to improve along time!

Please feel free to check it out and send some comments! :)

In case you’ve missed it, Microsoft has now released the Windows 10 Technical Preview Developer Tools!

These allow you to start using the Windows 10 Universal Apps Platform (UAP) and thus developing apps for the next generation of Windows!

All you need is a machine (or VM) with the latest Windows 10 Preview and Visual Studio CTP 6 to install the developer tools preview and start building some awesome apps!! :)

Cimbalino Toolkit Windows 10 UAP support

I’ve been getting a lot of questions lately about Cimbalino Toolkit support for Windows 10 Apps (aka Universal Apps, UAP, Windows Apps, etc…)

I can assure you that support is definitely coming and you can get an early look on what is being done in Scott Lovegroove’s fork available here!

Picking up where we left off on the previous article, you now know how to install the Cimbalino Toolkit in your app, so congratulations for that! :)

On this article I will show how to integrate it with the MVVM Light Toolkit, and then build a really simple “Hello World” app!

Note: Though this article will focus on how to integrate with the MVVM Light Toolkit, the Cimbalino Toolkit can be combined with most Windows development toolkits and frameworks that are available (like MVVMCross, Caliburn, etc.)

Using the same approach to add NuGet packages to the solution shown in the previous article, now search for “MvvmLight” and select the package shown in this picture:

You should now click on the Install button, confirm that you want to install the package into both projects, review the details shown in the License Acceptance window, and click the I Accept button.

You will now see a couple of warnings about moving the ViewModel folder manually; this is expected and it is due to the fact that we are building a Universal App (you can find more information about this here).

Look at the Solution Explorer Window, you should see that we have two ViewModel folders, one on each of the projects:

Go ahead and delete one of the ViewModel folders, and move the remaining one from the project to the shared files on the bottom. The end result should look something like this:

We now we need to register the IMessageBoxService with the ViewModelLocator so that we can use it in the MainViewModel to show message popups in the app!

Edit the ViewModelLocator.cs file and change it to the following:

using Cimbalino.Toolkit.Services;
using GalaSoft.MvvmLight.Ioc;
using Microsoft.Practices.ServiceLocation;

namespace App1.ViewModel
{
    public class ViewModelLocator
    {
        public ViewModelLocator()
        {
            ServiceLocator.SetLocatorProvider(() => SimpleIoc.Default);

            SimpleIoc.Default.Register<IMessageBoxService, MessageBoxService>();

            SimpleIoc.Default.Register<MainViewModel>();
        }

        public MainViewModel Main
        {
            get
            {
                return ServiceLocator.Current.GetInstance<MainViewModel>();
            }
        }

        public static void Cleanup()
        {
            // TODO Clear the ViewModels
        }
    }
}

As you can see above, we registered the IMessageBoxService with the MVVM Light Toolkit IoC Container by calling SimpleIoc.Default.Register<IMessageBoxService, MessageBoxService>(), and this is how we will use all of the services provided by Cimbalino Toolkit - and there are quite a lot of them!!

Now open the MainViewModel.cs file and change it to the following code:

using Cimbalino.Toolkit.Services;
using GalaSoft.MvvmLight;
using GalaSoft.MvvmLight.Command;

namespace App1.ViewModel
{
    public class MainViewModel : ViewModelBase
    {
        private string _name;

        public string Name
        {
            get
            {
                return _name;
            }
            set
            {
                Set(ref _name, value);
            }
        }

        public RelayCommand SayHelloCommand { get; private set; }

        public MainViewModel(IMessageBoxService messageBoxService)
        {
            SayHelloCommand = new RelayCommand(async () => await messageBoxService.ShowAsync("Hello " + Name + "!"));
        }
    }
}

We started by adding a couple of properties, Name and SayHelloCommand, that we are going to bind to the view.

We can also see a IMessageBoxService parameter in the MainViewModel constructor, which the IoC Container will satisfy by creating an instance of MessageBoxService and providing it to the constructor.

Inside the constructor, we declared what will happen when the SayHelloCommand is invoked: show a popup message box with the input name.

That takes care of the view model, time to work on the view!

On the shared files project, create a new folder named View, and inside it create a new user control named MainUserControl.xaml with the following content:

<UserControl x:Class="App1.View.MainUserControl"
             xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
             xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
             xmlns:d="http://schemas.microsoft.com/expression/blend/2008"
             xmlns:mc="http://schemas.openxmlformats.org/markup-compatibility/2006"
             DataContext="{Binding Main,
                                   Source={StaticResource Locator}}"
             d:DesignHeight="300"
             d:DesignWidth="400"
             mc:Ignorable="d">

    <StackPanel>
        <TextBlock Text="name" />
        <TextBox Text="{Binding Name, Mode=TwoWay}" />
        <Button Command="{Binding SayHelloCommand, Mode=OneTime}" Content="Say Hello" />
    </StackPanel>
</UserControl>

For the view we will use root StackPanel control, containing a TextBlock with a “name” label, a TextBox binded to the Name property in the view model, and a Button binded to the SayHelloCommand property.

Notice also on the top of the file that we set the user control DataContext property to use the ViewModelLocator.Main property, which returns the instance of the MainViewModel.

Now all that we needed is to add our MainUserControl to the MainPage.xaml file in each of the app projects. In the end, each of the MainPage.xaml files should be similar to this:

<Page x:Class="App1.MainPage"
      xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
      xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
      xmlns:d="http://schemas.microsoft.com/expression/blend/2008"
      xmlns:mc="http://schemas.openxmlformats.org/markup-compatibility/2006"
      xmlns:view="using:App1.View"
      mc:Ignorable="d">

    <Grid>
        <view:MainUserControl />
    </Grid>
</Page>

And… we are done!!!

Just run the Windows project and the Windows Phone project to confirm that our shared code does in fact work across the two platforms! :)

To make things even easier, you can download the full solution here!

One of the biggest complaints I always had about Cimbalino Toolkit is the lack of documentation and samples!

Granted, some awesome developers like Sara Silva and Scott Lovegrove have done a lot more than I have to promote the toolkit and write some really good code using it, but I think it’s time I take on some of that work!

As such, I’m now making an effort to regularly write articles on Universal Apps development with Cimbalino Toolkit step by step, and here is the first one…

Adding the Cimbalino Toolkit NuGet to a Universal App

Open Visual Studio 2013, click File -> New -> Project, on the Templates on the left select Store Apps -> Universal Apps, on the right select Blank App (Universal Apps), pick a name and hit Ok to save the solution!

Click Tools -> NuGet Package Manager -> Manage NuGet Packages for Solution….

On the top right of the Manage NuGet Packages window you will see a search box; type “Cimbalino” on it and press Enter. You should now be seeing two packages: “Cimbalino Toolkit Core” (compatible with background agents) and “Cimbalino Toolkit” (main component)

Select “Cimbalino Toolkit” and click on the Install button. You will now see the Select Project window.

Leave all projects of the solution selected and click Ok. You will now see the License Acceptance window, showing the licenses for all packages that will be installed.

Please review the data and then click I accept to continue with the installation.

After this step, you should now have returned to the Manage NuGet Packages window, and a green checkmark should now be shown on the side of each of the toolkit components.

Congratulations: you have now successfully installed the Cimbalino Toolkit in your project! :)

After Microsoft completed the acquisition of the Nokia Devices & Services business, MixRadio and all of it’s employees became part of Microsoft.

However, a couple of weeks after that Microsoft started a full reorganization and decisions were quickly made to ensure MixRadio would become a separate entity.

So the only visible changes resulting from the acquisition are actually the company signs around the office, the “blue badges”, and the new @microsoft.com email addresses… no other real integration ever happened for MixRadio, so I can’t actually say I felt like a Microsoft employee during this short period!

As a result of all this, plans have been made for the future of MixRadio as a new company that made me believe this is the right time for our paths to come apart.

During my time with the company, I was involved in almost every aspect of the MixRadio Windows Phone client development; every time I open the MixRadio 4.x client in my phone, I can’t help but to feel proud of what this team accomplished.

I wish the very best to MixRadio and all my colleagues in the upcoming future, and I’m sure to keep using MixRadio service as it is by far one of the best streaming music services available!

As for me, I will keep doing what I love, always related with development under Microsoft Technologies, but more to come on this over the next weeks…

Basically, the class is an IDictionary<string, object> with a Save() method that will take the instance and serialize it to a file called ”__ApplicationSettings” in the root of the app’s isolated storage.

Now if you upgraded your app from Windows Phone Silverlight 8.0 to the Windows Runtime model, you’ll probably want to migrate the settings from the old format to the new one, right?

Problem is that though the class exists in Windows Phone Silverlight apps, it does not in the new Windows Runtime apps, being replaced with ApplicationData.LocalSettings and ApplicationData.RoamingSettings instead.

So the only solution will be doing it ourselves, by reading and deserializing the “old” settings file!

Here’s a sample of the content of an ”__ApplicationSettings” file from one of my tests:

PhoneApp1.Address, PhoneApp1, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null
<ArrayOfKeyValueOfstringanyType xmlns:i="http://www.w3.org/2001/XMLSchema-instance" xmlns="http://schemas.microsoft.com/2003/10/Serialization/Arrays"><KeyValueOfstringanyType><Key>Name</Key><Value xmlns:d3p1="http://www.w3.org/2001/XMLSchema" i:type="d3p1:string">John Doe</Value></KeyValueOfstringanyType><KeyValueOfstringanyType><Key>Age</Key><Value xmlns:d3p1="http://www.w3.org/2001/XMLSchema" i:type="d3p1:int">20</Value></KeyValueOfstringanyType><KeyValueOfstringanyType><Key>Country</Key><Value xmlns:d3p1="http://schemas.datacontract.org/2004/07/PhoneApp1" i:type="d3p1:Address"><d3p1:Code>UK</d3p1:Code><d3p1:Name>United Kingdom</d3p1:Name></Value></KeyValueOfstringanyType></ArrayOfKeyValueOfstringanyType>

By looking at the contents of some samples of settings file like the one above, here’s what we can learn:

• the file has always two lines (second line in the above sample is auto-wrapped to fit the post!)
• the first line has the known types full names that should be loaded and passed on to the DataContractSerializer constructor, each properly separated by a null char
• if only basic types are used, the first line will be empty
• the second line is the serialized xml data

So I wrote the following code snippet to read and deserialize the values from ”__ApplicationSetting” to an IEnumerable<KeyValuePair<string, object>>:

public async Task<IEnumerable<KeyValuePair<string, object>>> GetValuesAsync()
{
    try
    {
        using (var fileStream = await ApplicationData.Current.LocalFolder.OpenStreamForReadAsync("__ApplicationSettings"))
        {
            using (var streamReader = new StreamReader(fileStream))
            {
                var line = streamReader.ReadLine() ?? string.Empty;

                var knownTypes = line.Split('')
                    .Where(x => !string.IsNullOrEmpty(x))
                    .Select(Type.GetType)
                    .ToArray();

                fileStream.Position = line.Length + Environment.NewLine.Length;

                var serializer = new DataContractSerializer(typeof(Dictionary<string, object>), knownTypes);

                return (Dictionary<string, object>)serializer.ReadObject(fileStream);
            }
        }
    }
    catch
    {
        return new Dictionary<string, object>();
    }
}

So all you now have to do is call the GetValuesAsync() method above and load those values to one of the new Settings repositories!

The Cimbalino Toolkit way

Starting in Cimbalino Toolkit 1.2.0, you’ll be able to use the new IApplicationSettingsService to access Local, Roaming, and Legacy app settings.

In case that wasn’t clear from the names, the Legacy settings will allow you to get the values on the ”__ApplicationSettings” file (do note that only the Values property is implemented, so it’s read-only).

Here are the platform rules for the ISettingsService:

• Local
  • Supported in all platforms
• Roaming
  • Supported in all platforms except Windows Phone Silverlight 8.0
• Legacy
  • Only supported in Windows Phone

One last suggestion: after migrating the legacy settings remember to delete the ”__ApplicationSettings” file as it won’t be needed again! ;)

In case you missed it, there is a new and improved Cimbalino Toolkit now available, supporting the following platforms:

• Windows Phone Silverlight 8.0 and 8.1 apps (WP8)
• Windows Phone 8.1 apps (WPA81)
• Windows Store 8.1 apps (Win81)

The long story

About 3 years ago, the first version of Cimbalino Windows Phone Toolkit was released as a NuGet package with full source code hosted in GitHub to help every on the development of Windows Phone apps!

Back then, Windows Phone 7.0 was the only version available, and that meant that some technical decisions had to be made that influenced the toolkit architecture!

The main one was that WP7 apps Marketplace ingestion would automatically detect every component used in a particular app, and add the required Capabilities for them; so if the toolkit was a single assembly, you’d get your app with the full Capabilities list in the requirements, even if your app didn’t actually use them…

There was also some limitations on the available API’s for Background Agents and once again, the Marketplace ingestion of an app would basically fail if it detected one of those forbidden API‘s.

So the toolkit ended up divided like so:

In light blue are the components that may be used with Background Agents. The rest of the components are divided by Capabilities or 3rd party components requirements.

Then came Windows 8.0 and Windows Phone 8.0, and Microsoft removed the Marketplace Capabilities auto-detection feature (the developer has to declare them manually in the app manifest), so we can now have drop that specific component division requirement! :)

This small change allowed to reduce the create a new Cimbalino Toolkit with just 2 NuGet packages!

There is still a lot of work to be done to port everything from the old toolkit to the new one, but here’s some of the things already working:

• ApplicationBarBehavior, MultiApplicationBarBehavior, MultiBindingBehavior
• StorageService, EmailComposeService, MessageBoxService, NavigationService, and others…
• Most of the extension methods have already been ported, including the PNG support ones
• Most of the value converters

Also, there is the need to write some new samples and documentation, so if you can I could surely use the help!!! ;)

TL;DR

Here are the new Cimbalino Toolkit NuGet packages:

• Cimbalino.Toolkit.Core - The core portion of the toolkit (compatible with background agents)
• Cimbalino.Toolkit - The main component of the toolkit

Please check back soon to read about what’s new and what changed! :)

The deal to transfer substantially all of the Nokia Devices & Services business to Microsoft has now officially been closed.

With it, I proudly become a Microsoft employee! :)

I will always cherish the moment I decided in moving to the UK to work for Nokia (even if that stopped any chance of receiving the Microsoft MVP award, but that’s another story!).

Nokia made me feel that I could actually make a difference with my work, and I truly appreciate the company for the opportunity!

I’ve been working with Microsoft technologies for more time than I can remember, both as a user and also as an IT professional, and I consider getting the “blue badge” as a giant career step for me!

In the present moment this doesn’t bring any significant changes: I’ll carry on working in the MixRadio apps here in Bristol, as I did until today!

Thank you Nokia, it’s been really fun… Hello Microsoft! :)

Version 3.2.3 of Cimbalino Windows Phone Toolkit is now available!

As previously indicated, this will probably be the last version still supporting Windows Phone 7…

Here’s the change log starting from version 3.2.0 to the current 3.2.3:

• v3.2.1
  • New WebRequestExtensions
  • Ensured that MarketplaceInformationService doesn’t cache the results
• v3.2.2
  • New EventHandlerExtensions
  • Improved the MultiBindingBehavior by adding the missing Mode property
  • Improved the ShellTileServiceTile to enable tiles update with XML data
  • Fixed a couple of issues on MarketplaceInformationService related to “beta apps”
• v3.2.3
  • New SaveRingtoneService
  • New ScreenCaptureBehavior
  • New FrameworkElementExtensions
  • DeviceInfo, Location, and UserInfo components can now be used inside Background Agents
  • Improved ShellToastService to add the custom sound support

There are other improvements and bug fixes not stated here, but also quite important too! :)

The WrapPanel control (part of the Windows Phone Toolkit) is a really useful control container.

Having said that, you should definitely avoid using it in your apps if you are planing to use in ListBox.ItemsPanel for large lists items presented with fixed size!!

To demonstrate my point, let’s say we have a list of 10 items:

{0, 1, 2, 3, 4, 5, 6, 7, 8, 9}

Now say we want to list 3 items per row and them wrap to the next row, we can use a WrapPanel container control, like so:

<ListBox x:Name="ItemsListBox"
            ItemTemplate="{StaticResource ItemDataTemplate}">
    <ListBox.ItemsPanel>
        <ItemsPanelTemplate>
            <toolkit:WrapPanel />
        </ItemsPanelTemplate>
    </ListBox.ItemsPanel>
</ListBox>

The resulting items layout will look something like the following picture:

This will work fine with 10 items, but what about 100? Or 1.000? Or even 10.000?

Using a WrapPanel with a large number of items will cause the control loading time and memory usage to increase, and if you make it large enough, you’ll probably start seeing your app crash with “out of memory” errors…

Now lets say we first group the items in groups of 3, making the source list look like this:

{ {0, 1, 2}, {3, 4, 5}, {6, 7, 8}, {9} }

All we now need is another ItemsControl inside our main ListBox to iterate the each group, something like this:

<ListBox x:Name="ItemsListBox">
    <ListBox.ItemTemplate>
        <DataTemplate>
            <ItemsControl ItemTemplate="{StaticResource ItemDataTemplate}" ItemsSource="{Binding}">
                <ItemsControl.ItemsPanel>
                    <ItemsPanelTemplate>
                        <VirtualizingStackPanel Orientation="Horizontal" />
                    </ItemsPanelTemplate>
                </ItemsControl.ItemsPanel>
            </ItemsControl>
        </DataTemplate>
    </ListBox.ItemTemplate>
</ListBox>

Here’s the resulting layout schematic:

Major advantages with this approach is the obvious performance improvement and memory consumption reduction. Why? Because we maintained the VirtualizingStackPanel in our main ListBox.ItemsPanel!

To prove my point, I’ve created a small demonstration app showing the result of using these two approaches with a list of 400 items.

Download the code, deploy it on a phone or emulator, then run each approach separately and exit the app after each run in order to check the peak memory usage.

You’ll notice a huge difference in loading times, but I can tell you that memory wise, it’s the difference between using 120MB or just 20MB! :)

The upcoming 4.x would have WP8 and WP Blue support, allowing for a more future prune implementation and dropping the NuGet packages from 9 to just 2 (the Background package as it stands today and a main one with all the rest).

To actually understand the position of the Windows Phone developers about WP7 development, I started a poll that I now invite you to answer! :)

The next W&W WAG (Wales and West Windows Application Group) meeting will be help tomorrow, February 26th, at Nokia Bristol office, and will feature me talking about the Cimbalino Windows Phone Toolkit, and the Mike Hole, talking about Bluetooth and NFC based communication.

The meeting will start at 18h30, you can find more details and register here!

Hope to see you there! :)

Update: Kudos to Murat and Rudy Huyn for pointing me out on a missing return; that would cause the NotSupportedException to be raised all the time… I’ve fixed the code by inverting the if condition.

Update 2: Just noticed that GDR2 is also supported, as the code below will also work in devices with it! :)

Windows Phone 8 made it possible to take a screenshot of your screen at any time, just by pressing the Windows and Power button at the same time.

Sure, this is a really cool feature and can be quite handy from time to time, but it can become a security concern for some specific scenarios, not to mention a way to copy someone else’s graphical designs!

Since Windows Phone 8 update 3 (GDR2) there is now a hidden feature that allows you to disable the Screenshot functionality on a page by page basis: the PhoneApplicationPage.IsScreenCaptureEnabled!

This is a hidden property that requires Reflection in order to access and modify it’s state. The following extension methods will help you with that:

public static class PhoneApplicationPageExtensionMethods
{
    public static bool CanSetScreenCaptureEnabled(this PhoneApplicationPage page)
    {
        return Environment.OSVersion.Version >= new Version(8, 0, 10322);
    }

    public static void SetScreenCaptureEnabled(this PhoneApplicationPage page, bool enabled)
    {
        var propertyInfo = typeof(PhoneApplicationPage).GetProperty("IsScreenCaptureEnabled");

        if (propertyInfo == null)
        {
            throw new NotSupportedException("Not supported in this Windows Phone version!");
        }

        propertyInfo.SetValue(page, enabled);
    }

    public static bool GetScreenCaptureEnabled(this PhoneApplicationPage page)
    {
        var propertyInfo = typeof(PhoneApplicationPage).GetProperty("IsScreenCaptureEnabled");

        if (propertyInfo == null)
        {
            throw new NotSupportedException("Not supported in this Windows Phone version!");
        }

        return (bool)propertyInfo.GetValue(page);
    }
}

The first step is to call CanSetScreenCaptureEnabled() from inside your PhoneApplicationPage to check if the Windows Phone version is at least Windows Phone 8 update 3 (version 8.0.10322) as that is the minimum required version for this to work!

If it is, we can then use the GetScreenCaptureEnabled() and SetScreenCaptureEnabled() extension methods to change the property value!

Here is a sample usage code to disable screenshot functionality:

public partial class MainPage : PhoneApplicationPage
{
    public MainPage()
    {
        InitializeComponent();

        if (this.CanSetScreenCaptureEnabled())
        {
            this.SetScreenCaptureEnabled(false);
        }
    }
}

If you do try to take a screenshot after that code, this is what will happen:

The same result will happen from the application switcher screen:

Nowadays, privacy has become the #1 concern in everything we do, and I’m sure this is a really useful information for a bunch of apps out there (looking at you 6snap and all other Snapchat apps ;) )

Then look no further: here is the list of the best apps I have installed on my own phone! :)

Social

• Twitter - The fully featured Twitter app with multiple account support and push notifications that actually do work!
• Facebook Beta - There is also a non-beta Facebook official app, but I prefer the beta one as it gives me the latest features sooner! ;)
• 4th & Mayor - I know that there is an official Foursquare app and that it’s a lot better than the first version, but I still prefer 4th & Mayor from Jeff Wilcox as it is quite simpler and uses a more direct approach!
• WhatsApp - free messaging that works on pretty much any phone? Yes, thank you very much! :)
• Skype - The official Skype app, really good when it actually works… this is the one app I really need and sometimes fails me miserably :\
• 6tag - developed by Rudy Huyn, probably the best Instagram app for Windows Phone. There is an official Instagram BETA app, but it’s still lacking some features…
• Disqus - It’s probably the most used network for commenting on forums and blogs everywhere!
• LinkedIn - LinkedIn official app, to keep in eye on your professional connections.
• Viber - Another VOIP app, quite known out there

Tools + Productivity

• Authenticator - In a time where security and privacy are lacking more and more, using two-factor sign-in whenever possible does help a bit (Microsoft, Google, and other websites use this approach)
• Google - not that different than accessing www.google.com with the browser, but nevertheless it’s the only app that Google has on Windows Phone…
• Adobe Reader - Official Adobe Reader app to open PDF files on the phone. There is also a PDF Reader from Microsoft as a really good alternative.
• BoxFiles for Dropbox - There are quite a few Dropbox apps right now for Windows Phone (none is official) and I personally like this one.
• SkyDrive - full featured official SkyDrive app from Microsoft.
• GDrive - Using Google Drive? Then this is what you need! It’s not a fully featured client, but at least it is better than nothing!
• TeamViewer - Access your machine remotely using TeamViewer.

News + Weather

• Nextgen Reader - this is the #1 app in my phone!!! I just couldn’t go by without reading my RSS feeds, and given it uses Feedly as source, all my feeds are synchronized; just perfect!!
• Amazing Weather HD - A really good weather app with nice look and quite a few features. A free alternative is Bing Weather, also quite nice!

Lifestyle / Shopping

• Amazon Mobile - Search Amazon, purchase stuff, check your order status…
• eBay - The app is quite simple and could use a better look, but it works well and does a proper job alerting when auctions are about to end.

Travel + Navigation

• Geosense - quite useful to convert from different GPS coordinates types, to get my location, open KML files from Google Earth… and yes, I wrote it and that’s also another reason why it’s here, so sue me! :P
• TripAdvisor - I always like to read the reviews on hotels and restaurants on TripAdvisor before I actually go to the place.
• Currency - Currency exchange, provided by XE

Entertainment

• IMDb - The official IMDb app for Windows Phone, probably the best showcase for a WP app and the best IMDb client you’ll find in any mobile device!
• Helium Voice Free - Because it’s fun and I like to show kids! :)

Business

• Office Remote - do you do PowerPoint presentations? Then do yourself a favor and install this in your Windows Phone!

Personal Finance

• PayPal - I like to keep a close eye on my PayPal transactions!

Photo

• Pictures Lab - Nice, clean, and fast, picture effects app, developed by René Schulte.
• Tile Me! - Create a Windows Phone tile picture with this app, and use it everywhere! :D

Music + Video

• YouTube - a couple a months ago there was an official YouTube app (and it was really good, I might add), but Google pulled the plug on it and so we are stuck with just this miserable plugin and YouTube mobile website…
• Shazam - You know when you’re in a party, listening to a music that you actually like and don’t know who the artist is? That’s when Shazam comes quite handy!
• Sax - A simple fun way of playing saxophone without one!

Books + Reference

• Wikipedia - it’s Wikipedia, and that is all anyone needs for reference…

So go on now, install some apps in your phone and have fun!

And by the way: Happy New Year!!! :)

Windows Phone image processing and format support has always been lacking a bit, especially when compared with all the GDI+ capabilities one has available in the full .NET Framework.

For instance, you can read JPEG and PNG files, but you can only save to JPEG, as there is no support to save to PNG directly on the platform.

Saving to PNG has been quite easy since the beginning of Windows Phone 7 by using 3rd party libraries, and on this chapter, .NET Image Tools is the most used one!

But personally, using Image Tools always presented two major problems:

• it requires SharpZipLib (a GPL licensed library) to handle Zlib compression
• it’s quite slow and uses a lot of memory

The first problem is a definitive “no-no” for usage in closed code commercial apps, as GPL is ”viral license”

The second problem is more related to the way Image Tools was developed, not considering usage in mobile devices that have lower specifications as to processor capacity or memory.

The Cimbalino Windows Phone Toolkit way

Cimbalino Windows Phone Toolkit version 3.2.0 presents a new WriteableBitmapExtensions containing a SavePng() method to create PNG files from WriteableBitmap instances!

Internally it uses DotNetZip (Ms-Pl license) to handle the required ZLib compression and it’s quite optimized for speed and low memory consumption.

To illustrate the speed improvement, Ertay Shashko was kind enough to test it with his Tile Me app, and here are the results of his personal usage:

@pedrolamas Imagetools (~2.5 seconds to generate): http://t.co/LS5Lj1ZSCq Cimbalino (Default, ~0.7 secs to gener.): http://t.co/Hv0CAOK8K6

— Ertay Shashko (@ErtaySh) November 6, 2013

I guess the numbers speak for themselves! :)

The change log for Windows Phone 8 update 3 (also known as GDR3) has been known for a few weeks and one of the new features is the added

support for bigger, higher-resolution screens

This is obviously only for new devices, with 5” or 6” screens using 1080p resolution, like the amazing Nokia Lumia 1520!

Here’s the complete list of Windows Phone supported resolutions, divided by aspect ratio:

• 15:9
  • WVGA (480x800, 1.0x scale factor) - this is the only resolution available in WP7
  • WXGA (768x1280, 1.6x scale factor)
• 16:9
  • 720p (720x1280, 1.5x scale factor)
  • 1080p (1080x1920, 2.25x scale factor) - only supported in the new large screen devices with WP8 update 3

As a Windows Phone developer/designer, you don’t need to know this!

All you need to do is design the interface in XAML for the 480x800 resolution, and it will automatically scale up using a fixed scale factor! How cool is that? :)

Now if you really want to know what is the device scale factor (maybe to create different app resolution-aware layouts), you can read the Application.Current.Host.Content.ScaleFactor (note: this property will return the scale factor * 100).

But there’s a catch: for the new 1080p devices, the scale factor is returned as 1.5x, just as the 720p devices, instead of the correct 2.25x…

To get the real scale factor, you can use the following code snippet:

public int ScaleFactor
{
    get
    {
        object physicalScreenResolutionObject;

        if (DeviceExtendedProperties.TryGetValue("PhysicalScreenResolution", out physicalScreenResolutionObject))
        {
            var physicalScreenResolution = (Size)physicalScreenResolutionObject;

            return (int)(physicalScreenResolution.Width / 4.8);
        }

        return Application.Current.Host.Content.ScaleFactor;
    }
}

In WP8 update 3 you can use DeviceExtendedProperties.TryGetValue("PhysicalScreenResolution", out physicalScreenResolutionObject) to retrieve the screen Size resolution in pixels, take the Width of it and divide it by 4.8 to know the correct scale factor.

If the call to DeviceExtendedProperties.TryGetValue fails it just means you don’t have a WP8 GDR3 device, and as such the device is not a 1080p device and you can just fallback to use the Application.Current.Host.Content.ScaleFactor approach!

The Cimbalino Windows Phone Toolkit way

Previous versions of Cimbalino Windows Phone Toolkit already had the IScreenInfoService to help handling this, and since version 3.2.0, you can also count on the added 1080p support! :)

Version 3.2.0 of Cimbalino Windows Phone Toolkit is now available!

This release is mostly a bug/performance fix; here’s the change log:

• Added the WriteableBitmapExtensions, which provides a high-performance & low memory impact SavePng() method!
• Improved the IScreenInfoService and ResolutionAwareUriConverter to contemplate 1080p screens
• The usual improvements and bug fixes

Directly from the official site:

Windows Phone Week is a series of events created for the developer community by Windows Phone Developer MVPs.

The events are in nine countries, encouraging developers from around the world to explore app and gaming development.

Each event has a unique agenda, format and registration process so please check the details at the location nearest you.

Although at this stage only 9 countries are participating, there are plans to expand to other territories, so stay tuned! ;)

A few weeks ago I stumbled on an issue while using ampersand (&) in a URI association deep link with query string parameters!

Let’s start by assuming I have a Windows Phone app capable of handling deep links with “my-app:” moniker. Now take a look at the following sample link:

my-app://do/stuff/?param1=a%26b&param2=c

We can easily see a query string with two parameters, and after decoding their values, we get param1 = "a&b" and param2 = "c".

If we use the Launcher.LaunchUriAsync(uri) method to open the link, this is what will arrive in the internal UriMapper:

/Protocol?encodedLaunchUri=my-app%3A%2F%2Fdo%2Fstuff%2F%3Fparam1%3Da%2526b%26param2%3Dc

By retrieving and decoding the encodedLaunchUri from the previous link, the result will be "my-app://do/stuff/?param1=a%26b&param2=c", matching the original uri, as we would expect!

If we now use a web page with that link on it instead, open the page inside Internet Explorer on the phone and tap on the link, this is what will get to the app UriMapper:

/Protocol?encodedLaunchUri=my-app%3A%2F%2Fdo%2Fstuff%2F%3Fparam1%3Da%26b%26param2%3Dc

If we do as before and retrieve and decode the encodedLaunchUri, we will get "my-app://do/stuff/?param1=a&b&param2=c", which in this case, doesn’t match the original deep link!

This behavior is due to Internet Explorer in Windows Phone, as it seems to decode all links before trying to navigate to them, and when it can’t perform the navigation (e.g. when the link isn’t a http:// or https:// link) it just sends it to the platform to handle it, but by that time the link has already been wrongly re-encoded!

So far I haven’t been able to find any way of bypassing this issue, apart of simply not using the & in my apps deep links… and my advice to you is to proceed just like this!

Most desktop applications use the Tab key to jump focus from one control to the next one, and this is expected behavior and common knowledge to most users.

On Android, the on-screen keyboard normally shows a “Next” key to - yes, you’ve guessed it! - go to the next field, and that is something really useful when filling long forms!

In truth, some native Windows Phone apps actually do this on some fields, where tapping the Enter key will have the same result, but unfortunately this is not the default behavior.

You could simulate this behavior using the TextBox.KeyUp or TextBox.KeyDown events, and then calling Control.Focus() on the next control you want to get focus, but I guess we can all agree that this is quite some work and if you change the fields order, you’d have to change the code accordingly.

The Cimbalino Windows Phone Toolkit way

Well, as of Cimbalino Windows Phone Toolkit version 3.1.0, all you need to do is add the AutoFocusBehavior to your Page and… relax! :)

Yes, that’s really all it takes, as the behavior contains the everything needed to manage TextBox/PasswordBox control focus changes on Enter key, with some added bonus:

• TabIndex property value from controls will be taken into account and the order will be respected
• Any control with IsEnabled = false, Visibility = Collapsed, or TabStop = false will be skipped
• Any TextBox control with AcceptsEnter = true will just use the default expected behavior (tapping Enter will just add a new line)
• The AutoFocusBehavior.CycleNavigation property controls whether focus will jump from last control to first one or just focus the full page
• The AutoFocusBehavior.SelectAllOnFocus property controls whether the entire contents of a control will be selected on focus

There is also an AfterAutoFocus event and AfterAutoFocusCommand so you can easily add some extra behavior of yours to the current one! :)

Version 3.1.0 of Cimbalino Windows Phone Toolkit is now available!

Here’s the change-log for this release:

• New MarketplaceInformationService (more info)
• New MediaLibraryService
• New FMRadioService
• New LockScreenService
• New AutoFocusBehavior (more info)
• Various improvements and bug fixes

You can count on some articles around the new stuff for the next few days! :)

“The cat is out of the bag”…

…as Microsoft has confirmed that FM Radio is making a return in the next update to Windows Phone 8 (commonly known as GDR2)!

Obviously, updating your phone to GDR2 may not suffice, as the phone itself must have FM Radio tuning capability from factory!

Back when Windows Phone 7.x was king we could use the FMRadio class to control the device FM Radio, but given that no support for it was added to Windows Phone 8, accessing it in a WP8 device would just throw an exception… but that was before GDR2!

Mark Monster, Silverlight MVP, has written a really good article on how to safely use the FMRadio class across all versions of Windows Phone.

So what’s the problem?

Here’s the whole problem and how you can check it, step by step:

• Preconditions
  • Use a real phone with Windows Phone updated to GDR2
  • Plug in your headphones to the phone (the phone uses them as an FM Radio antenna)
• Steps to reproduce
  • Open Music+Videos hub
  • Tap the “radio” item to start the FM Radio tuner
  • Tune in a radio station and check that you can hear audio on the headphones
  • Open any app that uses the BackgroundAudioPlayer and start playback
• Actual Results
  • You hear the FM Radio audio and the audio from the app… at the same time!!
• Expected Results
  • FM Radio should stop and you should now be hearing the audio from the app

Basically, there seems to be some sort of issue where the FM Radio does not stop once the BackgroundAudioPlayer starts!

You can however easily bypass this issue: just ensure you stop the FM Radio playback before starting the BackgroundAudioPlayer or any other playback for that matter!

To make things easier, you can use the following code snippet:

using Microsoft.Devices.Radio;

public class FMRadioSafe
{
    private static bool? _isAvailable;

    public static bool IsAvailable
    {
        get
        {
            if (!_isAvailable.HasValue)
            {
                try
                {
                    _isAvailable = FMRadio.Instance != null;
                }
                catch
                {
                    _isAvailable = false;
                }
            }

            return _isAvailable.Value;
        }
    }

    public static void Stop()
    {
        if (IsAvailable)
        {
            FMRadio.Instance.PowerMode = RadioPowerMode.Off;
        }
    }
}

Just copy and past this to your app and call FMRadioSafe.Stop() before any audio output instruction and you’re done! :)

Update 20/08/2013: You can now use the FMRadioService from Cimbalino Windows Phone Toolkit version 3.0.0!

A few months ago, I started receiving some crash reports from one of my most successful apps, Geosense!

After fixing the issue and publishing an updated version of the app, until today I still get quite a few reports from the very same old version, but none from the updated one!

This has got me to think on the reason to why people don’t update their apps! Here are some reasons:

• No constant internet connection
• Removing the Store tile from the Home screen
• Don’t care about updating apps!

The first one doesn’t make much sense to me, as the Windows Phone ecosystem makes a lot more sense as a “always online” system! Also, Geosense requires internet connection to work and crash reports can’t be done without internet connection, so this doesn’t seem to be the main reason in my case!

I don’t see the point in it, but not caring to check and update the apps in ones phone is just a matter of personal opinion!

That leaves the middle option: having the Store tile in the Home screen will enable users to get visual notification of updates (the number of updated apps appears in the tile); without it, the only other option is that the user actually opens the Store app from the applications menu.

Wouldn’t it be nice to just get the app to notify the user that an update is available?

Keeping this in mind, I opened Fiddler on my laptop, set my phone to use it as a proxy server, opened Geosense info from the store, and this is the request I could see going to Microsoft servers:

http://marketplaceedgeservice.windowsphone.com/v8/catalog/apps/7ca9cfea-1b92-4ca4-8559-269936d5361e?os=8.0.9903.0&cc=GB&oc=&lang=en-GB&hw=520170499&dm=RM-821_eu_euro1&oemId=NOKIA&moId=VOD-GB&cf=99-1

I can see in the above url the application ProductId (7ca9cfea-1b92-4ca4-8559-269936d5361e) the windows phone version (os=8.0.9903.0), the store territory (cc=GB), the language (lang=en-GB) and a bunch of other stuff related to the device brand, model and version.

The response is even more interesting, as it shows all the Store information about the app, including the latest available version and release date.

Given we are only interested in the version, after manually clearing up the response this is what we get:

<a:feed xmlns:a="http://www.w3.org/2005/Atom" xmlns:os="http://a9.com/-/spec/opensearch/1.1/" xmlns="http://schemas.zune.net/catalog/apps/2008/02">
  <!-- other stuff -->

  <a:entry>
    <!-- other stuff -->

    <version>1.10.1.8</version>

    <!-- other stuff -->
  </a:entry>

  <!-- other stuff -->
</a:feed>

Well, we now know how to get the Store information about a particular app, we know what gets returned and how to read it, so let’s put that all together!

We will need the ProductID for the current running app, and for that we can just read it from the WMAppManifest.xml file like I shown in a previous article:

public static string GetManifestAttributeValue(string attributeName)
{
    var xmlReaderSettings = new XmlReaderSettings
    {
        XmlResolver = new XmlXapResolver()
    };

    using (var xmlReader = XmlReader.Create("WMAppManifest.xml", xmlReaderSettings))
    {
        xmlReader.ReadToDescendant("App");

        return xmlReader.GetAttribute(attributeName);
    }
}

Given that there is no way in the current SDK to retrieve the Store territory, we will fallback to the CultureInfo.CurrentUICulture value for it and also for the language.

Here’s the complete async method to retrieve the latest version information from the Store:

private Task<Version> GetUpdatedVersion()
{
    var cultureInfoName = CultureInfo.CurrentUICulture.Name;

    var url = string.Format("http://marketplaceedgeservice.windowsphone.com/v8/catalog/apps/{0}?os={1}&cc={2}&oc=&lang={3}​",
        GetManifestAttributeValue("ProductID"),
        Environment.OSVersion.Version,
        cultureInfoName.Substring(cultureInfoName.Length - 2).ToUpperInvariant(),
        cultureInfoName);

    var request = WebRequest.Create(url);

    return Task.Factory.FromAsync(request.BeginGetResponse, result =>
    {
        var response = (HttpWebResponse)request.EndGetResponse(result);

        if (response.StatusCode != HttpStatusCode.OK)
        {
            throw new WebException("Http Error: " + response.StatusCode);
        }

        using (var outputStream = response.GetResponseStream())
        {
            using (var reader = XmlReader.Create(outputStream))
            {
                reader.MoveToContent();

                var aNamespace = reader.LookupNamespace("a");

                reader.ReadToFollowing("entry", aNamespace);

                reader.ReadToDescendant("version");

                return new Version(reader.ReadElementContentAsString());
            }
        }
    }, null);
}

All you now have to do is compare it to the active app version, like in this sample code:

private async void CheckForUpdatedVersion()
{
    var currentVersion = new Version(GetManifestAttributeValue("Version"));
    var updatedVersion = await GetUpdatedVersion();

    if (updatedVersion > currentVersion
        && MessageBox.Show("Do you want to install the new version now?", "Update Available", MessageBoxButton.OKCancel) == MessageBoxResult.OK)
    {
        new MarketplaceDetailTask().Show();
    }
}

At startup, just call CheckForUpdatedVersion() and it will check if a new version is available, and if so, show a confirmation message box to the user and open the Marketplace details for the updated app.

If you’re using Cimbalino Windows Phone Toolkit, I’ve added the IMarketplaceInformationService that contains all the above logic to retrieve Store information for apps, with added bonus that will work not only for WP8 but also in WP7!

For the time being, this new service is only available in the 3.1.0-rc version of the toolkit, so make sure to install the pre-release version!

Well, how does \$19 USD sound like? :)

Until the end of August, that’s the current subscrition fee for a one year WPDev account (plus taxes)!

And in case you already have an account, you can renew your current account for the same price, as Joe Belfiore himself stated in a tweet just minutes ago!

For those of you asking... If you're already a dev you CAN renew at the $19 price! @TheRomit @mrcfield

— joebelfiore (@joebelfiore) June 27, 2013

Please check the Windows Phone Dev Center for more information!

MSDN states the following for the Mutex class:

When two or more threads need to access a shared resource at the same time, the system needs a synchronization mechanism to ensure that only one thread at a time uses the resource. Mutex is a synchronization primitive that grants exclusive access to the shared resource to only one thread. If a thread acquires a mutex, the second thread that wants to acquire that mutex is suspended until the first thread releases the mutex.

Bottom line is that the mutex is a system wide lock, not just contained to the current process!

When it comes to usage, there is a major difference between them: the lock keyword is used to contain a thread-safe block of code, and when code is executed outside of that block, the locked object is released; the mutex on the other hand, doesn’t use the same approach, and as such has to manually be released.

One situation that you can get into is when a thread terminates while owning a mutex, the mutex is said to be abandoned, and this is a really bad thing, normally indicating a serious programming error.

Unfortunately, due to the volatile nature of the Windows Phone background agents, abandoned mutexes will eventually happen without any thing a developer can actually do, but to catch and treat the AbandonedMutexException that will get raised on the other awaiting thread (if one exists)!

The following code sample simulates how to raise and handle the AbandonedMutexException:

public static void MutextTest()
{
    var mutex = new Mutex(false, "MyMutex");

    new Thread(() =>
    {
        mutex.WaitOne();

        Thread.Sleep(1000);
    }).Start();

    Thread.Sleep(2000);

    try
    {
        mutex.WaitOne();
    }
    catch (AbandonedMutexException e)
    {
        Debug.WriteLine(e);
    }
    catch (Exception e)
    {
        Debug.WriteLine(e);
    }
}

When running the above in a Console application, this is the output we get from it:

System.Threading.AbandonedMutexException: The wait completed due to an abandoned mutex.

For the same code in a Windows Phone 8 app, this will be the output:

System.Exception: The wait completed due to an abandoned mutex.

The two platforms show an inconsistent result for the same behavior, as an AbandonedMutexException get thrown for the full .NET Framework, and a generic Exception for the WP8 one.

Seems that the only thing in common is actually the message!…

One interesting fact is that the Mutex documentation for WP8 does not mention the AbandonedMutexException class, though it does exist in the WP8 class library, but doesn’t seem to be in use anywhere on the platform. This may be the result of having similar behavior as the WP7 platform, where we would actually get the same behaviour due to the lack of the more specific AbandonedMutexException class.

I’m proud to present the latest version of Cimbalino Windows Phone Toolkit!

This new version comes with a major breaking change: Visual Studio 2012 is now required, as the toolkit has taken the “async/await” path! :D

If you still use Visual Studio 2010 for your Windows Phone development, you can still use the previous version of the toolkit (but then again, seems like a really nice time to upgrade ;) )

And without further ado, here’s the change-log:

• async/await support added for WP7
• New Cimbalino.Phone.Toolkit.Background component, fully compatible with Background Agents.
• New ShellTileService
• New VoiceCommandService
• New LauncherService
• New NetworkInformationService
• AsyncStorageService is now compatible with WP7
• BingMapsService has been removed and the functionality moved to MapsService
• Several improvements and bug fixes!

Last Monday I had the pleasure of participating in a WPUG event where I talked about the Nokia Music API and the Cimbalino Windows Phone Toolkit.

I had quite a technical challenge, as I couldn’t access the internet from inside the emulator, no matter what I did!

After a couple of minutes in silent panic, I tried to bypass the connectivity problems the best I could, doing anything from showing a YouTube video of Nokia Music features to running the demos on my personal phone and showing it off in the air to the audience!

Other than that, the event went really good, and hopefully I’ll start seeing more and more people using the Nokia Music API and Cimbalino Windows Phone Toolkit in their apps! ;)

From the feedback I got, I can see people requesting more information about MVVM, so I’m going to point to two articles I wrote about two years ago for Coding4Fun (now part of Microsoft Channel9):

• Currency Converter for Windows Phone 7
• Currency Converter v2 - Now on Caffeine

My big “thank you” to Matt Lacey and Riaz Ahmed for the opportunity! :)

One of the features I most enjoy in WPF is the MultiBinding class, which allows you to take several source properties, pass their values to an IMultiValueConverter implementation, and bind the result to a single target property!

By now you’re probably thinking “why do I need that?”, but in certain specific scenarios, having the possibility to take several values and produce a single result directly in the UI can be quite useful!

Take this sample from MSDN:

<TextBlock DataContext="{StaticResource NameListData}">
  <TextBlock.Text>
    <MultiBinding Converter="{StaticResource myNameConverter}"
                  ConverterParameter="FormatLastFirst">
      <Binding Path="FirstName"/>
      <Binding Path="LastName"/>
    </MultiBinding>
  </TextBlock.Text>
</TextBlock>

We can easily infer that the objective here is to set the TextBlock.Text property to the result of “LastName, FirstName”, given the two properties from the specified TextBlock.DataContext and a custom IMultiValueConverter instance called myNameConverter.

While useful, the MultiBinding is not available for Windows Phone developers - queue the whining…

I’ve seen a few alternative implementations around the internet, but none seems easy (and light!) enough to me, so I just decided to make my own!

On the latest release of Cimbalino Windows Phone Toolkit I added the MultiBindingBehavior, a quick and easy approach to solve the missing MultiBinding support in Windows Phone!

Here’s an example using the same scenario from above:

<TextBlock DataContext="{StaticResource NameListData}">
    <i:Interaction.Behaviors>
        <cimbalinoBehaviors:MultiBindingBehavior Converter="{StaticResource myNameConverter}" ConverterParameter="FormatLastFirst" PropertyName="Text">
            <cimbalinoBehaviors:MultiBindingItem Value="{Binding FirstName}" />
            <cimbalinoBehaviors:MultiBindingItem Value="{Binding LastName}" />
        </cimbalinoBehaviors:MultiBindingBehavior>
    </i:Interaction.Behaviors>
</TextBlock>

The major difference here is the usage of MultiBindingBehavior.PropertyName, as we can’t bind the target property directly, it will be up to the behavior to get/set the value. All the rest of the code is really quite self explanatory!

Here’s another sample using two TextBox controls to input the FirstName and LastName values:

<TextBox x:Name="FirstNameTextBox" />
<TextBox x:Name="LastNameTextBox" />
<TextBlock Style="{StaticResource PhoneTextLargeStyle}">
    <i:Interaction.Behaviors>
        <cimbalinoBehaviors:MultiBindingBehavior Converter="{StaticResource myNameConverter}" ConverterParameter="FormatLastFirst" PropertyName="Text">
            <cimbalinoBehaviors:MultiBindingItem Value="{Binding Text, ElementName=FirstNameTextBox}" />
            <cimbalinoBehaviors:MultiBindingItem Value="{Binding Text, ElementName=LastNameTextBox}" />
        </cimbalinoBehaviors:MultiBindingBehavior>
    </i:Interaction.Behaviors>
</TextBlock>

You can set the MultiBindingBehavior.Converter property to any IValueConverter instance (knowing that the value parameter is always an object[] instance) but I’ve also added an abstract MultiValueConverterBase that you can inherit and implement quite easily!

I’m happy to confirm that my first presentation in the UK will be for the WPUG May 20 event.

I’ll be talking about the Nokia Music API and the Nokia Music app, but you can also count on some good info on the Cimbalino Windows Phone Toolkit!

The event venue is Nokia’s office in Paddington, London, and registration is free and required!

I just released a new Cimbalino Windows Phone Toolkit version!

Here’s a short list of all the goodies you’ll find in the 2.3.0 version:

• Breaking change: Location component now uses the new Windows Phone 8 Location API (Geolocator) on WP8 (WP7 version will mimic behavior with GeoCoordinateWatcher)
• Breaking change: In WP8, the UserExtendedPropertiesService.AnonymousUserID now returns the “ANID2” value (WP7 version will still return “ANID”)
• New MultiBindingBehavior
• New OptimizedObservableCollection class
• Several improvements and bug fixes!

I didn’t actually release a change log for the previous 2.2.0 version, so here it is now:

• New MutexLock and NamescopeBinding helper classes
• New BooleanToBrushConverter and BooleanToIntConverter
• New UriExtensions class
• The ApplicationBarBehavior and MultiApplicationBarBehavior can now be attached to the PhoneApplicationPage
• The SystemTrayService implementation now allows for a global system tray across all pages
• Removed the cimbalino = http://cimbalino.org XML namespace prefix (incompatible with WP8)
• Several improvements and bug fixes

A big “thank you” is due to Scott Lovegrove for his continuous code contributions and articles about the toolkit!

Now to write some posts about the new features… ;)

Here is the specific bit:

<phone:PhoneApplicationPage.Resources>
    <cimbalinoHelpers:NamescopeBinding x:Key="ItemsMultiselectList" Source="{Binding ElementName=ItemsMultiselectList}" />
</phone:PhoneApplicationPage.Resources>

This special class has a single property called Source that can be set to any object; in this sample, it’s pointing to a named control inside the pages LayoutRoot (hence the single Binding.ElementName property set)

If you look a bit down the code, you’ll find the ApplicationBarIconButton.CommandParameter where this resource is getting referenced:

<cimbalinoBehaviors:ApplicationBarIconButton
    Command="{Binding DeleteItemsCommand, Mode=OneTime}"
    CommandParameter="{Binding Source.SelectedItems, Source={StaticResource ItemsMultiselectList}}"
    IconUri="/Images/appbar.delete.rest.png"
    Text="delete" />

If we just put the two parts together, we can see that the whole objective is to bind the ApplicationBarIconButton.CommandParameter property to ItemsMultiselectList.SelectedItems property.

Obviously you’d expect to just do it directly, like this:

<cimbalinoBehaviors:ApplicationBarIconButton
    Command="{Binding DeleteItemsCommand, Mode=OneTime}"
    CommandParameter="{Binding SelectedItems, ElementName=ItemsMultiselectList}"
    IconUri="/Images/appbar.delete.rest.png"
    Text="delete" />

In reality, this approach doesn’t work from the PhoneApplicationPage point of view, due to the different XAML Namescope.

XAML Namescope??

Here is the XAML Namescope definition found in this MSDN article:

…a XAML namescope stores relationships between the XAML-defined names of objects and their instance equivalents. This is similar to the wider meaning of the term “namescope” in other programming languages and technologies.

So think of the XAML Namescope as a hash-table with each control name and it’s instance (something like IDictionary<string, FrameworkElement>).

The problem is that the page’s LayoutRoot control gets a different XAML Namescope from the page itself, so searching for a child control from inside the page just won’t work!

The following image illustrates the Namescope boundaries for a default new page:

This is where the NamescopeBinding helper class makes its entry: just register an instance of this class as a page resource and bind the NamescopeBinding.Source property to the control you require outside the LayoutRoot XAML Namescope as shown in the sample code, and that’s it!

In the BindableApplicationBar sample, if you actually attach the MultiApplicationBarBehavior to the LayoutRoot instead of the page, it will work perfectly without the need for the NamescopeBinding helper class.

But my advice is to always bind the ApplicationBarBehavior and MultiApplicationBarBehavior to the page as it will provide better integration and more fluid animation, and use the NamescopeBinding helper class if needed.

I’ve created a small sample app that demonstrates the XAML Namescope behavior and how it affects your applications, which you can download from here.

I particularly like the fact that all tests run on the emulator where they can get the full runtime environment of a real Windows Phone device.

Yet, the test framework still has some pitfalls where we realize it is just not enough!

A few weeks ago I wrote an article about one of these pitfalls, on how to run code in the UI Thread.

Now I’ve stumbled in yet another pitfall, this time on how to run the Assert.ThrowsException with async code!

Microsoft solved this issue on the Windows 8 version of the Test Framework, by adding some Task<Exception> Assert.ThrowsException(Func<Task>) methods, but there is no equivalent in Windows Phone.

This is my personal implementation of these methods for the Windows Phone Test Framework:

public static class AssertExtensions
{
    public static Task<T> ThrowsExceptionAsync<T>(Func<Task> action)
        where T : Exception
    {
        return ThrowsExceptionAsync<T>(action, string.Empty, null);
    }

    public static Task<T> ThrowsExceptionAsync<T>(Func<Task> action, string message)
        where T : Exception
    {
        return ThrowsExceptionAsync<T>(action, message, null);
    }

    public async static Task<T> ThrowsExceptionAsync<T>(Func<Task> action, string message, object[] parameters)
        where T : Exception
    {
        try
        {
            await action();
        }
        catch (Exception ex)
        {
            if (ex.GetType() == typeof(T))
            {
                return ex as T;
            }

            var objArray = new object[] {
                "AssertExtensions.ThrowsExceptionAsync",
                string.Format(CultureInfo.CurrentCulture, FrameworkMessages.WrongExceptionThrown, message, typeof(T).Name, ex.GetType().Name, ex.Message, ex.StackTrace)
            };

            throw new AssertFailedException(string.Format(CultureInfo.CurrentCulture, FrameworkMessages.AssertionFailed, objArray));
        }

        var objArray2 = new object[] {
            "AssertExtensions.ThrowsExceptionAsync",
            string.Format(CultureInfo.CurrentCulture, FrameworkMessages.NoExceptionThrown, message, typeof(T).Name)
        };

        throw new AssertFailedException(string.Format(CultureInfo.CurrentCulture, FrameworkMessages.AssertionFailed, objArray2));
    }
}

Just copy the above code to your test project and then use it like in this sample:

[TestMethod]
public async Task MyTestMethod()
{
    await AssertExtensions.ThrowsExceptionAsync<ArgumentException>(async () =>
    {
        await Windows.Storage.StorageFolder.GetFolderFromPathAsync("");
    });
}

This means we can now have NuGet packages without any type of assembly, targeting only the project build process.

And if you’ve read this article about the issue with the current build process for Windows 8 and Windows Phone 8 apps, where the Xml Documentation gets bundled in the output packages (APPX and XAP), I have some great news: no more need to change the project file manually, as I just published a NuGet package that does those changes for you!!

All you have to do is run the following command from the Package Manager console window:

If you have NuGet Package Manager extension installed on Visual Studio, just search for AppPackageCleanup to install the Package.

Note: this package requires NuGet 2.5 as it won’t show up in the search results with previous versions of NuGet!

Well, this seemed like the perfect opportunity to finally create some unit tests for the Cimbalino Windows Phone Toolkit and test this new test framework, all at once!

Given that this post will require installing the VS2012.2 CTP 4, a non-final preview version software that has a “go-live” license, I think it’s only proper to apply the WOMM certification to it.

So bottom line, install it at your own risk!

So I started by installing the update, launch Visual Studio 2012, and create a new Windows Phone Unit Test App.

Then, I used NuGet to add a reference to the Cimbalino Windows Phone Toolkit and then added the following test class:

namespace Cimbalino.Phone.Toolkit.Tests.Converters
{
    [TestClass]
    public class ColorToBrushConverterTests
    {
        [TestMethod]
        public void ConvertWithColorReturnsBrush()
        {
            var converter = new ColorToBrushConverter();

            var expected = Colors.Blue;

            var actual = converter.Convert(Colors.Blue, typeof(string), null, CultureInfo.CurrentCulture);

            Assert.IsInstanceOfType(actual, typeof(SolidColorBrush));
            Assert.AreEqual(((SolidColorBrush)actual).Color, expected);
        }
    }
}

This simple class will test the ColorToBrushConverter.Convert method as to check for the proper creation of a SolicColorBrush out of a specific Color.

When I ran the test, this is what happened:

As you can see here, we got an “Invalid cross-thread access” error message; this is the result of all tests running on a special “test app” inside the Emulator, but the really bad news is that they all run in a background thread.

Apparently, if this was a Windows Store app we could just change the [TestMethod] attribute with the proper [UITestMethod] one as to mark the requirement of running the test in the UI Thread, but unfortunately, the attribute is currently missing from the Windows Phone test framework!

So I decided to fix that and create my very own UITestMethodAttribute, and here it is:

[AttributeUsage(AttributeTargets.Method, AllowMultiple = false)]
public class UITestMethodAttribute : TestMethodAttribute
{
    public override TestResult[] Execute(ITestMethod testMethod)
    {
        TestResult[] result = null;

        var ar = new AutoResetEvent(false);

        Deployment.Current.Dispatcher.BeginInvoke(() =>
        {
            try
            {
                result = base.Execute(testMethod);
            }
            finally
            {
                ar.Set();
            }
        });

        ar.WaitOne();

        return result;
    }
}

If you don’t like using the AutoResetEvent, then you can use this alternative version with the new Tasks:

[AttributeUsage(AttributeTargets.Method, AllowMultiple = false)]
public class UITestMethodAttribute : TestMethodAttribute
{
    public override TestResult[] Execute(ITestMethod testMethod)
    {
        var task = ExecuteOnUi(testMethod);

        task.Wait();

        return task.Result;
    }

    private Task<TestResult[]> ExecuteOnUi(ITestMethod testMethod)
    {
        var tsc = new TaskCompletionSource<TestResult[]>();

        Deployment.Current.Dispatcher.BeginInvoke(() =>
        {
            tsc.SetResult(base.Execute(testMethod));
        });

        return tsc.Task;
    }
}

For a usage sample, please refer to the Cimbalino.Phone.Toolkit.Tests project!

Other approaches to solve this issue can be found in this post by Joost van Schaik or this gist from Jake Ginnivan, both relying on just running the necessary code in the UI instead of the full test method as with the above approach.

More than just controlling the app bar from the ViewModel, the ApplicationBarBehavior adds some nice new properties that you can’t find in the native app bar control.

Such is the nature of the IsVisible property found in the buttons and menu items, allowing to change the app bar contents with some ease!

To demonstrate the IsVisible property, I’ll use the sample code from the previous article: this will generate an app bar with 3 buttons, the first two will appear when IsSelectionDisabled = true and the 3rd one will appear when IsSelectionEnabled = true (the opposite state).

This is the recorded animation of what the state changing causes to the application bar buttons visibility:

As you can see, it works perfectly! Well, almost perfectly…

If you look really closely, you’ll notice that the animation doesn’t seem quite that smooth!

By making time go a bit slower, this is what is actually happening:

As you can see above, the buttons move before the animation starts!

This behavior is due to the nature of the ApplicationBar.Buttons and ApplicationBar.MenuItems collections: their type is IList, and as such, all we really have is the Add, Remove and Clear methods to manipulate the collection items.

And that is exactly what the ApplicationBarBehavior does behind the scenes: add or remove items when the IsVisible property of each item changes, and that is why we actually see this animation glitch.

Now presenting the MultiApplicationBarBehavior

Fixing this issue will require changing the whole application bar associated with the page, instead of just adding or removing buttons one by one.

And that is exactly what the MultiApplicationBarBehavior does: it allows you to have multiples application bar controls representing different states of the app bar!

Here’s the same app bar from the first article, now using the “multi” version:

<!-- remaining code -->

<Grid x:Name="LayoutRoot" Background="Transparent">
    <i:Interaction.Behaviors>
        <cimbalino:MultiApplicationBarBehavior SelectedIndex="{Binding ApplicationBarSelectedIndex}">
            <cimbalino:ApplicationBar>
                <cimbalino:ApplicationBarIconButton Command="{Binding AddItemCommand, Mode=OneTime}" IconUri="/Images/appbar.add.rest.png" Text="add" />
                <cimbalino:ApplicationBarIconButton Command="{Binding EnableSelectionCommand, Mode=OneTime}" IconUri="/Images/appbar.manage.rest.png" Text="select" />
            </cimbalino:ApplicationBar>
            <cimbalino:ApplicationBar>
                <cimbalino:ApplicationBarIconButton Command="{Binding DeleteItemsCommand, Mode=OneTime}" CommandParameter="{Binding SelectedItems, ElementName=ItemsMultiselectList}" IconUri="/Images/appbar.delete.rest.png" Text="delete" />
            </cimbalino:ApplicationBar>
        </cimbalino:MultiApplicationBarBehavior>
    </i:Interaction.Behaviors>

    <!-- remaining code -->

</Grid>

<!-- remaining code -->

Major difference here is the presence of multiple ApplicationBar entries, but also the MultiApplicationBarBehavior.SelectedIndex property which will allow you to select what app bar you want to show.

Here’s the recording of the app bar transition now:

Much nicer, but just to make sure, here is the same animation but about 5 times slower:

What this means is that we are unable to apply Styles or Templates to an ApplicationBar object, but most important, we are unable to bind to its properties, something that is a big issue when you what to use MVVM pattern in you apps.

Surely MVVM is not a closed pattern, and as such there are alternatives to overcome this issue (like this one or this one)!

In my case, in order to access the ApplicationBar in my apps in a more ”MVVM‘ed” way, I created the ApplicationBarBehavior that you can find in the Cimbalino Windows Phone Toolkit!

This Behavior, when applied to a PhoneApplicationPage or it’s LayoutRoot element, allows to create and maintain a fully bindable Application Bar, and as such applying a more consistent MVVM pattern.

Here’s a small sample code for it:

<!-- remaining code -->

<Grid x:Name="LayoutRoot" Background="Transparent">
    <i:Interaction.Behaviors>
        <cimbalino:ApplicationBarBehavior>
            <cimbalino:ApplicationBarIconButton Command="{Binding AddItemCommand, Mode=OneTime}" IconUri="/Images/appbar.add.rest.png" Text="add" IsVisible="{Binding IsSelectionDisabled}" />
            <cimbalino:ApplicationBarIconButton Command="{Binding EnableSelectionCommand, Mode=OneTime}" IconUri="/Images/appbar.manage.rest.png" Text="select" IsVisible="{Binding IsSelectionDisabled}" />
            <cimbalino:ApplicationBarIconButton Command="{Binding DeleteItemsCommand, Mode=OneTime}" CommandParameter="{Binding SelectedItems, ElementName=ItemsMultiselectList}" IconUri="/Images/appbar.delete.rest.png" Text="delete" IsVisible="{Binding IsSelectionEnabled}" />
        </cimbalino:ApplicationBarBehavior>
    </i:Interaction.Behaviors>

    <!-- remaining code -->

</Grid>

<!-- remaining code -->

In this small code sample we can see the ApplicationBarBehavior and in it, some ApplicationBarIconButton (like you would do in the current one), and quickly we notice some new properties like Command, CommandParamenter, and IsVisible (something we can’t even find in the base Windows Phone ApplicationBar); obviously, even the properties Text and IconUri are bindable, allowing for easy localization! ;)

A few days later, I started to get some comments over the internet regarding the need to add my fix to all projects in a solution in order to make it fully work, something that turned out to be a bit tedious…

I have now updated the original post with a new solution that will only require you to change the projects that actually have a package output! :)

Please check the original post and update your projects to match the new change!

Before you even continue reading this article, I must just address a small warning: the following information has passed the WOMM certification, and as such, this works on my machine…

Recently, while browsing StackOverflow as I normally do, I found a question that really caught my attention:

Visual Studio packs into WP8 XAP unnecessary XML doc files

If you create Windows Phone 8 App in Visual Studio and reference any libs with XML documentation files supplied from nuget or manually, Visual Studio will automatically pack those XML files into output XAP as well.

In our case this weird behavior of Visual Studio increases XAP size almost twice. (We have 8Mb of xml docs in total.)

There is no such problem for WP7 app projects.

After reading this, I had to confirm this behavior myself! Here’s what I did:

• Created a blank solution
• Added two Windows Phone projects, one with the 7.1 SDK and the other with the 8.0.
• Used NuGet to add Json.net package to both projects
• Build the solution

These are the XAP files resulting from building each project:

As you can see here, the WP8 version is about 60Kb larger than the WP7 version. That’s 42% larger!!!

Here is the content of the WP7 XAP file:

And this is the content of the WP8 XAP file:

If you look closely on the WP8 version above, you’ll see a Newtonsoft.Json.xml file - that’s the Json.net Xml Documentation!

What is it doing there? Nothing. Can we safely remove it? Most definitely, yes!

My research on why this only happens in Windows Phone 8 lead to the MSBuild process, specifically the ResolveAssemblyReferences task on Microsoft.Common.targets file: this particular task returns a variable called ReferenceCopyLocalPaths, referring to “Paths to files that should be copied to the local directory.” which upon inspection, proved to have our “garbage files”!

To fix this, edit the *.csproj files for your projects that have package outputs (XAP or APPX), and add this to the end of the file, just before the </Project> closing tag:

<PropertyGroup>
  <FilesToXapDependsOn>$(FilesToXapDependsOn);BeforeFilesToXap</FilesToXapDependsOn>
</PropertyGroup>
<Target Name="BeforeFilesToXap">
  <ItemGroup>
    <FilteredPackagingOutputs Remove="@(FilteredPackagingOutputs)" Condition="'%(FilteredPackagingOutputs.OutputGroup)' == 'CopyLocalFilesOutputGroup' AND '%(FilteredPackagingOutputs.Extension)' == '.xml'"/>
  </ItemGroup>
</Target>

This custom target will run just before the FilesToXap target, telling MSBuild to remove all XML Documentation files from the list of files to copy.

So far this has proven to work perfectly for my applications, and when I applied it to my WP8 test project, I managed to get a much more reasonable 174KB XAP file!

One final note: although this article focus on Windows Phone, I actually found out that Windows Store Apps are also affected by this issue, and that the same solution can be used to fix the problem!

This seems to be a completely random issue with Nuget, as I see it happening with different projects, and sometimes not even happening at all!

Problem is that I work with some big/complex solutions that have a lot of projects, each one with it’s own packages.config file that can show this issue, so that sums up to a lot of failed builds!

There are actually a few open tickets about this in Codeplex, but given that this issue has been reported a while ago and so far it has not been solved, I thought on tackle this myself!

“If at first you don’t succeed, try and try again”

Following that motto, I thought on changing the Nuget Package Restore process so that it will retry a few times before aborting the build!

The easiest way I found to achieve this goal is just to change the .nuget\NuGet.targets file on the root of the solution. Inside this file, I found the following:

<Target Name="RestorePackages" DependsOnTargets="CheckPrerequisites">
    <Exec Command="$(RestoreCommand)"
          Condition="'$(OS)' != 'Windows_NT' And Exists('$(PackagesConfig)')" />

    <Exec Command="$(RestoreCommand)"
          LogStandardErrorAsError="true"
          Condition="'$(OS)' == 'Windows_NT' And Exists('$(PackagesConfig)')" />
</Target>

Above you can see the MSBuild target that actually runs Nuget.exe, and so this is the one I will change to “fix” the issue.

This is my improved RestorePackages target:

<Target Name="RestorePackages" DependsOnTargets="CheckPrerequisites" Condition="Exists('$(PackagesConfig)')">
    <PropertyGroup>
        <NugetLogStandardErrorAsError Condition="'$(OS)' == 'Windows_NT'">true</NugetLogStandardErrorAsError>
        <NugetLogStandardErrorAsError Condition="'$(OS)' != 'Windows_NT'">false</NugetLogStandardErrorAsError>
    </PropertyGroup>

    <Exec Command="$(RestoreCommand)" LogStandardErrorAsError="$(NugetLogStandardErrorAsError)" IgnoreExitCode="True">
        <Output TaskParameter="ExitCode" PropertyName="ExitCode" />
    </Exec>

    <Message Text="Error occurred, #1 retry..." Importance="High" Condition=" $(ExitCode) != 0 " />

    <Exec Command="$(RestoreCommand)" LogStandardErrorAsError="$(NugetLogStandardErrorAsError)" IgnoreExitCode="True" Condition=" $(ExitCode) != 0 ">
        <Output TaskParameter="ExitCode" PropertyName="ExitCode" />
    </Exec>

    <Message Text="Error occurred, #2 and last retry..." Importance="High" Condition=" $(ExitCode) != 0 " />

    <Exec Command="$(RestoreCommand)" LogStandardErrorAsError="$(NugetLogStandardErrorAsError)" Condition=" $(ExitCode) != 0 " />
</Target>

You can see three consecutive Exec tasks here, each one will run depending on the previous one exit code, and only the last one will actually abort the build.

What this means is that if Nuget fails, we will retry it two more times before aborting the build!

As you can see, this is not a proper fix for the issue, it just bypasses it… so I’m still waiting for a fix on this - and I’m now looking at you, Nuget dev team! ;)

If all the emulator settings are set to “Portuguese (Portugal)” (both interface as all regional settings), how come when I use an IValueConverter on any Binding expression, the “culture” parameter has a “en-US” CultureInfo?…

To properly research on the subject, I created a small app with two TextBlock controls that show the Thread.CurrentThread.CurrentCulture and Thread.CurrentThread.CurrentUICulture current values, and a third TextBlock with an IValueConverter that basically returns the culture.Name he is using, and the result was quite surprising!

Here is the code for my CultureDebugValueConverter class, implementing an IValueConverter:

public class CultureDebugValueConverter : IValueConverter
{
    public object Convert(object value, Type targetType, object parameter, System.Globalization.CultureInfo culture)
    {
        return culture.Name;
    }

    public object ConvertBack(object value, Type targetType, object parameter, System.Globalization.CultureInfo culture)
    {
        throw new NotImplementedException();
    }
}

Notice that no conversion is actually being made (the value parameter isn’t even being used), it just returns the “culture.Name” value from it.

Here’s the main ContentPanel on the MainPage.xaml:

<StackPanel x:Name="ContentPanel" Grid.Row="1" Margin="12,0,12,0">
    <TextBlock Style="{StaticResource PhoneTextSubtleStyle}">CurrentCulture</TextBlock>
    <TextBlock Text="{Binding CurrentCulture}" Style="{StaticResource PhoneTextTitle2Style}" />
    <TextBlock Style="{StaticResource PhoneTextSubtleStyle}">CurrentUICulture</TextBlock>
    <TextBlock Text="{Binding CurrentUICulture}" Style="{StaticResource PhoneTextTitle2Style}" />
    <TextBlock Style="{StaticResource PhoneTextSubtleStyle}">Converter Culture</TextBlock>
    <TextBlock Text="{Binding Converter={StaticResource CultureDebugValueConverter}}" Style="{StaticResource PhoneTextTitle2Style}" />
</StackPanel>

As you can see, the last TextBlock just sets the Binding.Converter to a StaticResource of CultureDebugValueConverter type.

This is the remaining code placed on MainPage.xaml.cs:

public partial class MainPage : PhoneApplicationPage
{
    public MainPage()
    {
        InitializeComponent();

        this.DataContext = this;
    }

    public string CurrentCulture
    {
        get
        {
            return Thread.CurrentThread.CurrentCulture.Name;
        }
    }

    public string CurrentUICulture
    {
        get
        {
            return Thread.CurrentThread.CurrentUICulture.Name;
        }
    }
}

Finally, I started the emulator, changed all the regional settings to “Portuguese (Portugal), and this is what I got after running the app:

So the real question right now is: If the operating system interface, the CurrentCulture, and the CurrentUICulture are all set to “pt-PT”, from where did that “en-US” came from?

There is no trivial reason for this behavior, and to completely understand it, we first need to know how the “culture” parameter on IValueConverter.Convert method works; on the documentation, you can read the following: * The culture is determined in the following order:

• The converter looks for the ConverterCulture property on the Binding object.
• If the ConverterCulture value is null, the value of the Language property is used.

Given that I didn’t set the Binding.ConverterCulture property, this means it will fallback to the FrameworkElement.Language, which in turn has this in the docs:

The default is an XmlLanguage object that has its IetfLanguageTag value set to the string “en-US”**

We have finally found the “guilty” one!!!

Now that we know this, we can fix it just by setting the Page.Language property! The fixed code should look something like this:

public MainPage()
{
    Language = System.Windows.Markup.XmlLanguage.GetLanguage(Thread.CurrentThread.CurrentUICulture.Name);

    InitializeComponent();

    this.DataContext = this;
}

If you look closely on the 3rd line, you’ll see the Language property set to a XmlLanguage instance created with the CurrentUICulture.Name.

Be aware that for this to work, you must set the Language property before the InitializeComponent method gets invoked!

And here’s the final result:

I honestly don’t know the reason for this strange behavior, but this is a problem to account for if you have localization needs for your Windows Phone app!

The demo project I created and used for this article can be downloaded from here!

The first thing you need to know in order to understand why this is happening, is that the TextBox control only updates the Text binding source when the control looses focus.

Second reason is that the ApplicationBar control can’t get focus, nor can it’s ApplicationBarIconButton or ApplicationBarMenuItem controls, so when you tap on them, the click event will be invoked without the TextBox control ever loosing focus!

To fix this behavior we need to force an update on the binding source when the click event get’s invoked, and here’s some code on how to achieve this:

var focusedElement = FocusManager.GetFocusedElement();
var focusedTextBox = focusedElement as TextBox;

if (focusedTextBox != null)
{
    var binding = focusedTextBox.GetBindingExpression(TextBox.TextProperty);

    if (binding != null)
    {
        binding.UpdateSource();
    }
}

We start by using FocusManager.GetFocusedElement method to get the current focused element. Then we check if that is a TextBox control, and if so, force it to update the Text property binding source!

The same problem will happen with PasswordBox, so it’s best just to handle both situations and encapsulate this in a reusable method:

public static void FocusedTextBoxUpdateSource()
{
    var focusedElement = FocusManager.GetFocusedElement();
    var focusedTextBox = focusedElement as TextBox;

    if (focusedTextBox != null)
    {
        var binding = focusedTextBox.GetBindingExpression(TextBox.TextProperty);

        if (binding != null)
        {
            binding.UpdateSource();
        }
    }
    else
    {
        var focusedPasswordBox = focusedElement as PasswordBox;

        if (focusedPasswordBox != null)
        {
            var binding = focusedPasswordBox.GetBindingExpression(PasswordBox.PasswordProperty);

            if (binding != null)
            {
                binding.UpdateSource();
            }
        }
    }
}

All you now need is to call the FocusedTextBoxUpdateSource method in the start of the app bar item control click event handler so that it will update the binding source before the rest of the code runs!

You can find this problem fixed on some toolkits and frameworks, like Caliburn.Micro and my own Cimbalino Windows Phone Toolkit ApplicationBarBehavior.

Another way to fix this would be by updating the binding source on text changed rather than when it looses focus, and for that you can use the TextBinding helper from Coding4Fun Toolkit for Windows Phone.

Wouldn’t it be great to just use await chooser.ShowAsync() and get the results immediately?

All choosers extend the ChooserBase<TTaskEventArgs> class, and it’s exactly for this class that we are going to use to create a ShowAsync extension method.

We start by creating the extension method signature:

public static class ExtensionMethods
{
    public static Task<TTaskEventArgs> ShowAsync<TTaskEventArgs>(this ChooserBase<TTaskEventArgs> chooser)
        where TTaskEventArgs : TaskEventArgs
    {
    }
}

The async methods are required to return void, Task, or Task<TResult> in order to be invoked with the await keyword. So our method will return a Task<TTaskEventArgs> value, where the TTaskEventArgs generic type must be a TaskEventArgs subtype.

We will need to use a TaskCompletionSource object so we can return a Task and later on set the result of the asynchronous operation.

var taskCompletionSource = new TaskCompletionSource<TTaskEventArgs>();

Next we will add the code for the normal Chooser handling:

EventHandler<TTaskEventArgs> completed = null;

completed = (s, e) => {
    chooser.Completed -= completed;

    taskCompletionSource.SetResult(e);
};

chooser.Completed += completed;
chooser.Show();

Notice that we are removing the event handler after it gets invoked as not to have a memory leak! All that is missing now is just returning the Task object:

return taskCompletionSource.Task;

And that’s it!

Here’s how the full extension method should look:

public static class ExtensionMethods {
    public static Task<TTaskEventArgs> ShowAsync<TTaskEventArgs>(this ChooserBase<TTaskEventArgs> chooser)
        where TTaskEventArgs : TaskEventArgs
    {
        var taskCompletionSource = new TaskCompletionSource<TTaskEventArgs>();

        EventHandler<TTaskEventArgs> completed = null;

        completed = (s, e) => {
            chooser.Completed -= completed;

            taskCompletionSource.SetResult(e);
        };

        chooser.Completed += completed;
        chooser.Show();

        return taskCompletionSource.Task;
    }
}

You can download a sample code for this directly from the Microsoft Code Gallery.

When the Windows Phone SDK started to allow developers to remove entries from the navigation back stack, they (inadvertly?) introduced a bug in PhoneApplicationFrame, more specifically in the CanGoBack property!

Here’s how to simulate the issue:

• Start by creating two separate pages
• On the application start page, add a Button that when clicked will just navigate to the second page (thus adding an item to the navigation stack)
• On the second page Loaded event, call the NavigationService.RemoveBackEntry (removing the previously added item from the navigation stack)
• Get the current PhoneApplicationFrame instance with (PhoneApplicationFrame)App.Current.RootVisual
• Compare the NavigationService.CanGoBack and PhoneApplicationFrame.CanGoBack property values: the first indicates false, the correct and expected value, while the second indicates true, something that should not happen because we just cleared the navigation back stack when we removed the only entry that was there!!

By using a Reflection tool to look at the PhoneApplicationFrame implementation, one could easily realize that while the methods Navigate, GoBack, RemoveBackEntry and others are just proxies to the same ones on NavigationService, this is not true for the CanGoBack and CanGoForward properties, which have local values and only get updated after a navigation event!

And this is where lies the whole problem: the values ​​of these properties should be obtained directly from NavigationService like the methods are, or at least they should also be updated when RemoveBackEntry method gets called!

You can test and confirm this bug by downloading this sample application.

All you need to do is run the app, click on “Navigate to self”, check that the stack count is now 1, click on one of the two buttons for the “RemoveBackEntry” and realize that the CanGoBack properties now have different values!

This situation has been fixed in the implementation of the INavigationService on Cimbalino Windows Phone Toolkit, but be aware that there are still a lot of similar services implementations from other toolkits and frameworks that have this bug…

Updated on 20/01/2013: After a few tweets with Joost van Schaik, he updated the INavigationService implementation on Wp7nl utilities to match the Cimbalino Windows Phone Toolkit.

For a while this address was home for my Portuguese blog Nação do Cimbalino. Rest assure that the blog still exists, it just got moved to a new address!

I’ll be working to get the blog up and running in the next few days, so please bare with me.

I promise it will be worth it! ;)