Author: Maarten Struys

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

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

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

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

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

image

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

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

  1. <Tokens>
  2.   <PrimaryToken TokenID="ClickerToken" TaskName="_default">
  3.     <TemplateType5>
  4.       <BackgroundImageURI IsRelative="true" IsResource="false">Background.png</BackgroundImageURI>
  5.       <Count>0</Count>
  6.       <Title>Clicker</Title>
  7.       <BackBackgroundImageUri IsRelative="true" IsResource="false">Images/BackBackground.png</BackBackgroundImageUri>
  8.       <BackTitle>Clicker</BackTitle>
  9.       <BackContent>Play and beat your own high score!</BackContent>
  10.     </TemplateType5>
  11.   </PrimaryToken>
  12. </Tokens>

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

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

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

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

Neutral Language String Table in AppResLib.dll

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

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

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

  1. <Tokens>
  2.   <PrimaryToken TokenID="ClickerToken" TaskName="_default">
  3.     <TemplateType5>
  4.       <BackgroundImageURI IsRelative="true" IsResource="false">Background.png</BackgroundImageURI>
  5.       <Count>0</Count>
  6.       <Title>@AppResLib.dll,-200</Title>
  7.       <BackBackgroundImageUri IsRelative="true" IsResource="false">Images/BackBackground.png</BackBackgroundImageUri>
  8.       <BackTitle>@AppResLib.dll,-300</BackTitle>
  9.       <BackContent>@AppResLib.dll,-400</BackContent>
  10.     </TemplateType5>
  11.   </PrimaryToken>
  12. </Tokens>

And here is the result:

image

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

Other parts in this series:

  1. Setting the stage and Initializing the Application Tile
  2. Updating an Application Tile from inside your application
  3. Using a Background Agent to periodically updating Tiles
  4. Creating and using Secondary Tiles
  5. Setting the stage for EvenTiles

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

Device Development Rocks!

At a first glance, developing software for mobile and embedded devices does not seem to differ much from developing software for the desktop. If I limit myself to developing applications for Windows CE based devices, you can use the same development tools as desktop developers. However, there are a number of interesting differences. For starters, Windows CE is a much smaller operating system, meaning for instance that we only have a subset of the Win32 API’s available. The same is true for developers who like to write managed code; the .NET Compact Framework is a subset of the full .NET Framework. Another important difference is the amount of memory available on the device. Quite often you find yourself dealing with low memory situations. If you are allocating memory, you might not get the memory you asked for. Are you dealing properly with this situation? Also, devices typically have slower processors than desktop machines. Therefore it is very important to write efficient code or you will run into performance issues. And then there is the whole category of battery powered devices. Each statement that is executed inside your application will drain the battery a little. So again, writing efficient code is very important. Let’s even move up the bar a bit. Desktop machines are typically frequently restarted. Embedded devices often will stay on, always, 24 hours a day and 365 days a year. This means the code you write should not only be efficient, but it should be correct as well. Especially if you take a look at allocating and freeing up memory, you might get into trouble. If you are leaking memory, even only a couple of bytes / hour, you might end eating up all available memory. Another area where you need specific skills is for creating systems that need hard real-time functionality. Windows CE is a hard real-time operating system, meaning response times can be guaranteed. But you have to know a lot about how to synchronize threads, potential deadlocks, priority inversion and many other things. And of course, still keep efficient and correct programming in mind. If you are thrilled by all these things and you are still writing desktop applications, perhaps it is time for you to look into embedded development.

Windows Embedded Handheld Revitalized

This is very exciting to see. It really seems that Windows Embedded Handheld devices will be important in the upcoming future. As a matter of facts, so important that a brand new blog by Dion Hutchings is not published on MSDN. Different from Windows Phone, Windows Embedded Handheld devices

  • can have different form factors
  • have access to Win32 API’s
  • can run native and managed applications
  • can have additional hardware resources.

For a while it seemed that Microsoft quietly would let go of Windows Mobile (or Windows Embedded Handheld, as I should call it these days). However, with this brand new blog, but also with some encouraging words from Kevin Dallas, it seems that Windows Embedded Handheld is alive and kicking.

Focus on Performance

Sometimes, reality differs a little bit from ideas. I had planned to continue writing about comparing developing for Android and for Windows Phone. It will happen but just a little later. I also planned to blog a lot about Mango, especially since Windows Phone is now officially released in The Netherlands as well. Reality is that I have blogged, but on another blog and in another language. My company has introduced a new blog on which I have been writing over the last 2 months or so. It contains posts with technical information around Microsoft technologies that are relevant for my day-to-day work. Topics vary between Windows Embedded OS Design / application development, Windows 8 Metro Style application development and Windows Phone application development. If you are curious and if you understand the Dutch language, you can take a look at the Alten PTS TechCorner.

For the upcoming two months I again have some plans, but this time they will become reality. There are a few upcoming events where I will speak about using the profiler that is part of the Windows Phone 7.1 SDK tools. Understanding how to use the profiler and how to act on profiling results will help you improve performance of your Windows Phone applications. However, there is much more you can regarding application performance. Do you support Fast Application Switching in your own applications? Are you using Background Agents and against which price? Are you using IsolatedStorage as efficient as possible inside your own applications? What does that even mean: “using IsolatedStorage efficient”? What are the (performance) costs of persisting data in your application and how can you limit those costs? These are questions that I will answer in the upcoming months by showing sample code, showing lots of profiling results and writing / talking about performance. This is a topic I am passionate about. Hopefully you are as well. After all, performance is important for phone applications. End users will appreciate Windows Phone even better if all our applications will have great performance and batteries can be charged less frequent. Stay tuned, those performance posts will be published soon.

Running for the first time

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

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

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

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

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

Visual Studio 2010 With my app

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

Eclipse with my Android App

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

image

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

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

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

image

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

image

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

After installing the tools, my score was:

Windows Phone vs. Android: 1 – 0

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

Windows Phone vs. Android: 4 – 1

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

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

Windows Phone.

Ease of installation

Of course I am a bit biased, even though I am trying to be objective, independent and open minded. Over the last hour or so I have been busy setting up an Android development environment. If you are wondering why, it is not just out of curiosity, I am also preparing for a training I am taking next week. Over time it is going to be cool to find and understand differences between developing for Windows Phone and for other mobile platforms. I am planning to share my experiences in one way or another.

When I started developing Windows Phone applications, I just went to the App Hub, clicked on the link to download the free tools, and waited for Visual Studio 2010 Express for Windows Phone and Expression Blend 4 for Windows Phone to download and install. The development / design environment comes with a great emulator and within 30 minutes I was up and running (yes, I was using a slow Internet connection).

Today the story was slightly different. In order to start developing my first Android application, I had to download and install a Java SDK for which I went to Oracle. The next step was to download and install the Eclipse IDE for Java EE. Everything so far installed without any problem, but there is more to install. The next thing to install is the Android SDK, which has a nice Windows Installer. But wait ….  what is installed is the SDK Starter Package, with which you can download the SDK’s you need for your particular target. It looks like the SDK Starter Package is a specific download manager for multiple Android SDK’s. The challenge now is to find out which SDK I need. I decided to just install the latest version, being SDK Android Plaform 3.2, API 13, revision 1. Hopefully this is the right SDK to get started. Finally, the ADT plugin for Eclipse is needed. Installing the plugin is done from inside Eclipse. In order to get the plugin, you have to run through 8 different, but easy steps. Once Eclipse is restarted, it now should be possible to develop my first Android application. Now, instead of 30 minutes to install a development environment, it took me over 2 hours. However, remember, this is the very first time that I am going to work with Eclipse, a Java SDK and Android. I can imagine that experienced Android developers install the tools way faster than I did. However, so far my conclusion for the day:

Windows Phone vs. Android: 1 – 0.

Introducing Windows Embedded Handheld

After the release of Windows Phone to the market, you might wonder what became of Windows Mobile. If you are not really familiar with the embedded product line of Microsoft, you might think that Windows Mobile is completely gone. However, if you take a look at a particular Windows Embedded product, being Windows Embedded Handheld, you can see that this is the continuation of Windows Mobile, modernized and rebranded. If you want full device access and be able to use all exposed Win32 API’s, if you want freedom to deploy applications outside marketplace, if you want interoperability possible between different applications, Windows Embedded Handheld might be your best choice.

Windows Phone Application Development & Debugging – Deactivation versus Tombstoning

While creating an update of an existing application I ran into a problem that sometimes occurred when the application was moved to the background. It turned out that the application behaved consistent with no exceptions raised when it was tombstoned after being moved to the background. However, the application sometimes crashed when it was deactivated and immediately became the executing application again without being tombstoned. In a later post I will explain the specific problem that caused the application to crash, for now I want to focus on ways to easily test deactivation scenarios.

Visual Studio 2010 has great support to test tombstoning scenarios for Windows Phone applications. Simply start debugging an application on a device or on device emulator and click the start button on the device (emulator). You will notice that the application moves to the background but that Visual Studio does not terminate its debugging session. Putting a breakpoint inside Activated / Deactivated event handlers shows us that the application is indeed being tombstoned / resurrected.

Visual Studio and Tombstoning

The debugger shows that the application is still running even though the application is no longer visible on the device. By using the back key on the device, it is possible to return to the application and to continue debugging it. However, if you start the application again on the device (so not using the back key), the debugger terminates. This means that a brand new instance of the application was started. Inside an application, it is possible to distinguish between a new instance being started and resurrection from being tombstoned by acting on the Launching or Activated events respectively. In both cases, the constructor of the page that becomes visible will be executed. More information about the application life cycle of a Windows Phone application can be found in this excellent series of blog entries by Yochay Kiriaty.

There are situations where an application is moved to the background without being tombstoned. In those situations, the application simply remains resident in memory, with its process being kept alive. When the application is activated again, it simply continues running without the need to create a new physical instance of the application. For end users the behavior is identical to tombstoning, after all, the application becomes invisible when another application starts executing. For developers there is a difference though, because no Launching or Activated event is raised and no constructor code (for instance for the currently visible page) is executed. To be able to consistently test application deactivation requires some additional work. One of the ways to ‘force’ deactivation over tombstoning is by starting a PhotoChooserTask. In my own application I simply use the application bar to add a new ApplicationBarIconButton to display a PhotoChooserTask.

To assure that this ApplicationBarIconButton is only visible in Debug mode, a bit of conditional compilation is needed. The following code snippet shows how to create a new ApplicationBarIconButton programmatically, add it to the ApplicationBar and add an event handler to its click event.

Adding an ApplicationBar Item
  1. #if DEBUG
  2. PhotoChooserTask _pt;
  3. #endif
  4.  
  5. public MainPage()
  6. {
  7.     InitializeComponent();
  8.  
  9. #if DEBUG
  10.     _pt = new PhotoChooserTask();
  11.  
  12.     this.ApplicationBar.IsVisible = true;
  13.  
  14.     ApplicationBarIconButton pauseButton = new ApplicationBarIconButton
  15.     {
  16.         Text = "Pause App",
  17.         IconUri = new Uri("/Images/appbar.transport.pause.rest.png", UriKind.Relative),
  18.         IsEnabled = true
  19.     };
  20.  
  21.     pauseButton.Click += new EventHandler(pauseButton_Click);
  22.     this.ApplicationBar.Buttons.Add(pauseButton);
  23. #endif
  24. }

Of course, adding a button to an existing ApplicationBar only works if the application has 3 or less ApplicationBarButtonIcons in use. An alternative could for instance be adding a MouseLeftButtonDown event handler to the application’s title. When clicking the ApplicationBarButtonIcon you created specifically for debug purposes, what you now can do is display the PictureChooserTask. This results in your application being pushed to the background, without being tombstoned.

Forcing us to the background
  1. void pauseButton_Click(object sender, EventArgs e)
  2. {
  3.     _pt.Show();
  4. }

This approach makes it relatively easy to test the different scenarios for your application going to the background and returning to the foreground again. Here are the results in a little test application.

TombstoningOrNot

In the left screen you can see the application immediately after the main page became visible. In the center screen you see the result of clicking the pause button, after which a PhotoChooserTask was activated and closed again. What you can see is that there is no Application_Deactivated / Application_Activated combination. You can also see that no constructor is called after returning from the PhotoChooserTask. In other words, the application is not tombstoned while the PhotoChooserTask is active. Finally, the right screen shows how the application returns from being tombstoned. In this case constructors are called and Application_Activated is raised.

The issue I had in one of my applications had to do with counting on constructors to be called to dynamically add a few controls to my visual tree.

Note: This blog entry is applicable for Windows Phone 7. For the next version of Windows Phone (codenamed Mango), developers can choose between tombstoning and fast application switching by setting the corresponding property in the project settings. Fast application switching could be considered as another state in the application’s life cycle, being very similar to the situation that was described in this post using the PhotoChooserTask.

MEDC Revitalized?

This is something I really hope will happen one day. Until 2008, Windows Embedded and Windows Mobile developers had their own conference, MEDC. Since that time, Windows Embedded and Windows Mobile developers could find some interesting content at the various Tech-Ed conferences around the world. However, it is of course very different to be part of a larger conference, owning one track with something like 16 breakout sessions, or having your own dedicated conference with perhaps as much as 100 breakout sessions. At Tech-Ed, it seems that Windows Embedded presence is getting smaller and smaller. Of course the mobile arena has changed a lot over the last 2 .. 3 years. Windows Mobile has been rebranded to Windows Embedded Handheld. Apart from that, Windows Phone, being a brand new platform has been released. Windows Phone technical content has been presented at MIX and at Tech-Ed over the last two years. Windows Phone will also at least be present at the brand new Build Conference later this month.

So what about Windows Embedded in all its flavors? Some time ago, there was an intriguing pre-announcement here at the Windows Embedded website. The information about a possible new embedded developer conference is still there. However, I was just looking at the listed twitter feed for updates around this conference, but I didn’t find any updates. Hopefully this announcement was not just a teaser. I think it would be great if there would be another large scale developer conference, organized by Microsoft and dedicated to Windows Embedded technologies. To make my dream even better …. It would be great if Windows Phone would be present at such a conference as well, after all, Windows Phone runs on one of the Windows Embedded Operating Systems.

Where did my ads go?

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

ClickerLiteDesignerView

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

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

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