Category: Windows Phone

Every Live Tile deserves a Windows Phone Application

Over the last week I have been writing about Live Tiles in Windows Phone Mango, how you can create Secondary Live Tiles and how you can display information on the back of Live Tiles and periodically change that information. There is more to write about Live Tiles, but I think it is time to change the topic slightly.

In part 4 of the Live Tile mini series, I introduced an application that adds a Secondary Tile to the Start Screen of your phone. That application is now almost finished in its first version. This free application has a Secondary Tile, it contains an AdControl, deals with location awareness and periodically updates the Secondary Tile. It also can access Marketplace, both to submit a review for the application and to display other applications that are published by me. All in all it is a complete application, yet its functionality is very simple. It is simple enough to explain it almost entirely. That is exactly what I am planning to do over the upcoming weeks.

Initially, the application makes use of code behind. In a later version it will be changed, making use of MVVM and Unit Testing. The application will also act as a sample to show profiling, debugging background agents and many more topics. I will combine blog entries and videos to show how to create this application, how to test it and hopefully how to publish it to Marketplace. As soon as the application is available for download, I will let you know in this blog entry. Here is a sneak preview of EvenTiles.

This application is very simple, yet it contains lots of functionality that you can use inside a Windows Phone application. When the application is started, it checks if a Secondary Tile exists. Actually, it can even be started by clicking on its Secondary Tile when available. If no Secondary Tile is pinned to the start screen, the user has the option to create a Secondary Tile and automatically pin it to the Start Screen. When the Secondary Tile is already pinned on the Start Screen, the user has the possibility to remove it from the Start Screen. You can also see that the application has advertisements. In order to allow for localized advertisements, the application reads the current location of the device once (if the user allows doing that). The application has a Settings Page that can be reached through the ApplicationBar as well as an About Page. To preserve data, the application makes of of Isolated Storage. To transfer data between the application and its background agent, a file in IsolatedStorage is used that is protected by a Mutex. So even though the application itself is very simple, it contains many pieces of functionality that you can use in very complex applications as well. As such, this application is hopefully a starting point that allows you to develop fantastic Windows Phone Applications. Stay tuned for the first part of EvenTiles from Start to Finish – Part 1, which shows you how to create the initial solution and how to create a Secondary Live tile.

Every Windows Phone application deserves Live Tiles (part 4)

My previous post about Live Tiles showed you how you can use a PeriodicTask to update your Application’s Live Tile periodically from inside the phone. Now we are going to move a little beyond Application Tiles and move towards Secondary Tiles.

Matthijs Hoekstra, Microsoft’s Dutch Windows Phone Champ, inspired me to create the following sample application. The application creates a single Secondary Tile and that is about it. This application is great to make the number of tiles on the phone’s start screen even (which simply looks better). At the same time, the application has limited functionality, making it easier to concentrate on functionality that is needed to create and update the Secondary Tile.

Each application can create multiple Secondary Tiles. These Secondary Tiles are created programmatically, and will be pinned on the user’s start screen after they are created. They do have the same properties and update possibilities as Application Tiles. However, an application always has an Application Tile, regardless from it being pinned on the start screen or not. Secondary Tiles are completely optional. End users of course have the possibility to unpin the Secondary Tile again from the start screen, so you should not automatically assume that a Secondary Tile you created inside your application will live on the phone’s Start Screen forever. One important difference between the Application Tile and a Secondary Tile is the possibility for a Secondary Tile to specify a navigation URI. With this URI it is possible to immediately navigate to a particular page inside an application and / or to pass additional data to a particular page. Because users can unpin Secondary Tiles, it is not wise to only allow navigating to a particular page through a Secondary Tile, even though this would be technically possible.

Let’s take a look how to create a Secondary Tile inside an application. The sample code that you will see is all part of the sample application that simply creates a Secondary Tile. The application also has a few options to change the appearance of the tile, which will be described in future blog entries around Live Tiles. In the sample application, a Secondary Tile is created when the user clicks a button. Technically, this could also be done automatically, for instance in the constructor of the MainPage. This code snippet is responsible for creating a Secondary Tile:

Creating a Secondary Tile

private void btnInstall_Click(object sender, RoutedEventArgs e)
{
    ShellTile TileToFind = ShellTile.ActiveTiles.FirstOrDefault(x => x.NavigationUri.ToString().Contains("TileId=Secondary"));
 
    if (TileToFind == null)
    {
        StandardTileData NewTileData = new StandardTileData
        {
            BackgroundImage = new Uri("Tile.png", UriKind.Relative),
            Title = "Even Tiles",
            Count = 0,
            BackBackgroundImage = new Uri("Tile.png", UriKind.Relative),
            BackTitle = "Even Tiles",
            BackContent = "Show even # of tiles on Start Screen",
        };
 
        ShellTile.Create(new Uri("/MainPage.xaml?TileId=Secondary", UriKind.Relative), NewTileData);
        btnInstall.Content = removeText;
    }
    else
    {
        TileToFind.Delete();
        btnInstall.Content = addText;
    }
}

In the above code snippet we first check if the Secondary Tile currently exists. If not, a new Secondary Tile will be created containing both foreground and background information. The Secondary Tile also contains a Uri, containing the address of the MainPage, but it also passes additional data so we can determine if the MainPage was started from the Secondary Tile or not. If, on the other hand a Secondary Tile does exist, it will be deleted and the user has the possibility to create another Secondary Tile. As you can see, the ShellTile class is used to create or access the Secondary Tile. Identical to Application Tiles, the StandardTileData class is used to modify properties on the tile.

In the OnNavigatedTo method the reason for navigating to the MainPage is determined by checking if the Secondary Tile caused this. If so, the user has the possibility to delete the Secondary Tile. If the application was started traditionally, we are checking for an existing Secondary Tile and set Button Content accordingly. This is shown in the next code snippet:

Secondary Tile Navigation?

protected override void OnNavigatedTo(System.Windows.Navigation.NavigationEventArgs e)
{
    base.OnNavigatedTo(e);
 
    btnInstall.Content = addText;
 
    if (NavigationContext.QueryString.ContainsKey("TileId"))
    {
        btnInstall.Content = removeText;
    }
    else
    {
        ShellTile TileToFind = ShellTile.ActiveTiles.FirstOrDefault(x => x.NavigationUri.ToString().Contains("TileId=Secondary"));
        if (TileToFind != null)
        {
            btnInstall.Content = removeText;
        }
    }
}

The initial version of the sample application looks like this:

In the next part of this series we will take a look at additional possibilities you have to update your Live Tiles.

Every Windows Phone application deserves a Live Tile (part 3)

My previous post about Live Tiles showed you how to update the back side of the Application Tile inside an application. The big drawback of this approach is that your tile will only be updated as a result of your application being executed. Depending on the information you want to display on your tile, you might want to take another approach to update your application’s tiles.

This time we will make use of a Background Agent to periodically update the Application Tile without the need for the application to actually run. We again work on the same sample application, Clicker, and extend its functionality by adding a PeriodicTask. A PeriodicTask is supposed to be lightweight and will run at fixed intervals. A PeriodicTask will not run forever, but it expires after at most 14 days. From within the running application, the PeriodicTask can be renewed before the expiration date. In this way, applications that are not used will not continue to use precious device resources through a PeriodicTask forever.

Back to our tile though. The scenario we want to implement is the following. The backside of the tile already displays the high score. It would be nice to alternate between showing the game’s high score and showing the amount of time the game has not been played. To implement this functionality, a PeriodicTask is ideal.

In order to make use of a PeriodicTask, a new project of type Windows Phone Scheduled Task Agent must be added to the solution containing the Clicker application. This newly created project already contains an OnInvoke method that is called each time the PeriodicTask executes. Inside the OnInvoke method, the back side of the live tile is updated. The PeriodicTask will execute approximately once every 30 minutes. It is important to determine how data can be exchanged between the application and the PeriodicTask. The PeriodicTask has access to the application’s IsolatedStorage. In Clicker, a file is used to save the high score, which in turn is read by the PeriodicTask. Since the OnInvoke method will execute on a thread and will be terminated after being executed, data needed for the PeriodicTask must also be persisted in IsolatedStorage. To store and retrieve high scores, a static class is available inside the Clicker application. This class will be used in the application to store high scores. The same class will also be used in the PeriodicTask to retrieve high scores. Together with the high score, also a boolean variable is stored, indicating if the high score or an informational message should be stored on the back of the Application Tile.

Retrieving HighScore info

public static string GetLiveTileBack()
{
    string highScore = string.Empty;
    bool showHighScore;
 
    using (var store = IsolatedStorageFile.GetUserStoreForApplication())
    {
        mtx.WaitOne();
        if (store.FileExists(highScoreFileName))
        {
            string storedHighScore;
 
            using (var highScoreStream = new StreamReader(store.OpenFile(highScoreFileName, FileMode.Open)))
            {
                showHighScore = Convert.ToBoolean(highScoreStream.ReadLine());
                storedHighScore = highScoreStream.ReadToEnd();
            }
 
            if (showHighScore)
            {
                highScore = storedHighScore;
            }
 
            using (var highScoreStream = new StreamWriter(store.CreateFile(highScoreFileName)))
            {
                showHighScore = !showHighScore;
                highScoreStream.WriteLine(showHighScore.ToString());
                highScoreStream.WriteLine(storedHighScore.ToString());
            }
        }
        mtx.ReleaseMutex();
    }
 
    return highScore;
}

The following code shows how the PeriodicTask is created / renewed and scheduled to update the Live Tile of the application.

Creating the PeriodicTask

public static void PeriodicTileUpdater()
{
    PeriodicTask periodicTask = ScheduledActionService.Find(periodicTaskName) as PeriodicTask;
 
    if (periodicTask != null)
    {
        RemoveAgent(periodicTaskName);
    }
 
    periodicTask = new PeriodicTask(periodicTaskName)
    {
        Description = "Periodic Task to Update the ApplicationTile"
    };
 
    // Place the call to Add in a try block in case the user has disabled agents.
    try
    {
        ScheduledActionService.Add(periodicTask);
 
        // If debugging is enabled, use LaunchForTest to launch the agent in one minute.
#if DEBUG_TASK
        ScheduledActionService.LaunchForTest(periodicTaskName, TimeSpan.FromSeconds(30));
#endif
    }
    catch (InvalidOperationException)
    {
    }
}

To make debugging easier, the PeriodicTask will execute every 30 seconds in debug mode, instead of every 30 minutes. The other important piece of functionality is in the PeriodicTask itself. The OnInvoke method is started every 30 minutes (every 30 seconds in debug mode). It retrieves the information to be displayed on the back of the Application Tile.

Heart of the PeriodicTask

protected override void OnInvoke(ScheduledTask task)
{
    if (task.Name.Contains(clickerTaskName))
    {
        // Application Tile is always the first Tile, even if it is not pinned to Start.
        ShellTile TileToFind = ShellTile.ActiveTiles.First();
               
        if (TileToFind != null)
        {
            string backContent = LiveTile.GetLiveTileBack();
 
            if (backContent == string.Empty)
            {
                backContent = "Isn't it time to play again";
            }
 
            StandardTileData NewTileData = new StandardTileData
            {
                BackContent = backContent
            };
 
            TileToFind.Update(NewTileData);
        }
 
#if DEBUG_TASK
        ScheduledActionService.LaunchForTest(task.Name, TimeSpan.FromSeconds(30));
#endif
    }
 
    NotifyComplete();
}

At the end of the OnInvoke method you will see a call to NotifyComplete. This call is important because it releases resources of the PeriodicTask. Omitting to do this means the PeriodicTask will not be rescheduled to run again after the specified interval in debug mode or after the fixed interval in release mode.

Where is that Mutex?

In the continuous story of Live Tiles I wanted to write about updating the Application Tile by using a PeriodicTask. This is a very nice way to update the tile without having to make use of a remote service. However, the PeriodicTask needs to get some data that is available in my application. The way to go is to store that data in a file in IsolatedStorage in the application and have the PeriodicTask retrieve the data from that same file, since it has access to IsolatedStorage.

Since the application might update data that the PeriodicTask needs and since both of them are executing independently from each other, it is a good idea to protect the data by means of a synchronization object. The documentation for Background Agents even suggests using a Mutex for this purpose.

And this is where the fun started for me. I tried to create a Mutex inside my application, and time and again I ran into an issue. The Mutex object was clearly unknown in my application, even though I did add a using directive for System.Threading.

It took me quite some time to figure out what was going on here, especially since the PeriodicTask that I was perfectly capable of using a Mutex. Both are Windows Phone projects, both have access to more or less the same namespaces. And yet, there was this difference in recognizing a Mutex object.

Taking another look at the documentation for the Mutex did not really help me, although it should have helped me, because there is a hint in the documentation that I completely missed.

Even though I was reading the above documentation several times, I didn’t get it. I know I had access to the System.Threading namespace and I still could not use the Mutex. So I started searching for a solution on the Internet and I was not really successful in that, although I got the indication that folks are using Mutex objects in Windows Phone Mango applications. All in all I guess I wasted at least one hour when I decided to compare references to assemblies in both the application and the PeriodicTask projects. Here I found one subtle difference.

The difference between the two projects is a reference to mscorlib.extensions. After adding a reference to that assembly in my application’s project, I could use the Mutex. Of course it simply comes back to reading the documentation, because it does indicate that the necessary assembly is mscorelib.extensions (in mscorlib.Extensions.dll). Ignoring that one little sentence delayed me for at least one hour. Hopefully you don’t fall in the same trap.

Every Windows Phone application deserves a Live Tile (part 2)

My previous post about Live Tiles showed you how to use both sides of the Application Tile in Windows Phone Mango and how to initialize it in the WMAppManifest.xml file. You also learned how to add local language support.

Now we will focus on how to update the Application Tile within your application. Even though this is considered to be a live update of the tile, the update is not triggered by a schedule. This means that the Application Tile for the sample application will not be updated spontaneously when you are looking at it on the start screen of your device. However, it will alternate between front and back side and it will show relevant information on the back.

In order to show you how to update the Application Tile from within your own application, we again take the same sample application, Clicker, and extend its functionality. Each time the game is played, we will check for a new best time. If there is a new best time, it will be visible on the back side of the Application Tile, together with the date. In order to update an Application Tile, two steps are necessary.

First you need to get access to the Application Tile. This is possible by retrieving the first tile from the generic IEnumerable collection of active tiles that belong to the application. The first tile is always the Application Tile. This tile always exists (even if the user has not pinned the Application Tile to the start screen). Optionally, one or more Secondary Tiles can also be part of the collection of Active Tiles. In order to easily get to a particular tile in the collection of ActiveTiles, methods on the Enumerable class can be called. Since this class is implemented in the System.Linq namespace, you must also add a using directive to System.Linq. Omitting to do so results in compilation errors.

Assuming you have retrieved the Application Tile from the collection, you can modify it by creating a new StandardTileData class and initializing it with the data items that you want to change on the tile. It is sufficient to set only changed properties to an instance of the StandardTileData class. In our sample, we will only update the BackContent property, but it is also possible to change the entire appearance of (both sides of) the tile if you want to do so.

Finally, you need to modify the Application Tile by calling the Update method on the found ApplicationTile, passing the newly created instance of the StandardTileData. I decided to create a static class with one method to update the Application Tile. The reason to do so is that this class will be re-used in a few similar, but different applications.

Updating the Application Tile

using System;
using System.Linq;
using System.Text;
using Clicker.Controls.Localization;
using Microsoft.Phone.Shell;
using System.Globalization;
 
namespace Clicker.Controls
{
    public static class LiveTile
    {
        public static void UpdateLiveTile(TimeSpan bestTime, DateTime bestTimeDate)
        {
            // Application Tile is always the first Tile, even if it is not pinned to Start.
            ShellTile TileToFind = ShellTile.ActiveTiles.First();
 
            if (TileToFind != null)
            {
                StringBuilder sb = new StringBuilder();
                sb.AppendLine(ControlResources.BestTime);
                sb.AppendLine(bestTime.TotalSeconds.ToString("N2", CultureInfo.CurrentCulture.NumberFormat));
                sb.AppendLine(ControlResources.BestTimeDate);
                sb.AppendLine(bestTimeDate.ToString("d", CultureInfo.CurrentCulture.DateTimeFormat));
 
                StandardTileData NewTileData = new StandardTileData
                {
                    BackContent = sb.ToString(),
                };
 
                TileToFind.Update(NewTileData);
            }
        }
    }
}

The result after playing the came a few times now looks like this:

The UpdateLiveTile method uses localization and is called each time the user has a high score. The only down side of a localized tile that I can think of is the fact that the tile does not automatically change to another local language when the user changes the language of the device. The tile will be modified if the application has executed one time, but if the application has not been executed, the tile will keep the original local language. The reason for that is that the tile is only updated inside the application, so the application has to run in order to display modified content on the tile. Since I don’t expect users to frequently change local languages on devices, I don’t think this is much of a limitation. In my first post about tiles, I wrote that the Mango update of Clicker will be available with this blog post. Unfortunately that is not the case, so I will make sure to send out a tweet when the updated version of Clicker hits Marketplaces all over the world.

Every Windows Phone application deserves a Live Tile (part 1)

Live Tiles have been one of the nice differentiators of Windows Phone. In Mango, Live Tiles even got better, as a matter of facts, way better for end users and for 3rd party application developers. Today, applications can benefit from multiple secondary tiles that allow deep linking into the application. With Mango, all tiles have a front and a back that can contain different information. On the home screen, tiles with information stored on both the front and the back side will regularly flip over to see both sides of the tile.

In this article you will learn how even the simplest applications can benefit from live tiles, with the possibility to update the information presented on the tile locally.

Each application has at least one tile, the application tile. It is up to the user to pin this tile to the start screen on their phone. By default, this tile is single sided, meaning it will not flip over to show the back to the user.

In order to use both sides of a tile, you can initially add the appropriate properties to the WMAppManifest.xml file. The cool part of completely defining your double sided application tile in the WMAppManifest.xml file is that the tile starts rotating immediately when the user pins the tile to the start screen, even if the application has never been started by the user. That is the starting point of this blog entry.

One of my sample applications that is available through the Windows Phone Marketplace is a simple game called Clicker. In its original form it of course has an application tile, that simply looks like this. The tile only shows the application title and uses transparency to display some areas using the selected theme color on the phone.

Initially, the backside of the tile will contain a text inviting a user to play a game. Therefore an initial backside of the tile is created in the WMAppManifest.xml file as follows:

<Tokens>
  <PrimaryToken TokenID="ClickerToken" TaskName="_default">
    <TemplateType5>
      <BackgroundImageURI IsRelative="true" IsResource="false">Background.png</BackgroundImageURI>
      <Count>0</Count>
      <Title>Clicker</Title>
      <BackBackgroundImageUri IsRelative="true" IsResource="false">Images/BackBackground.png</BackBackgroundImageUri>
      <BackTitle>Clicker</BackTitle>
      <BackContent>Play and beat your own high score!</BackContent>
    </TemplateType5>
  </PrimaryToken>
</Tokens>

Even though this is an acceptable first approach, the end user experience could still be improved. Clicker is a localized application with support for a few different languages. The message on the back of the application tile should therefore be localized as well for the different supported languages. With a little extra effort that can be achieved as well.

In order to put localized strings in the manifest file, you need to provide a native resource DLL for each local language that your application supports. If you are using Visual Studio 2010 Professional or better to develop your Windows Phone applications, you can literally follow the actions that are described in this MSDN How to page. However, if you are using the express edition of Visual Studio 2010 to develop your Windows Phone applications, you cannot create a native Win32 DLL. In that situation, you might be able to use the tool that Patrick Getzman created to localize application tiles. I am not sure if this tool currently supports creating localized BackTitle and BackContent strings though. If not you either have to kindly ask Patrick for support or you can make use of the free Visual C++ 2010 Express version to create the resource DLL.

Here are the two different string tables that I created in a neutral language resource DLL and in a Dutch language resource DLL.

ID	Value	Caption
AppTitle	100	Clicker
AppTileString	200	Clicker
AppTileBackString	300	Clicker
AppTileBackContent	400	Play clicker and beat your own high score!

Neutral Language String Table in AppResLib.dll

ID	Value	Caption
AppTitle	100	Clicker
AppTileString	200	Clicker
AppTileBackString	300	Clicker
AppTileBackContent	400	Speel en verbeter je beste score!

Dutch Language String Table in AppResLib.dll.0413.mui

After changing the WMAppManifest.xml file’s TemplateType5 content to the following, the application tile now appears in Dutch on a Dutch Windows Phone 7.5 device and in US English on any other device.

<Tokens>
  <PrimaryToken TokenID="ClickerToken" TaskName="_default">
    <TemplateType5>
      <BackgroundImageURI IsRelative="true" IsResource="false">Background.png</BackgroundImageURI>
      <Count>0</Count>
      <Title>@AppResLib.dll,-200</Title>
      <BackBackgroundImageUri IsRelative="true" IsResource="false">Images/BackBackground.png</BackBackgroundImageUri>
      <BackTitle>@AppResLib.dll,-300</BackTitle>
      <BackContent>@AppResLib.dll,-400</BackContent>
    </TemplateType5>
  </PrimaryToken>
</Tokens>

And here is the result:

The next blog entry will dig deeper into live tiles and shows you how to update the high score for this game on the backside of the application tile. At that time, the Mango update of the Clicker application will also be available through Marketplace. If you can’t wait to start playing with the application, the current version (without live tiles) is available here for download or at your own local Windows Phone Marketplace.

Other parts in this series:

If you want to learn more on how to develop a Windows Phone Application, make sure to take a look at EvenTiles, a series on Windows Phone Application Development with articles, videos and source code available for download.

Running for the first time

This time I cannot be objective, because today I created an Android application for the very first time and I created a Windows Phone application (definitely not for the first time). So what I am really doing is comparing my first Android experience with my first Windows Phone experience, way over a year ago already. At that time, even with the beta tools installation was a simple one click operation, after which I could create a typical hello world application and immediately execute it on the emulator. The whole process took less than 30 minutes. Even though Silverlight was new for me, I was of course familiar with Visual Studio, C# and the .NET (Compact) Framework.

Today I did something similar. I already described my experience installing the Android development tools. Now it is time to try my first application on Android. I have to admit that I have no experience at all with Java or with Eclipse, so my comparison is a bit unfair. That is also the reason to chose a very simple Hello World application to get going. Of course this is a good idea in general, since such a simple application can quickly be used to verify if the development environment is installed correctly and to see if things simply work.

Before I could get to work, I first needed to add an Android Platform in my Eclipse environment. This additional step is necessary because Eclipse is a versatile development environment and because there are different Android versions. The other thing that needs to be done is to actually create an Android Virtual Device, which is the emulator that can be used as target to run / test applications. Building an AVD takes some time, but is not really a bad thing. At least you know that you will have a target for a specific Android version.

Creating a new project differs slightly between Windows Phone and Android. The same is true for the functionality of the application. The two differ because they are using different development environments and programming languages, but they are of similar complexity.

My Windows Phone application looks like this, created in Visual Studio 2010 Express for Windows Phone:

Deliberately I created all functionality in code to better compare this application to the Android application. A corresponding Android application looks like this:

Compiling and deploying the Windows Phone application to the emulator was no problem at all. The emulator booted within 30 seconds after which the application was deployed and automatically started. It was a bit harder to get my Android application up an running in an emulator though. The first problem I ran into was a cryptic error I got when trying to deploy my Android application. The error was shown in the Eclipse console window:

It turns out that this error is caused by spaces in directory paths. I am not sure if this is an Eclipse issue or an Android SDK issue, but a solution to this problem was to create a logical link to the folder where the Android SDK was installed using a Command Prompt. This did the trick (of course after making sure inside Eclipse that the IDE now pointed to the newly created logical link).

MKLINK /J C:\Android "C:\Program Files (x86)\Android\android-sdk\"

Adding this link assured that the AVD did start. However, I still could not deploy the application to the virtual machine, this time because of another error:

It seems that this was simply a timeout error, because it takes quite some time to boot the AVD. Once it was entirely booted I tried running the application again and this time it was successful.

The scores for this exercise are clear. I needed to solve two (more or less cryptic) problems before I was able to run my application on the Android emulator. Deploying to the Windows Phone emulator caused no problems at all. Booting time for the Windows Phone emulator was around 30 seconds, the Android (3.2) emulator needed several minutes.

After installing the tools, my score was:

Windows Phone vs. Android: 1 – 0

After developing and creating a Hello World application, the scores are now:

Windows Phone vs. Android: 4 – 1

The reason why Windows Phone is a clear winner for me is the fact that deploying to the emulator just works and that the emulator boots relatively fast. The point I gave to Android might in fact belong to Eclipse. I really love maximize icon in the edit window, great for demos and something that I would not mind having in Visual Studio as well.

Over the upcoming weeks I will continue to compare Windows Phone with Android application development. So far there is a clear winner for me, but I want to really and honestly compare several aspects of developing applications on different platforms. Oh, just to be complete: My winner today is without any doubt

Windows Phone.

Where did my ads go?

Since a few weeks, Windows Phone developers can retrieve data on crash counts and stack traces for each published application through the App Hub. Because two of my applications indeed showed a few crash counts, it was of course time to fix the issues and to update the applications. One of those applications, ClickerLite, uses the AdControl to display advertisements inside the application. Besides fixing bugs, I also built the application against the latest version of the Windows Phone SDK. Instead of having to download and use a separate assembly to enable (Microsoft Advertising pubCenter) ads, the Microsoft Advertising SDK for Windows Phone is now part of the Windows Phone SDK. Of course this makes it easier to use the AdControl with full designer support in both Visual Studio 2010 and in Expression Blend 4.0. However, when I started to test my application, the AdControl was not visible, even though I did set the control up to receive test ads.

As often, the solution to the problem was easy, although it took me some time to find it. I simply needed to add the ID_CAP_MEDIALIB capability to my application’s manifest file. In the previous version of the Advertising SDK, this capability was not required and therefore not included in the manifest file. The end result was test advertisements showing up in the Visual Studio 2010 designer. However, when running the application (both in the emulator and on a real device), the test advertisements did not show up. This of course was also a clear indication that real advertisements would not show up in a released version of the application.

Adding ID_CAP_MEDIALIB solved the problem, the test ad showed up during testing, and the application was ready to be updated.

On a side note, if you are curious about ClickerLite, you can find it here on the Windows Phone 7 Marketplace. Note: This link will work from a Windows Phone 7, or from a PC with Zune software installed.

M	T	W	T	F	S	S
					1	2
3	4	5	6	7	8	9
10	11	12	13	14	15	16
17	18	19	20	21	22	23
24	25	26	27	28	29	30