Cimbalino Windows Phone Toolkit Updated to v3.1.0

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! :)

FMRadio vs. BackgroundAudioPlayer… fight!!

“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!

Checking for updates from inside a Windows Phone app

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!

The AbandonedMutexException hoax!

When working with multi-process applications, there comes a time where you’ll definitely need some sort of synchronization, and for that specific purpose we have the Mutex class.

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.

Cimbalino Windows Phone Toolkit Updated to v3.0.0

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!

Review of my WPUG talk

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):

My big “thank you” to Matt Lacey and Riaz Ahmed for the opportunity! :)

Cimbalino Windows Phone Toolkit: MultiBindingBehavior

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!</p>

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!