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

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:

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

All you now have to do is compare it to the active app version, like in this sample code:

privateasyncvoidCheckForUpdatedVersion(){varcurrentVersion=newVersion(GetManifestAttributeValue("Version"));varupdatedVersion=awaitGetUpdatedVersion();if(updatedVersion>currentVersion&&MessageBox.Show("Do you want to install the new version now?","Update Available",MessageBoxButton.OKCancel)==MessageBoxResult.OK){newMarketplaceDetailTask().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.

You’ve been playing with Visual Studio Express for a while, creating some new cool apps and games for Windows Phone, and now you want to publish them but the $99 USD price tag on the developer account seems a bit steep!

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

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:

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

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!

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!

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:

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!