Category: Windows Phone 7

EvenTiles from Start to Finish–Part 11

In the previous episode of this series about how to develop a Windows Phone application from scratch we started talking about using a PeriodicTask to perform background processing for our application. You learned how to create a Windows Phone Scheduled Task Agent, a separate project that became part of the EvenTiles solution to host a PeriodicTask. You also learned how the PeriodicTask relates to the EvenTiles to enable background processing for the application. In this episode of EvenTiles we will take a look at how to debug the PeriodicTask.

When you have added a PeriodicTask to your application you may have noticed that the behavior of Visual Studio’s debugger did change. Instead of detaching the debugger if you terminate the application, the debugger remains attached. This allows you to debug the PeriodicTask when the application is no longer executing. This is of course important because typically the PeriodicTask executes without our application being active. Under normal circumstances, a PeriodicTask will run once every 30 minutes for a few seconds. This schedule can not be changed for released applications and is determined by the operating system. Of course debugging a PeriodicTask would be unproductive in this way. Therefore there is a possibility to run your PeriodicTask more frequent under test.

If you take a look at the ScheduledActionService class, you will see that it contains a static method called LaunchForTest. This method allows you to schedule a Periodic Task to run at the time you specify. Since you will only use this method for testing Periodic Tasks, draining the battery by frequently executing code in the background is not really an issue. However, you will must not forget to remove the call to LaunchForTest in your production code. You can for instance do this by making use of conditional compilation. What I like to do is to define a separate symbol (to be used in combination with DEBUG) to control execution of LaunchForTest. Usually in Debug mode you want to test your Periodic Task frequently, but by defining a separate symbol, you can also easily disable calling LaunchForTest, even in Debug mode. The following code fragment defines the DEBUG_TASK constant:

Conditionally defined constant

#if DEBUG
#define DEBUG_TASK
#endif

Since this constant is not defined in Release mode, you don’t have to worry about accidentally adding a call to LaunchForTest in your released application. If you want to test your Periodic Agent with a normal schedule in Debug mode, you can simply change the name of the constant, for instance into NDEBUG_TASK. To make sure that the Periodic Agent will be called more frequent then usual, you can make use of the following code (inside the #if and #endif directives):

Calling Periodic Agent faster

private void StartPeriodicAgent()
{
    RemovePeriodicAgent();
 
    evenTilesPeriodicTask = new PeriodicTask(evenTilesPeriodicTaskName);
    evenTilesPeriodicTask.Description = "EvenTilesPeriodicTask";
 
    try
    {
        ScheduledActionService.Add(evenTilesPeriodicTask);
#if DEBUG_TASK
        ScheduledActionService.LaunchForTest(evenTilesPeriodicTaskName, TimeSpan.FromSeconds(30));
#endif
    }
    catch (InvalidOperationException ex)
    {
        if (ex.Message.Contains("BNS Error: The action is disabled"))
        {
            MessageBox.Show("Background agents for this application are disabled.");
        }
    }
}

As a result, the Periodic Task will now be executed approximately 30 seconds after this statement is executed. After that, the Periodic Task will execute on its normal 30 minute schedule, unless you add the call to LaunchForTest in the DoInvoke method of the Periodic Task as well:

Relaunching Periodic Agent

protected override void OnInvoke(ScheduledTask task)
{
    //TODO: Add code to perform your task in background
 
#if DEBUG_TASK
    ScheduledActionService.LaunchForTest(task.Name, TimeSpan.FromSeconds(30));
#endif
 
    NotifyComplete();
}

The following video shows you how to use the LaunchForTest method inside the EvenTiles application and how to make use of the Visual Studio debugger to test the Periodic Agent:

Debugging a Windows Phone Application’s PeriodicTask using LaunchForTest.

Of course the functionality of the Periodic Agent is still to be determined. In part 12 of EvenTiles we will work on adding functionality for the Periodic Agent.

EvenTiles from Start to Finish–Part 10

In the previous episode of this series about how to develop a Windows Phone application from scratch we talked about creating a Secondary Tile programmatically inside our application and showing different content on both the front and the back of the Secondary Tile.

This time we will introduce the concept of Background Agents for Windows Phone. A Background Agent is a piece of application code that can execute, even when the application is not running. Background Agents can be used to periodically perform some actions. Depending on the type of action and the type of scheduling, Background Agents can be of type PeriodicTask (which runs regularly for short amounts of time) or of type ResourceIntensiveTask (which runs for a longer amount of time, but not on a regular interval). Each application can have at most one PeriodicTask and one ResourceIntensiveTask. There are restrictions in using both PeriodicTask and ResourceIntensiveTask. One of the more important things to keep in mind is that a PeriodicTask will run approximately every 30 minutes for at most a couple of seconds, and it will continue running roughly twice an hour for 14 days in a row (assuming the PeriodicTask does not crash). If the application has not renewed the PeriodicTask within those 14 days, the PeriodicTask will be removed from the schedule. Thinking about it, that makes sense. If a user is not using your application for such a long time, it is probably not necessary to continue executing code for that application in the background.

For EvenTiles we will make use of a PeriodicTask, to allow updating of our Secondary Tile on a regular interval. Since updating the Secondary Tile is a relatively simple action, this is a perfect candidate for a PeriodicTask. In this way we can bring our Secondary Tile to life (after all, things will change to it on the start screen of the user’s phone), regardless of the execution state of our application. This technique can for instance be used to update weather information, or number of newly available emails to simply keep the user informed. In our sample application, we will use a PeriodicTask to simply display different strings on the back of the Secondary Tile. The reason to chose something so simple is to be able to concentrate on the bare functionality of the PeriodicTask, its relation to the application and ways to exchange data between the application and its Periodic Task.

To make use of a PeriodicTask, we need to add a new project to our solution. Visual Studio already contains a template for a Windows Phone Scheduled Task Agent, as shown in the next figure:

In the newly created PeriodicTask you will find a method called OnInvoke. That is the method into which you will add the functionality you like to have executed in the background. It is important to call the NotifyComplete method as last statement inside your OnInvoke method. Each time your code executes, it will execute in a separate thread. Since the PeriodicTask runs independent from the application (once the application has started the PeriodicTask), it can not update the User Interface of the application it belongs to.

To be able to start the PeriodicTask from inside your application, the first thing you will do is add a reference to the PeriodicTask in your application’s project:

When you have added the reference to the PeriodicTask, you have effectively made a connection between it and the application. This is visible inside the WPAppManifest.xml file:

PeriodicTask in Manifest

<Tasks>
  <DefaultTask Name="_default" NavigationPage="MainPage.xaml" />
  <ExtendedTask Name="BackgroundTask">
    <BackgroundServiceAgent Specifier="ScheduledTaskAgent" 
                            Name="EvenTilesScheduledTaskAgent" 
                            Source="EvenTilesScheduledTaskAgent" 
                            Type="EvenTilesScheduledTaskAgent.ScheduledAgent" />
  </ExtendedTask>
</Tasks>

The next thing that needs to be done is starting the PeriodicTask from inside the application. Of course it is good practice to keep the user in control, so we are going to create the PeriodicTask as a result of a user action. In episode 9 of EvenTiles we added a button to the MainPage to create a Secondary Tile. Since we want this Secondary Tile to change its backside text regularly (even without the application being active), it makes sense to create the PeriodicTask as part of the same Click event handler. The code to create and to remove the PeriodicTask looks like this:

Create and Remove PeriodicTask

private void StartPeriodicAgent()
{
    RemovePeriodicAgent();
 
    evenTilesPeriodicTask = new PeriodicTask(evenTilesPeriodicTaskName);
    evenTilesPeriodicTask.Description = "EvenTilesPeriodicTask";
 
    try
    {
        ScheduledActionService.Add(evenTilesPeriodicTask);
    }
    catch (InvalidOperationException ex)
    {
        if (ex.Message.Contains("BNS Error: The action is disabled"))
        {
            MessageBox.Show("Background agents for this application are disabled.");
        }
    }
}
 
private void RemovePeriodicAgent()
{
    var runningPeriodicTask = ScheduledActionService.Find(evenTilesPeriodicTaskName) as PeriodicTask;
    if (runningPeriodicTask != null)
    {
        ScheduledActionService.Remove(evenTilesPeriodicTaskName);
    }
}

Note how we make use of ExceptionHandling to catch an InvalidOperationException. This exception will typically be thrown if the user has disabled background processing for our application, which they can do from inside the Phone Settings. The following picture shows how the user can enable / disable background processing for our application:

Calling the methods to create / remove our PeriodicTask from inside our Click event handler is of course a simple action, although you should note that we create the PeriodicTask before creating a Secondary Tile. The reason for that is to allow the PeriodicTask to display a MessageBox to the user in case of problems. By first creating the Secondary Tile we force our application to immediately go to the background, and with that, not being able to show the MessageBox to the user.

Starting/Stopping Agent

private void btnInstall_Click(object sender, RoutedEventArgs e)
{
    if (secondaryTileInstalled)
    {
        var secondaryTile = ShellTile.ActiveTiles.FirstOrDefault(x => x.NavigationUri.ToString().Contains("TileId=Secondary"));
        if (secondaryTile != null)
        {
            RemovePeriodicAgent();
            secondaryTile.Delete();
            btnInstall.Content = txtInstallTile;
            secondaryTileInstalled = false;
        }
    }
    else
    {
        StartPeriodicAgent();
        StandardTileData NewTileData = new StandardTileData
        {
            BackgroundImage = new Uri("Background.png", UriKind.Relative),
            Title = "EvenTiles",
            Count = 0,
            BackBackgroundImage = new Uri("BackBackTile.png", UriKind.Relative),
            BackTitle = "EvenTiles",
            BackContent = App.ActualSecBackContent
        };
        ShellTile.Create(new Uri("/MainPage.xaml?TileId=Secondary", UriKind.Relative), NewTileData);
    }
}

Since we did not add functionality to our PeriodicTask, it will wake up every 30 minutes to immediately terminate again, because the only thing we are doing inside the PeriodicTask’s OnInvoke method is calling the NotifyComplete method:

An ‘Empty’ PeriodicTask

protected override void OnInvoke(ScheduledTask task)
{
    //TODO: Add code to perform your task in background
    NotifyComplete();
}

I strongly encourage you to take a look at the following video, that shows all the functionality we have so far in action:

PeriodicTask for Background Processing inside a Windows Phone Application

One thing is annoying in our solution so far. If we want to debug our PeriodicTask, we would have to wait 30 minutes each time until code in the PeriodicTask will be executed. How to overcome this problem will be topic of part 11 of our ongoing series around EvenTiles.

EvenTiles from Start to Finish–Part 9

In the previous episode of this series about how to develop a Windows Phone application from scratch we talked about restoring the entire page state after the application returns from the background. Today we finally are going to add a Secondary Tile to our application.

Each application has at least one tile, the Application Tile, which end users can pin to the start screen on their phone. In the very first episode of this series we defined the contents for the backside of the Application Tile in the manifest file of our application. Each application can also create one or more Secondary Tiles. Once a Secondary Tile is created programmatically, it will immediately be pinned to the start screen. Secondary Tiles can be removed again programmatically, but the end user can also remove Secondary Tiles from the start screen of their phone.

To add a Secondary Tile to the start screen, our application’s MainPage will host a button. When the user clicks the button, a new Secondary Tile is created. After creation, our application is moved to the background by the operating system in order to show the start screen with our newly created secondary tile, that is initialized in such a way that it contains both a front- and backside.

You can see the Secondary Tile being pinned on the start screen. You can also see that the Secondary Tile has two different sides, each with their own image and the backside containing an additional string, the string that the user can enter in the SettingsPage of the application. If the user returns to the application when the Secondary Tile is installed, they have the possibility to remove the Secondary Tile again from the start screen programmatically.

To find out if our Secondary Tile is currently visible on the start screen of the phone, we just check if it is defined in our application’s collection of tiles. This collection of ActiveTiles always contains at least the Application Tile and optionally all Secondary Tiles that were created in the application. When we are navigating to the MainPage of the application, we can find out if our Secondary Tile is available by executing the following code:

Secondary Tile Active?

protected override void OnNavigatedTo(System.Windows.Navigation.NavigationEventArgs e)
{
    base.OnNavigatedTo(e);
 
    secondaryTileInstalled = ShellTile.ActiveTiles.FirstOrDefault(x => x.NavigationUri.ToString().Contains("TileId=Secondary")) != null;
    btnInstall.Content = secondaryTileInstalled ? txtRemoveTile : txtInstallTile;
}

In this code snippet, we use a lambda expression on the static collection of ActiveTiles to find the first tile that contains the following string in its Uri: TileId=Secondary. The Application Tile does not contain this additional information, so if we find a tile with this string being part of its Uri, we can safely assume that this is our Secondary Tile. In that case, we set a boolean variable to true. Depending on the presence or absence of a Secondary Tile we also modify the Content property of the button. Of course we also need to create / delete the Secondary Tile, which is something that we will do inside the Click event handler of the button we created on the MainPage:

Creating / Deleting Sec. Tiles

private void btnInstall_Click(object sender, RoutedEventArgs e)
{
    if (secondaryTileInstalled)
    {
        var secondaryTile = ShellTile.ActiveTiles.FirstOrDefault(x => x.NavigationUri.ToString().Contains("TileId=Secondary"));
        if (secondaryTile != null)
        {
            secondaryTile.Delete();
            btnInstall.Content = txtInstallTile;
            secondaryTileInstalled = false;
        }
    }
    else
    {
        StandardTileData newTileData = new StandardTileData
        {
            BackgroundImage = new Uri("Background.png", UriKind.Relative),
            Title = "EvenTiles",
            Count = 0,
            BackBackgroundImage = new Uri("Backbackground.png", UriKind.Relative),
            BackTitle = "EvenTiles",
            BackContent = App.ActualSecBackContent
        };
        ShellTile.Create(new Uri("/MainPage.xaml?TileId=Secondary", UriKind.Relative), newTileData);
    }
}

In the above code snippet the first thing we do is verify if a Secondary Tile is installed. If so, we simply call the Delete method on it to remove it from the start screen on the phone. As visual feedback to the user, we immediately change the content property of the button to show a string to add another Secondary Tile. If we don’t have a Secondary Tile, what we are going to do is create and initialize a new instance of StandardTileData. Through its properties, this object will hold the complete characteristics of our new Secondary Tile. To create the Secondary Tile, we simply call the static Create method of the ShellTile class, passing a navigation string, indicating to which page we should go in our application when the user clicks the Secondary Tile. In this way, you can use Secondary Tiles to link to any page inside your application. You can also pass your own parameters to the navigation URI, which can help you take different actions if a page is invoked from a Secondary Tile. Together with the navigation URI, you also pass the StandardTileData to create the Secondary Tile. Immediately after calling the ShellTile.Create method, our application is moved to the background by the operating system and the start screen with our newly created Secondary Tile becomes visible. If you click on the phone’s back button, our application returns to the foreground (from either a tombstoning or dormant state). On the other hand, if the user clicks on the Secondary Tile, a new instance of our application is started and the instance of our application that was still available in the background is removed. This behavior implies that we don’t have to modify the text of the button in case of creating a live tile, because OnNavigatedTo will always execute before our MainPage becomes visible again.

The following video shows step-by-step how to create and delete Secondary Tiles programmatically. It also shows our Secondary Tile in action. Of course, this sample application is very simple, but hopefully you can see the potential, not only for having Live Tiles available for an application, but also to make use of Secondary Tiles to allow the user to immediately navigate to a particular page of your application.

Creating and Deleting Secondary Tiles Programmatically

If you want to take a look at the source code that we have available for EvenTiles so far, you can download the entire solution belonging to this episode:

Download EvenTiles Episode 9 Source Code

After downloading and unzipping the sample code, you can open the EvenTiles solution in Visual Studio 2010 Express for Windows Phone. You must have the Windows Phone SDK 7.1 installed on your development system to do so. If you have a developer unlocked phone you can deploy the application to your phone, if you don’t have a developer unlocked phone you can still experiment with this application inside the emulator.

In the next episode of EvenTiles we will introduce a more advanced topic when we are beginning to talk about making use of a background agent to allow our application to execute some code, even when it is not in the foreground.

EvenTiles from Start to Finish–Part 7

In the previous episode of this series about how to develop a Windows Phone application from scratch we used the Isolated Storage Explorer Tool to take a look at the contents of the ApplicationSettings, stored in IsolatedStorage on the device or emulator. This time we continue dealing with our application settings, because we are going to talk about Fast Application Switching and Tombstoning.

As you probably know, only one application can be running in the foreground on a Windows Phone. That application can use as much resources as it needs and should be as responsive as possible to give end users a great experience. Typically, users switch often between applications. They might not even think about different applications, because they are most likely very task oriented. To give end users the best experience, our applications share a responsibility with other applications and with the operating system.

If our application is currently running in the foreground, there are two important reasons for our application to stop running in the foreground:

The user terminates our application by pressing the Back Key on the phone until the entire back stack of pages for our application is empty.
Our application is interrupted because some sort of an event occurred.

The first situation is simple. When our application is terminating, it is our responsibility to store information that we want to persist until the next time our application is running. This is what we did for EvenTiles in part 5 of the series, using the Application_Launching and Application_Closing methods that are defined in the App.xaml.cs file.

NOTE: The description of Fast Application Switching and Tombstoning in this article is valid for Windows Phone Mango, not for previous versions of the operating system.

The following picture shows our application running over time. The user navigated to the SettingsPage on EvenTiles, modified the string value and decided to use the Start Key on the phone to start another application. After a while, the user returns to our application by pressing the Back Key until our SettingsPage is visible again.

For the user, this experience is great, because when they come back to our application, it shows up exactly as it was when they moved our application to the background. The operating system simply keeps our application in memory. There are some restrictions with regards to applications using certain resources like the camera. To keep our story lean and mean we will omit those. When the user starts many applications (thus putting more and more applications in the background), at some time the amount of available memory gets so low that another application can no longer be started. In this situation, the operating system decides to remove the oldest application in the background from memory, saving just minimal state information for that application. In this situation, the application that was just removed from memory is said to be Tombstoned. To restore our application from being tombstoned, we not only need to reload our application settings (as we did on the Application_Launching event), but most likely we also need to restore additional data. The Operating System ‘remembers’ the page in our application the user had visible when we were tombstoned. It is our responsibility to restore data that the user entered on that page (for instance the contents of a Textbox).

When our application is send to the background, several things happen. On the page that is currently visible, an OnNavigatedFrom event will occur. Also, the Application_Deactivated method in the App.xaml.cs file will be called. When an application is switched to the background, basically three things can happen to it:

The application will become the foreground application again without having entered the tombstone state. In this situation the application can benefit from Fast Application Switching.
The application got tombstoned, but it will become the foreground application after a while. In this situation the application must restore more state information.
The user starts the application again by clicking its icon or tile on the start screen. In this situation, the previous instance of the application is removed and the user should see the application in its initial state.

When you are debugging your application in Visual Studio, the default behavior when the application is moved to the background is for it to remain in memory. However, by modifying one of the project properties (as shown in the screen dump on the left), you can force the application to become tombstoned, regardless from the amount of free memory on the device (emulator). In this way, we as developers have the possibility to test our applications in either state they enter when being moved to the background. You should make sure that you test the tombstone scenario for your application. For instance, if EvenTiles with its current functionality is tested for tombstoning it will crash. This currently has to do with the way that data is initialized. In EvenTiles, we have a string property defined in App.xaml.cs that will later be used to write information to the back side of our Secondary Tile. The SettingsPage already makes use of this property. However, we are initializing this property, named ActualBackSecContent when the application is started in the Application_Launching method.

Activating and Terminating

// Code to execute when the application is launching (eg, from Start)
// This code will not execute when the application is reactivated
private void Application_Launching(object sender, LaunchingEventArgs e)
{
    if (!appSettings.Contains(keyActSecBackContent))
    {
        appSettings[keyActSecBackContent] = DefaultSecBackContent;
    }
    ActualSecBackContent = (string)appSettings[keyActSecBackContent];
}
 
// Code to execute when the application is activated (brought to foreground)
// This code will not execute when the application is first launched
private void Application_Activated(object sender, ActivatedEventArgs e)
{
}
 
// Code to execute when the application is deactivated (sent to background)
// This code will not execute when the application is closing
private void Application_Deactivated(object sender, DeactivatedEventArgs e)
{
}
 
// Code to execute when the application is closing (eg, user hit Back)
// This code will not execute when the application is deactivated
private void Application_Closing(object sender, ClosingEventArgs e)
{
    appSettings[keyActSecBackContent] = ActualSecBackContent;
}

Even though our application is removed from memory when it is tombstoned, if the user navigates through the back stack using the back key on the phone, eventually they will return back to a page of our application. In order to make this happen in case our application was tombstoned, it has to be reloaded again to memory to become active. In this situation, minimal state information was stored by the operating system (for instance which page was the last page the user saw when our application got tombstoned). On returning from tombstoning we will return to that page, but since the application needs to be started completely, classes have to be newly created and code in constructors of those classes will therefor be executed. To distinguish between starting a fresh copy of the application or returning from the background, Application_Launching (fresh restart) or Application_Activated (tombstoning or fast application switching) is called in our App.xaml.cs file. If our application was still in memory, there is no problem, after all, the property ActualSecBackContent still holds its value. If we are returning from a tombstoning situation we do have a problem, since Application_Activated will be called instead of Application_Launching. That is why the exception that is shown in the screen dump above was thrown.

You might think that this problem could easily be solved by initializing the ActualSecBackContent property in the constructor of our App class, but that would mean that we don’t benefit from fast application switching (the situation where our application remains in memory, even though it is in the background). A better solution is to make use of the Application_Activated event as follows:

Switching between BG and FG

// Code to execute when the application is activated (brought to foreground)
// This code will not execute when the application is first launched
private void Application_Activated(object sender, ActivatedEventArgs e)
{
    if (!e.IsApplicationInstancePreserved)
    {
        // The application was not preserved in memory, so we were tombstoned
        // Only in this case we need to re-initialize ActualSecBackContent
        ActualSecBackContent = (string)appSettings[keyActSecBackContent];
    }
}
 
// Code to execute when the application is deactivated (sent to background)
// This code will not execute when the application is closing
private void Application_Deactivated(object sender, DeactivatedEventArgs e)
{
    appSettings[keyActSecBackContent] = ActualSecBackContent;
}

If the application is becoming the foreground application, we check if we were still available in memory. If so (e.IsApplicationInstancePreserved == true) we don’t do anything, otherwise we just initialize the ActualSecBackContent property. There is nothing else to do, because we know that a value with that particular Settings key already is available, since the application was launched at some time before Application_Activated was called. If an application is moved to the background you want to make sure to save everything in such a way that you assume that your application will never return to the background. After all, the application can stay in memory, it might be tombstoned but there is also a possibility that the user starts a brand new instance of the application from the start menu. In the latter case, the existing instance of the application in the background will be removed by the operating system.

NOTE: If you are upgrading an existing application for Mango, at the very least (after converting your project in Visual Studio) you need to only retrieve stored data in the Application_Activated method when e.IsApplicationInstancePreserved is false. In that way your application will immediately benefit from fast application switching.

The following video shows the actions we took to prevent the EvenTiles application from crashing after being reactivated from a tombstoned state:

Fast Application Switching and Tombstoning (1)

With the changes that were described so far added to our application, it no longer crashes if we are returning from a tombstone state. There are however more things that need to be considered when the application is brought back from background to foreground. In the next Episode of EvenTiles we will take a look at restoring Focus on an input control when returning from the background.

If you want to see EvenTiles already in action on your Windows Phone, you can install the latest release from Marketplace. Remember that this application is not meant to be extremely useful, although it contains similar functionality that “serious” applications have. All functionality that you can find in the released version of EvenTiles will be covered in the upcoming episodes of this blog series, together with all source code. Just go ahead and get your free copy of EvenTiles from Marketplace at this location: http://www.windowsphone.com/en-US/search?q=EvenTiles (or search on your phone for EvenTiles in the Marketplace application).

EvenTiles from Start to Finish–Part 6

In the previous episode of this series about how to develop a Windows Phone application from scratch we used IsolatedStorage to persist some data. Since IsolatedStorage is a file store on a Windows Phone device, for exclusive use by a single application, it can be a challenge to look at its contents. Luckily, the Windows Phone 7.1 SDK has a tool available to explore IsolatedStorage contents. In this episode of EvenTiles we will explore this Isolated Storage Explorer Tool.

The Isolated Storage Explorer Tool is a command line tool, which is installed together with the Windows Phone 7.1 SDK in the following folder:

C:\Program Files (x86)\Microsoft SDKs\Windows Phone\v7.1\Tools (64 bit OS)
or
C:\Program Files\Microsoft SDKs\Windows Phone\v7.1\Tools (32 bit OS)

The tool itself has a lot of parameters, to get contents from IsolatedStorage, to write contents to IsolatedStorage, to specify an application and to specify a device. In a command prompt some limited help information is available:

In order to retrieve our ApplicationSettings from IsolatedStorage for EvenTiles, the first thing we need to know is the ProductID for our application. This ide can be found in the WMAppManifest.xml file.

WMAppManifest.xml

<Deployment xmlns="http://schemas.microsoft.com/windowsphone/2009/deployment" AppPlatformVersion="7.1">
  <App xmlns="" ProductID="{883385e6-52e5-4835-83db-8a17499b5767}" Title="EvenTiles" 

The next thing we need to do is make sure that the Emulator is started (or a physical device is connected). Either should have the application installed, but it is not necessary to have the application running. After passing the following command,

the folder C:\iso will contain a snapshot of our application’s IsolatedStorage.

When we drag and drop the _ApplicationSettings file to Visual Studio 2010, you can see that its contents are XML data, representing a Dictionary with one single entry defined in it, matching our Secondary Tile’s back side string.

You might not like using a command line tool to explorer IsolatedStorage. In that case, there is good news for you. If you browse to http://wptools.codeplex.com/, you will find the Windows Phone Power Tools for download. This handy collection of tools embeds the different SDK tools including the Isolated Storage Explorer Tool inside a Windows application. With that application you can explore your application’s IsolatedStorage as well. Using the power tool, it is also easy to write new or modified files to your application’s IsolatedStorage. The latter makes a lot of sense if you want to test new versions of applications against old contents in IsolatedStorage, for instance to migrate old files to new versions.

The following video shows the Isolated Storage Explorer Tool and the Windows Phone Power Tools in action.

Using the Isolated Storage Explorer Tool and the Windows Phone Power Tools

So this time we did not add functionality to our EvenTiles application, but it is important to learn about useful tools to help us develop our applications as well. In the next episode we will talk about Tombstoning and Fast Application switching and what we need to do in our application to support these two important execution states on Windows Phone devices.

EvenTiles from Start to Finish–Part 5

In episode number four of this series about how to develop a Windows Phone application from scratch we created the SettingsPage using a combination of Expression Blend and Visual Studio 2010. The SettingsPage has limited functionality, but it can modify a string that will eventually be displayed on the backside of a Secondary Tile. In this episode we will take a look at how to store data in IsolatedStorage.

If you watched the video of episode 4 you have noticed that the string containing the text to be eventually displayed on the Secondary Tile’s backside was not saved when the application was closed, because a default string showed up when the application was started again. In order to store the string so it will be available when the application starts again, we are going to store it into a specific part of the our IsolatedStorage. IsolatedStorage can be used to store files and system settings. It just acts as a hard drive with one little but important difference. IsolatedStorage is …. isolated. Everything that is stored in IsolatedStorage is exclusively available for the application that owns it, so other applications can not access it.

When a Windows Phone application starts, it will be running in the foreground, with its MainPage visible. As long as the user is working with the application, it remains n the foreground. An application can be terminated by the user by pressing the Back key on the phone until the last page of the application will be closed. An application can also be moved to the background. This happens when the user activates another application, or for instance when the user answers a phone call. On starting, a Launching event is raised. The App.xaml.cs file already has event handlers defined for the Launching and Closing events. These are the events that we are going to use to store / retrieve our string containing the backside text for our Secondary Tile.

NOTE: The sample code, retrieving and storing data in the Launching / Closing event works fine. However, all code executing upon firing those events has a time limit of 10 seconds. If an event handler takes longer to execute, the application will be immediately terminated. If you have much data to store / retrieve, you should take an alternative approach. You can for instance make use of a separate thread in those situations to retrieve / store information. To keep our sample lean and mean, we will directly retrieve / store data into IsolatedStorage from within the Launching / Closing event handlers.

Since all functionality is already available inside the SettingsPage to store the backside text of the Secondary Tile, we are only adding some functionality to the App.xaml.cs file. First thing to do is get access to the IsolatedStorageSettings for our application, which is in fact a dictionary in which values can be stored / retrieved through a key. The IsolatedStorageSettings are implemented as a singleton and are created the first time we try to access them. IsoloatedStorageSettings can be accessed from inside our entire application, although right now we will only use IsolatedStorageSettings inside the App.xaml.cs file.

IsolatedStorageSettings

public const string DefaultSecBackContent = "Having an even # of tiles on my StartScreen";
public const string keyActSecBackContent = "K_ASBC";
 
public static string ActualSecBackContent { get; set; }
 
private IsolatedStorageSettings appSettings = IsolatedStorageSettings.ApplicationSettings;

In the code snippet you can see a declaration of a key (just a string variable) that is used to store / retrieve the string containing content for the back side of a Secondary Tile. You can also see how a private variable is declared that is initialized with the one and only instance of our application’s settings in IsolatedStorage.

Application_Launching

// Code to execute when the application is launching (eg, from Start)
// This code will not execute when the application is reactivated
private void Application_Launching(object sender, LaunchingEventArgs e)
{
    if (!appSettings.Contains(keyActSecBackContent))
    {
        appSettings[keyActSecBackContent] = DefaultSecBackContent;
    }
    ActualSecBackContent = (string)appSettings[keyActSecBackContent];
}

Each time the application is started, the Application_Launching method will be executed. In this method we check if an object is stored under the key keyActSecBackContent. If this is not the case, we create a new entry in the dictionary of application settings and assign it with a default text that can be written to the back side of the Secondary Tile. If an entry already exists (which is basically always after creating one during the very first time), we retrieve the actual string from that entry. Since an application settings dictionary stores objects, we need to cast the actual value to a string.

When the application is terminated, the contents of the string that contains the text for the back side of the Secondary Tile might have been changed in the SettingsPage. That is the reason why we store that string always when the application ends.

Application_Closing

// Code to execute when the application is closing (eg, user hit Back)
// This code will not execute when the application is deactivated
private void Application_Closing(object sender, ClosingEventArgs e)
{
    appSettings[keyActSecBackContent] = ActualSecBackContent;
}

It looks like we now have stored our application settings properly. However, that is not entirely the case, since our application might be temporarily interrupted because the user can start other applications without terminating our application. In those situations we have to take a look at the life cycle of an application. That will be topic of another episode of EvenTiles. It is also interesting to take a look at exactly what information is stored in IsolatedStorage. In order to do that, you can make use of the Isolated Storage Explorer Tool, a handy little tool that will be covered in episode six of EvenTiles.

In the following video you can see all the steps that you need to make application settings persistent and to retrieve them each time the application starts again.

Using IsolatedStorage to store ApplicationSettings

Note: Every now and then I will make sure that you can download all source code that we created so far. I strongly recommend you to do so and to start experimenting with that code. After all, looking at real code, modifying it and understanding your modifications will hopefully help you to become a great Windows Phone developer fast.

If you want to keep up with the code of EvenTiles that is available until now, you can download it as a Zip file from this location. After downloading and unzipping it, you can open the EvenTiles solution in Visual Studio 2010 Express for Windows Phone. You must have the Windows Phone SDK 7.1 installed on your development system to do so. If you have a developer unlocked phone you can deploy the application to your phone, if you don’t have a developer unlocked phone you can still experiment with this application inside the emulator.

EvenTiles from Start to Finish–Part 4

In the third part of this series about how to develop a Windows Phone application from scratch we looked at the Silverlight Toolkit for Windows Phone and page transitions. Today we will work on some functionality in the Settings Page of our application. We will take off where we finished in Part 3, and start with an empty SettingsPage (except for the application name and page title).

The purpose of our complete sample application is to create a Secondary Tile programmatically and pin that to the Start Screen of the user. The Secondary Tile has a front and a back. The text on the backside of the tile can be modified by the end user. EvenTiles is not meant to be extremely useful, it is there to help introduce lots of programming aspects to develop Windows Phone applications.

In this episode we will add a few UI Elements to the SettingsPage to realize the follow functionality:

The text that will be displayed on the backside of the Secondary Tile is visible;
The backside text can be modified;
If the backside text differs from a default text, a button is displayed to allow easy restoration of the default backside text, otherwise the button is invisible.

The SettingsPage gets the following layout:

The layout of the UI is relatively simple. In the ContentPanel of the PhoneApplicationPage we have a StackPanel containing 3 different items (a TextBlock, a TextBox plus a hidden Button) and a ToggleSwitch (that is defined in the Silverlight Toolkit for Windows Phone). The ToggleSwitch is already visible but does currently not have any functionality associated to it. The ContentPanel itself is a Grid. Initially, a Grid has one row and one column. To place UI Elements in the Grid and to position them at a particular location you typically make use of multiple rows and/or multiple columns that you first have to define. To get the desired layout, the Grid contains 3 separate rows. In the first row (being row number 0), the StackPanel is hosted. This row takes the height it needs to display all visible UI Elements of the StackPanel. The next row on the Grid takes up whatever space is left on the grid and the last row takes precisely the height it needs to display the ToggleSwitch. The XAML for the ContentPanel looks like this:

SettingsPage UI

<!–ContentPanel – place additional content here–>
<Grid x:Name="ContentPanel"
        Grid.Row="1"
        Margin="12,0,12,0">
    <Grid.RowDefinitions>
        <RowDefinition Height="Auto" />
        <RowDefinition />
        <RowDefinition Height="Auto" />
    </Grid.RowDefinitions>
    <StackPanel>
        <TextBlock HorizontalAlignment="Left"
                    TextWrapping="Wrap"
                    Text="Set your own tile text (approx. 45 characters)"
                    VerticalAlignment="Top"
                    Margin="12,0" />
        <TextBox x:Name="tbBackContent"
                    TextWrapping="Wrap"
                    MaxLength="45"
                    d:LayoutOverrides="Height"
                    TextChanged="tbBackContent_TextChanged" />
        <Button x:Name="btnRestore"
                Content="Restore Default Text"
                Margin="0,0,0,3"
                d:LayoutOverrides="Height"
                Click="btnRestore_Click"
                Visibility="Collapsed" />
    </StackPanel>
    <toolkit:ToggleSwitch Header=""
                            Grid.Row="2"
                            Content="Allow using Location?" />
</Grid>

You can see our Grid.RowDefinitions being defined. There is also a possibility to define Grid.ColumnDefinitions, but for this particular simple UI we only need rows. Scrolling through the XAML you can see all individual UI Elements being defined. The TextBox and the Button connect events to event handlers. For the Button, the Click event is connected to a method called btnRestore_Click. Each time the user Clicks the Button, the code that is defined in btnRestore_Click will execute. That code is defined in C#. We will take a look at the code later. The TextBox uses the TextChanged event, that will be fired each time the value of the Text property of the TextBox changes. If this happens, code inside the method tbBackContent_TextChanged will execute.

In Part 2 of EvenTiles we looked at the NavigationService that can be used to navigate from one PhoneApplicationPage to another PhoneApplicationPage. Each time the user navigates to a particular page, the OnNavigatedTo method on that page is called. You can override that method to extend its functionality. When the user navigates away from a PhoneApplication, a similar method (OnNavigatedFrom) is called that you again can override to add specific functionality you need on a particular page. In the SettingsPage of EvenTiles we are overriding both these methods to add some functionality:

OnNavigated …

protected override void OnNavigatedTo(System.Windows.Navigation.NavigationEventArgs e)
{
    base.OnNavigatedTo(e);
    tbBackContent.Text = App.ActualSecBackContent;
    btnRestore.Visibility = tbBackContent.Text.Equals(App.DefaultSecBackContent) ? Visibility.Collapsed : Visibility.Visible;
}
 
protected override void OnNavigatedFrom(System.Windows.Navigation.NavigationEventArgs e)
{
    base.OnNavigatedFrom(e);
    App.ActualSecBackContent = tbBackContent.Text;
}

Both these methods contain a call to a similar method, preceded by the keyword base. These methods execute functionality that is defined in the base class of our derived PhoneApplicationPage class. To make sure that we don’t skip that code (which might contain important functionality for page navigation) we have to call those methods. Immediately under the call to the base class methods, our own functionality is added. When we are navigating to the SettingsPage, we initialize the TextBox with the currently stored backside content for a Secondary Tile that we will create later in this series. This content is defined in a string property in the App.xaml.cs file. Next we determine if the Button that can be used to restore a default text needs to be visible. This is only the case when the TextBox displays something different from a default text that is also defined in App.xaml.cs. In App.xaml.cs the default text is assigned to the actual text.

When the user is leaving the SettingsPage (for instance by pressing the Back button on the phone), we simply store the current content of the TextBox for later use.

Let’s now take a look at the event handlers for both the Button and the TextBox:

Event Handlers

private void tbBackContent_TextChanged(object sender, System.Windows.Controls.TextChangedEventArgs e)
{
    btnRestore.Visibility = tbBackContent.Text.Equals(App.DefaultSecBackContent) ? Visibility.Collapsed : Visibility.Visible;
}
 
private void btnRestore_Click(object sender, System.Windows.RoutedEventArgs e)
{
    tbBackContent.Text = App.DefaultSecBackContent;
}

If the text in the TextBox changes, the TextChanged event handler code will execute. Just like in the OnNavigatedTo method, we determine if the Button that can be used to restore a default text needs to be visible. If the Button is clicked, we simply restore the default text. Since this also fires a TextChanged event (after all, the text of the TextBox is changed), executing code in the TextChanged event handler will now result in the Button to be hidden.

In the following video you can see all the steps that are needed to add the described functionality to the SettingsPage.

Extending the SettingsPage for EvenTiles

We are still far away from having all functionality in place to actually make a Secondary Tile visible on the Start Screen. However, we need to understand a few fundamental concepts in order to create successful Windows Phone applications, so we will continue with the ground work for another couple of episodes. In the next episode we will look at persisting data in IsolatedStorage to make sure that we store data when the user stops using our application.

EvenTiles from Start to Finish–Part 3

In the second part of this series about how to develop a Windows Phone application from scratch we looked at the ApplicationBar and Page Navigation. Today we will introduce the Silverlight Toolkit for Windows Phone, show how to use it inside an application and add page transitions to the application. We will take off where we finished in Part 2.

The Silverlight Toolkit for Windows Phone is a separate assembly that you can install after downloading it. It installs in the same location where the Windows Phone SDK’s are installed, making it very easy to add a reference to it in order to use functionality that can be found in the toolkit.

After you have installed the toolkit, you can add a reference to it inside your application by right-clicking the references field your project and selecting the toolkit in the dialog box that appears. After adding the toolkit to the references, you will see it under references inside solution explorer. The first thing we are going to do is adding page transitions. If you look at the video, you will see that the pages of our application are currently simply appearing without any animations. However, page transitions inside many applications are similar to turning pages in a book. This is for instance the case with applications that are already installed on your Windows Phone. The Silverlight Toolkit contains functionality to make it very easy to incorporate similar page transitions inside your own applications. There are many different transitions to choose from, but we will use the same page turning transitions that you probably already know when you activate an application from the start screen.

To add page transitions inside your own application, it is important to change the PhoneApplicationFrame for your application into a TransitionFrame. The latter is defined in the Silverlight toolkit and allows for page transitions. The RootFrame is a container to hold all pages that you will create inside your application. You will have to search for the method InitializePhoneApplication inside the source file App.xaml.cs that Visual Studio created for you when you created the EvenTiles project. Inside this method, you can see that a new RootFrame is created of type PhoneApplicationFrame. You will have to change this into a TransitionFrame in order to get your page transitions working.

Using a TransitionFrame

// Do not add any additional code to this method
private void InitializePhoneApplication()
{
    if (phoneApplicationInitialized)
        return;
 
    // Create the frame but don't set it as RootVisual yet; this allows the splash
    // screen to remain active until the application is ready to render.
    // RootFrame = new PhoneApplicationFrame();
    RootFrame = new TransitionFrame();
    RootFrame.Navigated += CompleteInitializePhoneApplication;
 
    // Handle navigation failures
    RootFrame.NavigationFailed += RootFrame_NavigationFailed;
 
    // Ensure we don't initialize again
    phoneApplicationInitialized = true;
}

In order to get page transitions working, the next thing you have to do is add some XAML that defines the different page transitions to each page on which you want to make use of page transitions. Instead of adding individual pieces of XAML for each page, you can also create a new style that you use inside all pages that you want to make use of page transitions. That is the approach we are taking in this sample. First thing to do is add the following XAML to the App.xaml file:

PageTransition Style

<!–Application Resources–>
<Application.Resources>
    <Style x:Key="DefaultPageWithTransitions"
            TargetType="phone:PhoneApplicationPage">
        <Setter Property="sltk:TransitionService.NavigationInTransition">
            <Setter.Value>
                <sltk:NavigationInTransition>
                    <sltk:NavigationInTransition.Backward>
                        <sltk:TurnstileTransition Mode="BackwardIn" />
                    </sltk:NavigationInTransition.Backward>
                    <sltk:NavigationInTransition.Forward>
                        <sltk:TurnstileTransition Mode="ForwardIn" />
                    </sltk:NavigationInTransition.Forward>
                </sltk:NavigationInTransition>
            </Setter.Value>
        </Setter>
        <Setter Property="sltk:TransitionService.NavigationOutTransition">
            <Setter.Value>
                <sltk:NavigationOutTransition>
                    <sltk:NavigationOutTransition.Backward>
                        <sltk:TurnstileTransition Mode="BackwardOut" />
                    </sltk:NavigationOutTransition.Backward>
                    <sltk:NavigationOutTransition.Forward>
                        <sltk:TurnstileTransition Mode="ForwardOut" />
                    </sltk:NavigationOutTransition.Forward>
                </sltk:NavigationOutTransition>
            </Setter.Value>
        </Setter>
    </Style>
</Application.Resources>

Here we define different transitions that will run when you are navigating to and from pages inside the application. The transitions that you can see in the code snippet are all TurnStileTransitions which are commonly used for page transitions inside a Windows Phone application. The Silverlight Toolkit contains other transition types as well.

After having defined the transitions and after having changed the RootFrame to be able to host transitions, the only thing that is left to do is assigning newly created transition style to each individual page. This can for instance be done using Expression Blend. When you now would run the application, it will blend in perfectly with applications that came with your Windows Phone. Navigating from page to page inside our application is now identical to navigating inside for instance the different settings on the Windows Phone. Of course it is not necessary to make use of page transitions, but it does make your application look better and even more professional.

The Silverlight Toolkit for Windows Phone contains much more useful items, like a number of cool user interface elements. To see already one of them in action, we are adding it to the Settings Page. On the SettingsPage we later need a switch that can enable / disable reading of location data. Right now we are just going to enter a dummy switch and we are choosing a nice control from the Silverlight Toolkit, the ToggleSwitch. This control looks like a light switch and has (like a CheckBox) two different states, checked and unchecked. This control looks extremely good inside a Windows Phone application, as you can see in the following screenshot:

Inside Visual Studio 2010 Express Edition you can see the SettingsPage in designer mode. In it, you can also see a ToggleSwitch (in checked mode). The ToggleSwitch is added to the content grid, filling up as much space as it needs in the last row of the grid. How to layout UI controls inside a grid and in other container controls is something we will cover later in this series about Windows Phone Application Development.

In the following video you can see all the steps that are needed to add transitions to your Windows Phone Application and how to be able to use functionality from the Silverlight Toolkit inside your own application.

Using the Silverlight Toolkit to add Page Transitions to EvenTiles

LiveTiles will be extended soon. In the next episode we will create the SettingsPage UI and make sure that we can store data entered on the SettingsPage. Make sure to lookout for part four in this series about Windows Phone application development which will be published soon.

EvenTiles from Start to Finish–Part 2

In the first part of this series about how to develop a Windows Phone application from scratch we looked at the initial project and how to initialize the Application Tile by setting elements in the manifest file. Today we will add an ApplicationBar to our application and we will add page navigation as well. We simply take off where we finished in Part 1. Adding an application bar is actually easier from within Expression Blend. This tool can be used to design and prototype Windows Phone applications. The advantages of using Expression Blend to add the application bar are:

immediate visual feedback;
simple selection / insertion of application bar icons
simple reordering possibilities for application bar icons en menu items.

Visual Studio can work closely together with Expression Blend. Changes in one environment will be visible in the other environment (usually changed files must only be saved or a project must be rebuilt in order to achieve this). If a solution is already open in Visual Studio, you can start Expression Blend from within the Project Menu as shown. Even though you can use Expression Blend to add code to your Windows Phone pages, you probably want to limit doing so, since you don’t have Intellisense available, which is one of the great features of Visual Studio that really makes entering code easy. You can immediately see that you are in a different environment when looking at Expression Blend. Its default theme color is dark. Something else that is immediately noticeable is the large amount of windows, options and choices available inside Expression Blend. It surely will take you some time to feel comfortable in this powerful design tool.

What you can see here is Expression Blend showing the MainPage of our EvenTiles application. You can also see how to select an ApplicationBarIcon in the collection of ApplicationBarIcon buttons. Besides concentrating on creating a (static) UI for a Windows Phone application, Expression Blend is also a fantastic tool to create different visual states and animations. We are still in the early stages of application development in this series, but more in depth usage of Expression Blend will definitely follow later on. For now we will just add a little bit of functionality to our application. Using Expression Blend, two new pages have been added to the project, a Settings Page and an About Page. Both these pages only contain a filled title section. Right now, the only functionality that will be added to the application is code to navigate to each of the two empty pages when the corresponding ApplicationBar buttons are clicked. The following code snippet shows the ApplicationBar that was created with Expression Blend in XAML, and already includes Click event handlers:

ApplicationBar on MainPage

<phone:PhoneApplicationPage.ApplicationBar>
    <shell:ApplicationBar Opacity="0">
        <shell:ApplicationBarIconButton IconUri="/icons/appbar.feature.settings.rest.png"
                                        IsEnabled="True"
                                        Text="settings"
                                        Click="Settings_Click" />
        <shell:ApplicationBarIconButton IconUri="/icons/appbar.questionmark.rest.png"
                                        IsEnabled="True"
                                        Text="about"
                                        Click="About_Click" />
    </shell:ApplicationBar>
</phone:PhoneApplicationPage.ApplicationBar>

To add code to the Click event handers, we are using the C# code behind file, belonging to the MainPage.

To create entries in the code behind file for both Click event handlers (and in that way connecting XAML to code), you can right click on the event handler in XAML and selecting Navigate to Event Handler entry from the shown popup menu. The code in the event handlers is very simple, using the NavigationService to navigate to another page by providing a Uri that contains the page name.

Navigating to other pages

private void Settings_Click(object sender, EventArgs e)
{
    NavigationService.Navigate(new Uri("/SettingsPage.xaml", UriKind.Relative));
}
 
private void About_Click(object sender, EventArgs e)
{
    NavigationService.Navigate(new Uri("/AboutPage.xaml", UriKind.Relative));
}

After deploying the application to the emulator, the Main Page shows an ApplicationBar. Clicking on either of the two ApplicationBar buttons results in navigating to another page inside the application. The following video shows all steps to create the ApplicationBar, the additional pages and the code to navigate from page to page:

Adding an ApplicationBar and showing page navigation

LiveTiles will be extended soon. In the next episode we will take a look at the Silverlight toolkit, Page Transitions and additional controls that are available in the Silverlight toolkit. Make sure to lookout for part three in this series about Windows Phone application development.

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.

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