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.

EvenTiles from Start to Finish–Part 1

Technorati Tags: Windows Phone,Mango,Silverlight,EvenTiles,Application Development,Getting Started,Visual Studio 2010

As I promised a few days ago, in between other blog entries I will show you how to create a complete Windows Phone application from scratch. This project starts with running Visual Studio to create an initial solution and it stops after having updated the application a few times and successfully submitted each different version to MarketPlace. Initially I will focus on creating the application without thinking too much about testability and reusability. I just show you the possibilities of Visual Studio, the Emulator and later on Expression Blend, Marketplace and additional tools. Later in this project we shift focus towards creating a more maintainable application, also using modern design patterns like MVVM. This series of articles is not meant to be a complete programming course for Windows Phone. If you want to know more about developing applications in C#, you should take a look at the Rob Miles’ Yellow Book. Not only an excellent resource to learn the C# programming language but also fun to read. If you want to learn more about Windows Phone application development, I can highly recommend Rob Miles’ Blue Book, and Charles Petzold’s book titled Programming Windows Phone 7. The good news is that all these books can be downloaded for free and they are all very valuable resources.

Ok, back to application development. In this first part, you will learn how to create the initial solution for your project, how to modify the default Application Tile, how to write something on the back of the Application Tile through the manifest file and how to modify the default Icon. You will also see the application in action for the first time. All steps that are necessary are not only documented, but also accompanied by a short video that can be viewed in this blog entry as well. If you already want to have a sneak preview of the application we are going to develop, it will be published on Marketplace soon. I will update this line with the link to the application once it has been certified.

To begin with, we create a new Windows Phone Silverlight Application, call it EvenTiles and modify both the ApplicationIcon.png and the Background.png files to have a transparent icon for the application and a transparent Application Tile. The cool part about adding transparency is that the area’s of the art work that are transparent show up in the theme accent color that is selected by the user of the phone. Of course we are also setting the application name and a page name on the application’s main page.

For this first version of EvenTiles we are not going to add additional functionality, although we will change the behavior of the Application Tile. Instead of showing a static Application Tile, we want it to alternate between displaying the front and the back. We can achieve this by providing back side content for the Application Tile. This can actually be done in code, but also by adding definitions for background content to the application’s manifest file. Each Windows Phone application has a manifest file with the name WMAppManifest.xml that contains information about the application, including an optional definition of content that needs to be displayed on the back side of the Application Tile. We will modify the WMAppManifest file to specify what we want to see on the back side of the Application Tile (as shown in the following code snippet):

Defining the Application Tile

<Tokens>
<PrimaryToken TokenID="EvenTilesToken" TaskName="_default">
<TemplateType5>
<BackgroundImageURI IsRelative="true" IsResource="false">Background.png</BackgroundImageURI>
<Count>0</Count>
<Title>EvenTiles</Title>
<BackBackgroundImageUri IsRelative="true" IsResource="false">Backbackground.png</BackBackgroundImageUri>
<BackTitle>EvenTiles</BackTitle>
<BackContent>Click me to start EvenTiles</BackContent>
</TemplateType5>
</PrimaryToken>
</Tokens>

In order to clearly see the content on the back side of the Application Tile, it’s image is simply an entirely transparent image, meaning it will show a solid theme color as background of the back side content.

If you deploy this application to the emulator or to a real device, you will see a rotating Application Tile after you have pinned the application to the start screen. You can watch the application being created in this video:

EvenTIles:Part 1 – Add a back side to the Application Tile

So far, the following additional EvenTiles episodes have been published:

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.

Windows Embedded Compact in the (near) future

This week, Kevin Dallas, General Manager Windows Embedded at Microsoft, confirmed there will be a next version of Windows Embedded Compact, to be released in the second half of 2012. Even though Windows 8 will have ARM support and even though the next version of Windows Embedded Standard will most likely be based upon the Windows 8 bits, having a separate, light weight and hard real-time operating system makes a lot of sense. Especially if you take a look at Kevin’s vision of intelligent systems that are built from different building blocks, amongst which of course also embedded systems with a variety of different footprints and form factors.

The announcement that there will be a Windows Embedded Compact v.next is great news for everybody who is currently working on solution based on Windows Embedded Compact. It means that you can safely continue to invest in knowledge around Windows Embedded Compact. It also means that Windows Embedded Compact will make use of Visual Studio 2010 in its next version and that Windows CE will be amongst us for at least another 15 years, probably even longer.

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.

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