Windows Phone Developer Blog

Listbox, Why Art Thou Blanking?

Oren Nachman — Thu, 17 May 2012 00:53:58 GMT

One of the biggest performance changes for developers using Silverlight in Mango (WP 7.5) is off-thread input for ListBox. In a nutshell this basically means that all any flick or pan a user makes on a ListBox is handled by a dedicated thread, the Direct Manipulation (DM) thread, instead of the UI thread. By connecting the DM thread to the Compositor thread (that’s the one that does all the drawing to the screen independent of the UI thread) we have a ListBox that moves smoothly even when the UI thread is completely blocked.

Unfortunately this also comes with a price – the ListBox is now so responsive and moves so fast that the Listbox can run out of content to display to the user as the user is flicking, and blank – basically drawing nothing except for an updated ScrollBar (so the user knows he’s still moving in the ListBox, but it doesn’t help much) and the background while the UI thread scrambles to bring in new items to fill up the holes.

My ListBox isn’t blanking, why do I care about this blog post?

You care because you care about your users. You’re the kind of dev who knows that even though he’s got a great, powerful phone, not everyone does. You care because you are proud to call yourself a developer. You care because… ok, back to reality.

With the release of Tango, Windows Phone is now supported on lower powered machines which often have slower hardware and less memory, so even though your device shows no blanking, others may see blanking, especially if they’re rocking a new, lower powered, Tango phone. This post will help give you the tools that let your app run smooth, with hardly any blanks, even on those phones.

My ListBox is not blanking, but it’s really jerky during scroll

Holy Smokes Batman! Jerky scrolling is all but eliminated in the new ListBox, even for WP7 apps – are you sure you’re using it? There’s a good chance you’re using the original LongListSelector (LLS) from the toolkit, which doesn’t auto-update when you move your project to Mango. To take full advantage of the new ListBox improvements you need to download the latest toolkit from http://silverlight.codeplex.com and update to the new LLS which is based on the platform’s ListBox.

Why does blanking occur: the nitty gritty

There are a couple of common code / design reasons that cause a ListBox to blank, but in general it all boils down to the amount of time it takes to bring in a new item. The ListBox maintains a one screen buffer of items in each direction which moves with the user’s viewport as they scroll around. If the ListBox can’t fill that buffer in the direction of the scroll fast enough, you get blanking.

Diagram 1: In a stationary world, when there is no scrolling going on, the user will be looking at the center screen and there will be buffered items waiting to be shown in both directions

Filling the buffer takes a few steps, namely creating an Item Container (if a suitable one from the excess buffer in the other direction doesn’t already exist) and Data Binding the new item’s content (which kicks off the Measure pass). All of these updates occur on the UI thread and they all happen at once (not item by item) so if a flick is fast and the ListBox realizes that it needs to draw a full screen worth’s of items it will block the UI thread while it does just that.

Diagram 2: As the user moves downwards we balance the buffers by transferring the excess buffer from the top buffer (red) to the bottom buffer and re-databind it to the new data, maintaining 1 screen of buffer in each direction.

But if the user flicks again while the UI thread is blocked bringing in buffer items, we’ll get even more out of sync and move completely out of our buffer space – since there is nothing in the Control to draw (remember, the ListBox is still scrambling on the UI thread to bring the new items in, it’s just too slow) you just get the background, i.e blankness.

If there’s nothing to draw, why is the ListBox still moving? Or, look at it from another angle:

As we mentioned earlier, scrolling is now off-thread, so from the Compositor’s point of view it’s moving the ListBox and everything in it, the problem is that the UI thread hasn’t stuck anything in it (at that position) yet, so we blank.

Diagram 3: Fast flicking a few times get you into this situation, where we have excess buffer above which we are trying to move downwards, but because there is so much of it and the UI thread is blocked trying to bring these items in we don’t finish in time and the user sees blankness (black) until the items are ready, at which time they simply appear.

So why is *my* ListBox blanking? And how do I fix it?

Let’s run through a couple of common reasons why ListBoxes blank, with some proposed solutions to each one.

1. Using ValueConverters in your template

ValueConverters are great – they allow you to transform your data on the fly as they are being DataBound into your items. Unfortunately they incur a UI thread cost – we need to transition from Silverlight into User Code, run your converter and then return. If your converter is heavy or you’re using lots of them in your template, then this will introduce blanking.

Question to ask yourself: does this code look like it can run in a trivial amount of time across all of the elements being brought in for a given frame? If not, you probably should explore a different way of doing the DataBinding. For example,you can have the object translate the values on population / property get time instead of using a converter - even though this may break your Data Model this can significantly reduce the DataBinding cost (and you could always wrap your object in a ViewModel).

2. Complex DataTemplates

When an item is moved from one buffer to another during a scroll, ListBox is usually smart enough to determine that this is the same kind of item and just update the data in the item. While this might sound cheap this dirties the item causing it to be remeasured. If your template is complex you will find that a lot of your time is wasted in Measure – remeasuring the layout of the control now that the data has been updated.

Fixing this is very per-scenario. Some general guidelines are to make sure to only use a container if you really need the options it provides – do you have a Grid within a Grid? Could you replace all of your Grids with a simple Canvas or maybe a StackPanel?

3. Decoding images on the UI thread

By default all images are decoded synchronously on the UI thread, so if you have something like this:

you're going to block the UI thread for however long it takes to decode your image. Luckily there’s an easy fix for this, change your template to read as follows:

Note that this does come with some caveats – older images will still show up until the new ones are loaded and the user may see a visual pop-in of the image when it is done loading, but these can all be worked around and massaged into a nice user experience that is not harmed by excessive image decode.

For further details see this blog post.

4. Using PrepareItemForContainerOverride to dynamically select a template

A simple list item is often times just not good enough – your app has an image item, a text item, a video item, a link item etc. etc. and you have a different template for each one of them. A common pattern is to use the ListBox’s PrepareItemForContainerOverride callback to dynamically change the container’s template based on what item is being databound.

Unfortunately, doing this can completely throw off the ListBox’s buffering technique – the ListBox sees that the container that it had in its buffer is not the type that you need and junks it, wasting even more time on the march to blankness.

So how do I solve this? Surprisingly enough, it is often cheaper to have all of your template parts in one large template (yes, yes, I know about point 2 above – keep reading!) with each mini-template collapsed if it does not apply. Since collapsed template items incur next to no cost during layout, they have next to no impact on run time (though there is a slightly larger memory cost).

And how do I get my different items to display on the different templates? Simple – databind to a new property on your classes which either has a type enumeration that runs through a value converter (ItemTypeToVisibility), these kinds of converters are often cheap, or wrap your class in a UI view model so that it has a property that returns the Visibility type directly.

5. Pulling data from [favorite heavy source] as part of your binding

The properties you bind to should have simple getters (setters is a different story) – always. If you have logic like this:

public int Rating
{
get
{
    <read from database>
    - or -
    <read from IsoStore>
    - or -
    <parse out some XML>
    - etc -
}
}

then you’re doing something wrong. This kind of logic is fine for a property that you know is only read very rarely, if at all, but if it’s in a ListBox then it most likely is going to be seen and you should be initializing the data up front.

Don’t get me wrong – you don’t need to load everything as you are pulling in 1000 items to your list, but you can certainly do it on a background thread as a deferred task kicked off in the constructor of your object. If your objects are really heavy and memory is becoming an issue then you have a few possible routes:

Implement a completely delayed load by hooking into the ListBox’s scroll amount or compression states and only loading more items when you get to the end of the list
Implement a DoubleLinkedObservableCollection, where each item in the collection knows about the next node (in each direction) and when it gets databound (based on one of the properties) it notifies X number of nodes on each side to make sure they all have their data ready to go. This should be done on a background thread, just don’t forget to Dispatch back to update any properties that raise a PropertyChanged event.

6. Cut down background work

With only one core any background thread can interfere with the smoothness of the UI thread. Although background threads get a much smaller time slice compared to the UI thread, enough of them vying for time will effectively starve the UI thread.

Diagram 4: Fictional time slice showing the effects of more background threads (not to scale)

Across any given slice of time, the UI thread will be allowed to run longer than any other thread, but is effectively running at the same priority, hence it is forced to yield to the background threads when its time is up. The more background threads, the longer it is before you get back to the UI thread so that it can complete its task.

Moral of the story? Be wise about the number of active background, especially in high stress scenarios. Stick to using a thread pool so that you can queue up your work without it all trying to run at the same time.

I’ve tried all the above, it’s still blanking and I only have a couple of screens of data – help!

If you find yourself blanking on a relative small set of data (approximately 3-5 screens), then it might be time for drastic measures. As mentioned above the cause for blanking is the amount of time it takes to bring in new items with new data as the user is scrolling, i.e. the virtualization overhead is the culprit. If you disable virtualization on your list, you’ll generate of all your items up front and scrolling will be blankless. To do this, add the following to your XAML:

<ListBox.ItemsPanel>
  <ItemsPanelTemplate>
    <StackPanel>
    </StackPanel>
  </ItemsPanelTemplate>
</ListBox.ItemsPanel>

While making this change is relatively simple, the impact can be drastic – no more blanking, but it comes at a cost:

Startup time for the Page increases – we now have to realize more items, so it’s going to take longer
Memory – same as above, more items hanging around, larger memory cost

If you give it a try on a low end device and startup and memory look acceptable – then this is your magic bullet!

So what are we left with?

Hopefully at this point you have a non to minimally blanking list, which scrolls smoothly and generally delights your users! Have you run into any other pitfalls that you think others should be warned of? Let us know below!

Running into other, unrelated performance issues? Drop us a line and we'll see if we can focus on them in a future blog post (stay tuned for a "memory" series coming soon).

Memory Profiling - The Heap Summary View

Pratap Lakshman — Thu, 10 May 2012 16:24:11 GMT

In an earlier post we looked at how we can gain broad insight into an application scenario’s memory characteristics and how the graph and markers drew our attention to ranges of execution for further analyses. Recall that in the memory leak diagnosis case we chose to analyze only the time range over which we observed the increase in memory usage. Indeed, that is a key first step to the analysis: filtering the memory activity data by a time range. The Heap Summary view is the result of such filtering, and represents the population of the heap during the chosen time range.

Heap Summary View

The Heap Summary view presents, in tabular form, a demographic analysis of the population of the heap.

In human population demographics, data collection happens through a census as well as through a continuous update to registries that track births, deaths, migration of place of residence and the like. The data collection in the case of heap population demographics is no different. “Births” map to allocations, “deaths” map to objects’ memory collected by the GC, and “migration of place of residence” maps to the migration of objects between the Gen0 region of the heap and the Gen1 region. A census of the heap at the start of time range identifies all incumbent objects (i.e. that were in existence). Births, deaths, and migrations are updated continuously, and a final census at the end of the time range identifies all the objects that were retained. In order to have a consistent terminology, we refer to the incumbent objects at the start as objects that were “retained” at the start.

Managed Silverlight Visual elements (i.e. objects that go into the Silverlight visual tree) are not just plain old managed objects. These might be facades with backing native-implementations holding native memory and during the course of execution might create and hold on to texture memory. Casual use of such elements in code can even lead to subtle leaks. From this perspective, subsequent analysis can be made easier if Silverlight Visual elements were tracked and reported separately from plain old managed objects. And this is precisely how they are tracked and reported through the Heap Summary view. Continuing with the demographic analogy, such classification has precedent in social demographics where human populations have been classified on ethnicity.

Armed with this context, let us study the following Heap Summary view from the memory leak diagnosis case:

The shaded region across the graph and markers indicates the time range used as the filer.

The census at the start reports 5576 instances of managed type objects accounting for about 283 KB and 26 instances of Silverlight Visual elements accounting for about 13 KB. In terms of incumbency the plain old managed objects dominate.

The churn happening within the selected time range is reported as 10615 instances allocated (births) and 11590 instances collected (deaths), accounting for about 23 MB each. The counts and sizes are somewhat balanced and cancel each other out to an extent. And this is borne out by the census at the end for the managed objects; the census at the end reports 4601 instances of managed type objects accounting for about 223 KB, which is just a little lower than what we had at the start. However, it also reports 69 instances of Silverlight Visual elements accounting for about 4 MB now (up from 13KB at the start).

When we correlate this table with the graph, our suspicion is drawn towards the Silverlight visuals. Why did their count go up, and why are they accounting for so much more memory? Within the filtered time range, memory usage has been steadily increasing too. Could we be leaking memory? Could we be leaking some part of visual tree itself? And there even seem to be images being loaded along the way; might we be leaking their texture memory too? We wonder.

Clearly, the next lead to follow is to get more visibility into what are those “Retained Silverlight Visuals at End”.

Summary

The Heap Summary view presents, in tabular form, a demographic analysis of the population of the heap. Interpreting the data in the table and correlating it with the graph and markers by itself can be used to make educated guesses at what could potentially be the problem, but equally importantly it serves to inform the next step in the performance investigation, as we shall see.

Delivering Rich Mobile Web Experiences in Windows Phone 7.5 (ESPN.com Case Study)

Amin Lakhani — Wed, 02 May 2012 16:09:42 GMT

The Windows Phone Browser team has a goal of delivering the best web browsing experience on a smartphone. This goal has many components within our team: from the UI of the browser, compatibility with a wide array of website layouts, and of course buttery-smooth rendering performance. However, even if we execute flawlessly on our end, we are missing a crucial piece - delivering a great web experience is fundamentally a partnership between our team and web developers. Achieving this goal means working together to ensure that your content and services are delightful for users to consume on Windows Phone.

We understand that web development resources are always limited as you keep up with the increasing traffic from mobile devices, and the elusive "write once, run everywhere" promise of web development has not perfectly materialized. However, with IE9 for Windows Phone 7.5, we took a big step in the direction of this promise. By sharing a codebase with IE9 for the PC, we achieved identical support for new web standards and pushed the envelope on real-world performance with industry-leading hardware acceleration. We wanted to hear about developing for IE9 on WP7.5 from web developers directly, so we decided to collect some feedback and share it on the blog.

ESPN.com recently deployed their premium web experience to Windows Phone, and we thought it would be great to hear what they had to say about developing for IE9 on Windows Phone. As a side note, ESPN started looking into supporting Windows Phone because of a simple request I made on their support page. Lots of folks on my team are sports fans and were asking me about the site's experience on WP7.5, so I just dropped ESPN a note like any user would. The message was quickly routed to the mobile site team; I have immense respect for ESPN’s responsiveness and the system they have place to address user feedback. Here's what Mike Marrone, technical lead, had to say about developing for IE9 on WP7.5:

Overall, it was an easy process. We support only WP7.5 and IE9 thanks to its very good CSS3/HTML5 support. We are in a convenient position of having an existing legacy mobile site that older devices can fallback to. Honestly, development for WP7.5 boiled down to a fairly basic process - IE9 on the PC, being nearly the same browser, was a great dev tool to get most of the way there before final QA on actual devices.

Some other more specific development notes:

The "display: box" CSS style is not supported on WP7.5. We use this in carousel experiences to transition elements left or right 100% of the viewport without having to programmatically determine the viewport size (which means the browser automatically updates the positioning upon device rotation, etc.). On WP7.5, we actually used a better alternative thanks to it being the only browser that currently supports the CSS "vw" unit (VERY useful).
[Amin] See here and here for more information on vw units.

The bulk of our CSS differences between WP7.5 and other supported devices was with gradients. WP7.5 has an easy fallback with filters so it was not a big development issue.
[Amin] See here for information on using Gradient Filters in IE9.

JavaScript touch events would be a nice addition.
[Amin] We hear you, stay tuned!

We look forward to your continued great progress in mobile.

As you can imagine, this was music to our ears! We often use IE on the PC to investigate bugs, and it was great to hear that the tools work well for web development outside of our offices too. We appreciate the feedback (it will inform our plans for future releases) and welcome additional feedback through the comments below.

IE9 on Windows Phone is set up to support rich web experiences with great performance, and often all it takes is updating user-agent logic and using standards based (as opposed to vendor prefixed) HTML & CSS. ESPN invested a reasonable level of resources to do that and delivered a delightful experience to its users. I've definitely started to see the site pinned to Start around here, and I wouldn't be surprised if our senior managers are secretly checking ESPN during meetings.

Here's a before (left) and after (right) screenshot of the ESPN.com experience on Windows Phone 7.5. We want to say thanks to ESPN, and we look forward to seeing more rich experiences light up!

Special thanks to Krys Krycinski, Mike Marrone, and James Ballow at ESPN.

Amin Lakhani
Program Manager, Windows Phone

Four ways we’re improving Marketplace

Todd Brix — Mon, 30 Apr 2012 21:48:45 GMT

Today I’ll outline the latest steps we’re taking in our ongoing effort to keep the quality bar high in our rapidly growing Marketplace. I know most of you share our goal of a great shopping experience and already go out of your way to follow our policies and guidance. For others, I hope this insight into a few near-term changes we’re putting in place helps save you time and reduces your risk of having apps pulled from the Marketplace.

Avoiding trademark trouble

When a trademark or copyright owner contacts us about a suspected violation, we investigate and pull apps when the complaint is valid. Lately we’ve been doing more of this, especially for trademark misuse. Sometimes the requests come from the owners of big, well-known brands. Other times they come from new brands. Either way, we often find trademark violations are unintentional: some developers just aren’t clear on what constitutes a violation. But these investigations—and the time and money they can cost—can be avoided by doing a little homework before submitting or updating your app.

If you’re developing an app, please consult our content policy covering trademarks and this related Q&A. (The U.S. Trademark and Patent Office also has helpful background and a trademark search tool.) Our rules boil down to this: Your registered publisher name and everything about your app—name, logo, description, screenshots—must be unique and free of trademarked content unless (1) you own the trademark, (2) you’ve secured permission from the owner to use it, or (3) you’re using a trademarked name (not a logo) to describe your app’s features or functionality without suggesting that the app is actually published by the trademark owner.

For example, using “Microsoft App Co.” as your publisher name would cause problems because “Microsoft” is a trademarked term. By the same logic, you couldn’t call your app “MSN” or “YouTube”. However, you may be able to make an app called “Reader for MSN,” as long as you don’t use the MSN logo or otherwise suggest that the app is published by Microsoft.

Keeping the quality bar high

I’ve posted before about our efforts to help ensure that apps in Marketplace offer clear value. One of those efforts concerns bulk publishing—developers who send us hundreds of similar apps simultaneously. Today I want to mention two related issues on our radar that could affect developers working on app genres that lend themselves to bulk publishing.

First, we’re seeing developers submit the same app to multiple Marketplace categories, a violation of our policies. Instead, you should pick a single category that best reflects the content and function of your app. This not only helps customers find your app but gives all developers an equal opportunity to have their app discovered where people expect. Developers who submit the same app across multiple categories will have it removed from the catalog.

Second, when you create multiple closely-related apps—say, a series of quote apps that vary by theme—the Marketplace tile images must reflect the unique features of each individual app. They cannot be duplicates or near duplicates of each other. Your branding also shouldn’t dominate the tile. Here are a few examples of dos and don’ts:

Creating unique, easily distinguishable app tiles helps customers see at a glance what’s different about the apps you’re publishing, improving the shopping experience and potential for downloads.

Cleaning up keywords

Some developers have been violating Marketplace policy by entering more than the five allowed keywords for an app. A keyword is a word or short phrase that describes your app. Entered during the App Hub submission process, these words or phrases are always separated by commas.

Starting this week, we’re going to start enforcing the five keyword rule for all current and future Marketplace apps. Any app that exceeds this number will have all its keywords deleted. Affected developers will be notified and can then enter five new keywords in App Hub. We’re taking this action to help ensure that customers are able to find the most relevant set of apps for their search—including yours.

We’re also starting to examine app keywords for relevancy. We’ve noticed some developers have been entering keywords that are popular search terms—“Justin Bieber,” “YouTube”—but are totally unrelated to their app and what it does. If we find a keyword that’s not relevant to your app’s function or content, we’ll delete that keyword. Additionally, if you suspect that other developers are using high-impact keywords unrelated to their app— “Skype” for a tic-tac-toe game, for example—email reportapp@microsoft.com with the details and we’ll investigate.

Refining our approach to content policy enforcement

The final issue I want to discuss is one that affects all major app stores today: the treatment of apps that are “racy” or sexual in nature. We’re committed to offering a diverse selection of safe and quality apps that appeal to a wide range of customer interests. Items that some customers view as entertainment, others may consider inappropriate. This is a challenge for any big retailer, whether they operate online or down the street.

We think the right solution is (a) to be transparent about what’s acceptable and (b) to show the right merchandise to the right customer in the right place. Our content policies are clearly spelled out: we don’t allow apps containing “sexually suggestive or provocative” images or content. What we do permit is the kind of content you occasionally see on prime-time TV or the pages of a magazine’s swimsuit issue.

Admittedly, it’s tricky catering to such a wide range of people and markets. But we take this responsibility seriously and evaluate and discuss questionable cases. Recently we decided that we could improve the shopping experience for all our customers by a more stringent interpretation and enforcement of our existing content policy.

Specifically, we will be paying more attention to the icons, titles, and content of these apps and expect them to be more subtle and modest in the imagery and terms used. Apps that don’t fit our standard will need to be updated to remain in the store. This is about presenting the right content to the right customer and ensuring that apps meet our standards. We will also monitor customer reaction to apps and reserve the right to remove ones that our customers find offensive

While this change might require a little extra work on the part of a small number of developers, there are plenty of creative and appropriate ways to comply: showing male or female models in silhouette, for example, is one possible alternative. Here are a few other examples of app tiles that pass muster:

If you’re one of the handful of impacted developers, we will be reaching out to you within the next few days with more specific guidance on changes you need to make. If you don’t hear from us, there is no immediate action you need to take.

I hope this post has provided some useful tips and helpful insight into our policies, and how they’re evolving to reflect both customer and developer feedback and the growing size and reach of the Windows Phone Marketplace. We’re committed to our developer community and appreciate your feedback on how we can make Marketplace better for you and your customers. I look forward to hearing your thoughts.

Two Marketplace changes; An update on 9 new markets

Todd Brix — Tue, 24 Apr 2012 22:49:34 GMT

I wanted to make sure you saw the Windows Phone consumer blog today, because my colleague Mazhar highlights two changes to the Marketplace shopping experience that developers should be aware of.

First, we’re removing the option to browse and buy Windows Phone apps from the Zune PC software, a change that started rolling out this afternoon. Second, in the coming weeks we’ll also start requiring that customers have Windows Phone 7.5 installed on their phone to buy, download, update, or review apps in Marketplace.

Mazhar’s post has more details and background. But I want to highlight one important way the removal of the Windows Phone store from Zune impacts developers.

It’s important to make sure you’re using the correct protocol for direct links to your app in Marketplace. This “deep link,” as it’s also called, makes it easy for customers to pull up your app in the phone and web stores. The correct format is:

http://windowsphone.com/s?appId={GUID}

You’ll find more details on deep links here on MSDN. If you use the older zune:// format for links, customers will see an error message. Just something to keep in mind.

One final update for today: We just released the OS software required to bring Marketplace to customers in Bahrain, Israel, Iraq, Kazakhstan, Qatar, Saudi Arabia, Thailand, UAE and Vietnam. These nine markets—which are already open for app submissions—were part of the larger Marketplace expansion I outlined last month. Our hardware partners can now create phones for these markets and begin their final launch preparations.

Mazhar will have more to say about these new storefronts in the weeks ahead.

Respond to User Input

Mike Battista — Tue, 24 Apr 2012 15:53:00 GMT

The fourth of the four principles I mentioned in Optimizing Apps for Lower Cost Devices is Respond to User Input.

A responsive UI is a basic expectation that users have of apps. Failing to respond to user input can frustrate users and can ultimately drive them away to other apps that are more responsive.

The basic guidance here is to keep as much activity off of the UI thread as possible until absolutely necessary. The UI thread is what processes user input for you, so any code you execute on that thread will interfere with this processing. Unless you're updating elements of your UI, you generally should not be executing code on the UI thread.

A quick way to check whether a block of code is running on the UI thread is to call Deployment.Current.Dispatcher.CheckAccess() inside that block of code (Intellisense won't show this method but it is there and useful). This will return true if the code is executing on the UI thread, so if this returns true and you're not updating your UI, then you've found code that could be moved to background threads.

An easy way to move code to background threads is to wrap it in a call to ThreadPool.QueueUserWorkItem().

// Running on the UI thread.
...

// Running on a background thread.
ThreadPool.QueueUserWorkItem((o) =>
{
    ...
}

The ThreadPool is (as its name suggests) a pool of background threads that are waiting to execute work items for you. QueueUserWorkItem enables you to register blocks of code that will execute on the next available background thread in the ThreadPool. Note that use of ThreadPools is common and encouraged across many platforms (including Windows 8) so familiarizing yourself with them will serve you well in future projects.

When you are ready to update your UI, you will need to return to the UI thread. You can return to the UI thread at any time from a background thread by wrapping your code in a call to Deployment.Current.Dispatcher.BeginInvoke().

// Running on a background thread.
ThreadPool.QueueUserWorkItem((o) =>
{
    ...

    // Running on the UI thread.
    Deployment.Current.Dispatcher.BeginInvoke(() =>
    {
        ...
    }
}

If you try to update your UI from a background thread, you will receive an UnauthorizedAccessException with the message "Invalid cross-thread access." In these cases, wrap the offending code in a call to Deployment.Current.Dispatcher.BeginInvoke() as shown above to execute it on the UI thread as required.

In addition to being able to control whether your code executes on the UI thread or on background threads, you also have options to do the same with framework code in several places.

Image decoding is an expensive operation that can harm interactivity significantly if executed on the UI thread, particularly if you're loading many images at a time. The framework allows you to specify BitmapCreateOptions to control whether image decoding executes on the UI thread or on background threads. Be sure to use the BackgroundCreation option to move image decoding to background threads.

The built-in ProgressBar control has known performance problems that can harm UI performance as a result of its animations executing on the UI thread. Use the SystemTray ProgressIndicator for the best performance as the ProgressIndicator is a shell component that will not interfere with your UI thread. A bonus to using the ProgressIndicator is that your UX will more closely match the UX of the built-in experiences.

If you're using animations in your app, use Storyboards wherever possible as these run on an important background thread known as the compositor thread and will not interfere with your UI thread. If you're familiar with Expression Blend, it can be particularly useful for generating Storyboards.

With code now running off of the UI thread for a given page, you should also focus on optimizing navigation between pages.

To keep page load times and in-app navigation responsive, defer loading activities until the first frame is rendered. The guidance for optimizing startup time of your MainPage applies to optimizing the startup time of subsequent page loads as well. Enabling the TiltEffect is a great way to acknowledge user input and indicate that navigation is in progress. This will make your app look and feel more like the first party experiences as well.

Many apps add page transition animations to add style to in-app navigations. While this is a great practice to make your apps more dynamic, excessive use of transition animations can delay load times, particularly when the generation/execution of the animations result in spikes in memory/CPU usage. If transition animations are causing performance problems in your app, disabling them completely, or at least on low-memory devices only, can significantly improve in-app navigation performance.

Maintaining a responsive UI is important regardless of the platform you are targeting. By offloading work to background threads and keeping in-app navigation fast, you'll provide the best possible experience to your users.

Memory Profiling - Launching, Graphs and Markers

Pratap Lakshman — Thu, 19 Apr 2012 18:25:04 GMT

It is said that “A point of view is worth 80 IQ points”; the meaning perhaps being that if we can look at things in different ways then we might understand them better. The Memory Profiler that ships with the Windows Phone SDK 7.1 provides, in its own way, multiple views into the memory usage of your application, and in an earlier post we had seen how specific views helped us understand one particular issue with the application better. But even before we got to the specific views, there was a graph and a couple of rows of markers, remember? Let us discuss them briefly.

Launching the Memory Profiler

How do you even know that you need to run your application scenario through the Memory Profiler, especially since there might not be any obvious visual cue? The answer lies in an Execution Profiler warning message. The expectation is that you would run your application scenario through the Execution Profiler for evaluating visual and code performance, and if it suspects any memory related issues it will raise a warning message suggesting running the scenario through the Memory Profiler!

Users of the Execution Profiler will find the interaction model of the Memory Profiler familiar. It launches from the same page, with the difference being that you select the Memory (managed object allocations and texture usage) option. The Advanced Settings option can be ignored for the purpose of this discussion. The following is the launch page for the Memory Profiler:

A warning message is issued if the deployment target happens to be the Windows Phone Emulator. The emulator runs on the desktop, and the desktop has a different hardware architecture than the device, with different performance characteristics across the board. The warning therefore alerts you to this lack of performance fidelity. If you are doing Execution profiling beware! The emulator is still a suitable target for doing memory profiling since in that case we are dealing with (memory) allocation profiling. Clicking on the Launch Application link deploys the application to the target and commences the profiling session.

Stop Profiling

There are two ways to gracefully end the profiling session:

By hitting the Stop Profiling link on the Profiler page.
By hitting the back button on the target (device or emulator) until you exit the application.

If the connection from Visual Studio to the target is broken for any reason (for example, if the emulator instance is closed, or the device is untethered, or the device shuts down, the connection is broken) the session is aborted.

Once the session is gracefully ended, the data gathered during the run is processed and presented graphically for analyses, starting with a Memory Usage graph plotting memory usage over time, and two rows of markers indicating image loads and GC runs as shown below:

Memory usage graph

The memory usage reported is that of private bytes: exclusive bytes allocated by the process being profiled. Some variance in memory usage is normal and not indicative of a problem. However, memory usage that keeps rising bears examination.

Image load markers

A tooltip on the image load marker indicates the encoding format, the ID of the executing thread on which it got loaded, the point in time when it was loaded, and how long it took to load. A spike in memory usage corresponding to an image load marker might indicate a large sized image being loaded (larger than 2000 x 2000 pixels). Windows Phone imposes this limit, and larger images will be sampled at a lower resolution, and will take longer to load. If you must use large images consider displaying only a portion that meets this limit by loading the image into a System.Windows.Media.Imaging.WriteableBitmap and using the LoadJpeg(WriteableBitmap, Stream) extension method as shown below:

int width = (int) this.image1.Width;
int height = (int) this.image1.Height;
Uri uri = new System.Uri("image.jpg", UriKind.Relative);
StreamResourceInfo sri = Application.GetResourceStream(uri);
WriteableBitmap wb = new WriteableBitmap(width, height);
System.Windows.Media.Imaging.Extensions.LoadJpeg(wb, sri.Stream);
this.image1.Source = wb;

The ID of the executing thread can be used to check if the image load computation is happening on the UI thread (the UI thread’s ID can be got from the CPU Usage analysis from the earlier Execution Profiling session). To keep the UI responsive it is essential to keep the UI thread relatively free, and if you notice that the image load computation is indeed happening on the UI thread, consider moving it to a background thread using the BackgroundCreation option. From XAML, this can be done as shown below:

An exercise to try out at this point it to memory-profile an application that loads in a large image; do you see a spike in memory usage corresponding to the image load marker? What was the duration of the image load? On what thread was it getting loaded? Try using the BackgroundCreation option; now what was the thread on which the image got loaded? Did the duration of the image load change? Let us know your experience.

GC markers

Memory is a limited resource on the phone, and although you are programming in a managed environment where the GC takes care of collecting unused memory you still wield control over allocation and referencing, and must monitor them to trim working set. The GC mediates all allocation requests from your code, and operates on a heap that it has partitioned into 2 regions (generations), with allocations happen in the ephemeral “Gen0” region and objects surviving a GC collection possibly promoted to an older “Gen1” region. The GC markers correspond to collections and a tooltip indicates it’s kind ("ephemeral", "Full"), the point in time when it started, and how long it took to run. An “ephemeral” GC collects only from Gen0 while a “Full” GC collects from both Gen0 and Gen1. Furthermore a “Full” GC can do a “compaction” of the heap if it happens to be significantly fragmented, and even go on to empty the system’s cache of JIT compiled code.

A GC is triggered using several heuristics:

When the amount of managed memory allocated since the last GC is deemed significant (1 MB). This is typically an “ephemeral” GC. However it can turn into a “Full” GC under the following circumstances:

When the managed memory held by objects promoted to Gen1 is deemed significant (5 MB).
When the application’s total memory usage is deemed significant (i.e. close to the maximum allowed by the OS).
When there is significant native-memory pressure - native-memory associated to managed objects (quite common in Silverlight) contributes to total memory usage!

When user code calls System.GC.Collect(). This is always a “Full” GC.
After any resource allocation failure. This is always a “Full” GC.
When the system as whole is running low on free memory. This is always a “Full” GC (that will go all way to emptying the cache of JIT compiled code).

The GC’s decision of deeming a threshold “significant” is based on internal heuristics and mentioned here for informational purposes only. The point to note though is that a “Full” GC is much more performance intensive than an “ephemeral” GC.

Insight

Armed with the graph, the markers and your own intuition, you can now get some insight into your scenario’s appetite for memory:

Does memory usage cross the 90 MB technical certification requirement threshold?
Is memory usage steadily growing?
Do you see a spike in memory usage? Is there a corresponding image load marker? That could be the likely cause (are you using large sized images when a smaller sized image would do?)
Are image loads taking long? (Again, this could be due to using large images).
Are image loads happening on the UI thread (consider moving that to a background thread).
Are there too many GCs? The GC on the Phone is a stop-the-world GC, and therefore the time taken by the GC to run is time taken away from your application! In general strive for little to no GC activity during application startup.
The frequency distribution of the GC markers indicates the rate of memory allocation in the scenario, as well as the time ranges when most GC activity happened. If you are writing a game try to concentrate the GC activity during a level change.
Are there multiple adjacent “ephemeral” GCs? That indicates short lived and/or temporary objects.
Is memory usage not coming down even after one or more “Full” GCs? That is indicative of long lived objects.
Are you explicitly causing “Full” GCs by calling System.GC.Collect()? That is rarely required, and often a bad idea.

An exercise to try out at this point it to profile an application that has various memory allocations patterns; can you correlate the graph and markers with your own intuition? Let us know your experience.

Summary

The graph and markers provide basic information about your application’s memory usage and when combined with your own intuition of the application scenario, be used to infer several characteristics. Further drill down through the various Views can then be used to understand these characteristics better.

Would you like to know more about the Views? Let us know.

Handle Feature Reductions

Mike Battista — Tue, 17 Apr 2012 16:28:00 GMT

The third of the four principles I mentioned in Optimizing Apps for Lower Cost Devices is Handle Feature Reductions.

With the Windows Phone 7.5 Refresh, we refactored the OS in several areas to reduce memory usage and free up more RAM for apps. Part of this exercise included assessing the memory usage of features in the developer platform and assessing which, if any, we could afford to live without.

To free up the most RAM while also being as minimally disruptive as possible, we disabled generic background agents (PeriodicTasks/ResourceIntensiveTasks).

On today’s devices, users can disable background agents for an app manually via the Settings control panel, and the system can disable background agents for an app if the maximum number of supported background agents is exceeded. These conditions are surfaced to the app via an InvalidOperationException which the app must handle. On 256MB devices, the app receives the same InvalidOperationException received in the maximum exceeded case above when trying to schedule a background agent (since the maximum number of supported background agents is 0). This means if an app is written today to handle the maximum exceeded case, it will continue to work on 256MB devices unchanged. Make sure your apps handle this exception path and degrade gracefully when these features are unavailable. This will benefit your app experience both on today’s generation of devices as well as on new lower cost devices. The 256MB emulator introduced in the WPSDK 7.1.1 enables you to easily test this code path.

If you're using PeriodicTasks today to power your live tiles, there are a few options available to you. The first option is to switch to push notifications. A second option is to create ShellTileSchedules to update your tiles with remote images. A third option is to leverage the ShellTile API's from your foreground app to update your tiles whenever the app is launched. While technically the tiles wouldn't be live in this last case, the content would be refreshed, which can give the impression of live tiles. If you allow users to flag content, for instance, you could turn your tiles into a permanent reminder space and update them to reflect the most recently flagged content (or toggle through flagged content with every app launch). If these options aren't feasible for you, then you can still always take advantage of secondary tiles to provide convenient access to deeper experiences in your apps.

In addition to PeriodicTasks and ResourceIntensiveTasks being disabled, the lower cost 7x27a chipset itself has reduced media playback capabilities that may impact playback of some of your content. Attempting to playback unsupported content on the device will result in either (1) a "Sorry, we can't play this file on your phone" error, if played via the MediaPlayerLauncher, (2) a MediaFailed event if played via MediaElement, or (3) suboptimal video playback in some cases. While most apps in our testing during the Windows Phone 7.5 Refresh were not impacted by these reduced capabilities, you may be impacted if you do exceed them. Be sure to understand the new baseline and encode your content to work well across all Windows Phone devices. To conditionally offer higher quality vs. lower quality content depending on the device, leverage the MediaCapabilities.IsMultiResolutionVideoSupported flag. This flag will be false on devices with reduced media capabilities, so be sure to fall back to the baseline specs in this case.

While feature reductions are never ideal, these reductions bring with them an opportunity to reach a large new audience with your apps. Be sure to account for these reductions when targeting lower cost devices to provide the best possible experience to your users.

Adjusting to rapid Marketplace growth—and preparing for the future

Todd Brix — Thu, 12 Apr 2012 20:56:44 GMT

Over the last several weeks some of you have reported slowdowns or delays in the app approval and publishing process. You’ve also said App Hub feels slower. We’ve been investigating, and today I want to explain why this is happening and more importantly what we’re doing about it.

This is the first in a series on our evolving Marketplace service that I plan to write in the months ahead.

It turns out App Hub had become less responsive. And our certification turnaround times have increased—by one business day, on average, from January through late March. Why? In short, growing pains. In three months the number of apps in Marketplace has grown by 60 percent, to nearly 80,000. During that period we’ve also nearly doubled the number of customer stores around the world, so there are now 54 markets to sell your apps. The addition of so many new markets and apps so quickly has slowed our backend systems.

So what are we doing about it? There is a long-term and a short-term plan. We’re already in the process of developing a more robust and scalable Marketplace service that will address current problems and pave the way for the even more rapid growth we’re expecting in the years ahead. But engineering work this significant doesn’t happen overnight. Our plan is to have it complete by late summer.

Until that work is done, we’ll be taking short-term measures to shore up the current service and relieve some of the strain on app certification and publishing. Some of these changes started rolling out about 10 days ago and include:

Adding more server capacity to better handle the increased load.
Streamlining our processes to accelerate the rate at which apps can be ingested, certified, and published.

Unfortunately, you probably won’t see dramatic results until Marketplace’s next generation service is deployed later this summer. But the average app certification wait has now fallen to 2.6 business days, or about a half-day improvement over the last 10 days. (You might experience different wait times depending on the app you’re submitting.)

We’ve also deployed some bug fixes that are helping to improve App Hub responsiveness.

I’m well aware there’s more work to do. But I wanted you to know that we take your feedback and concerns seriously and are attacking the problem on multiple fronts. I’ll have more to say on short-term plumbing upgrades—and planned long-term improvements to Marketplace and App Hub—in future posts. In the meantime, please let me know what’s on your mind.

Reduce Memory Usage

Mike Battista — Tue, 10 Apr 2012 17:16:00 GMT

The second of the four principles I mentioned in Optimizing Apps for Lower Cost Devices is Reduce Memory Usage.

Per certification requirement 5.2.5, apps should not exceed 90MB of memory usage on 256MB devices. When thinking about targeting 256MB devices, your first order of business should be to check whether your apps exceed 90MB today. If they don't, then reducing memory usage is less urgent (but still important as I'll mention later). If they do, then memory tuning will be required.

Leverage the memory profiler and memory-related API's to identify areas of opportunity to improve memory usage in your app. These tools can help you understand pretty quickly what the peak memory usage of your app is as well as what the breakdown of memory usage is across various states of your app.

A general principle to keep in mind is that loading less will result in less memory usage. Loading less could mean loading less data at a time, loading less/smaller content, or fixing leaks which result in more objects residing in memory over the lifetime of your app.

Many apps load and display lists of data (news articles, recipes, events, search results, etc.) often across several pivots on a page. If each of these pivots loads hundreds of list items (usually with images attached to each one), this can result in wasted memory usage particularly if (1) the user never views particular pivots or (2) the user never scrolls below 20 items in any given list. If several pages in your app display lists of data in this way, then memory usage can add up quickly as users navigate through your app. Wherever possible, load less data at a time. Defaulting to a small amount of items in each list and then loading more data as the user requests it can enable you to load the most relevant content in your UI at once (rather than potentially harm user interactivity by loading data in response to user input like pivot selection changes) while keeping your app's memory footprint at a reasonable level.

Asset memory (for images, sound effects, etc.) can quickly add up if you're not careful about how you load assets. The more assets you load into memory at a time, the larger your memory footprint will become. Not only does the amount of content you load affect memory usage, but also does the size of the content. Memory usage of images, for instance, can be approximated by multiplying width * height * bpp (bits/pixel). Higher resolution images will naturally translate into higher memory usage. Loading a 1024x1024 image into memory only to scale it down to a 100x100 container will consume more memory than is necessary. If you're doing this for every image in a list or in a photo gallery feature, then you're using a lot more memory than you need to be. Load thumbnails where it makes sense, and load higher resolution content as the user requests it. If your content is preloaded in your app, make sure that the resolution of the content aligns with the sizes of the containers that will host the content. If you're loading images from a web service, check for options to load lower resolution images instead of higher resolution versions. PictureDecoder.DecodeJpeg can generate thumbnails from high resolution image streams so use this to your advantage. If you're building a game, load assets for the on-screen experience only and flush those assets when they are no longer necessary. Hanging on to assets unnecessarily can result in OOM (out-of-memory) exceptions or general performance problems as the size of your game grows.

Memory leaks can bloat your app footprint and should be identified and addressed. Common sources of memory leaks are building circular navigation loops and failing to deregister event handlers to long-lived objects. Apps that use a home button can result in circular navigation loops which can fill the back stack with redundant page instances. These page instances consume memory and could result in your app crashing due to an OOM (out-of-memory) exception while users navigate through your app. Avoid circular navigation loops by removing home button functionality or by leveraging the new back stack manipulation API’s exposed in Windows Phone 7.5. Neglecting to deregister event handlers to static objects can prevent objects from being reclaimed by the garbage collector. Imagine a search results page where the user navigates back and forth between the details of a search result and the search results page itself. If the details pages hold on to references to long-lived objects, they could continue to reside in memory even after the user navigates back from them. Be sure to deregister event handlers to static objects when they are no longer needed to prevent such leaks. OnRemovedFromJournal is the recommended place to perform this task since it handles page closure both via backward navigations as well as via the back stack manipulation API’s.

Additionally, you should be careful with the use of memory-intensive controls like the WebBrowser and Maps controls. IE can consume a lot of memory when rendering complex websites. This is true even today. The WebBrowser control essentially embeds IE in your app, so if you allow users to navigate to arbitrary complex websites in your app, the memory that IE uses will be attributed to your app. This could result in your app running out of memory if the sum of your app's memory usage plus IE's memory usage exceeds the recommended 90MB limit. If you'd like to use the WebBrowser control, just be mindful of the content that users are allowed to load. If the content isn't very complex, then performance/memory issues shouldn't be a concern. If users can load complex content in the control and your app footprint is already large, you may want to consider using the WebBrowserTask on 256MB devices to reduce the memory usage inside of your app. Similarly, for the Maps control, you may want to leverage the BingMapsTask/BingMapsDirectionsTask to offload map memory to a system process. If a customized map experience is critical to your app, then loading fewer overlays or otherwise simplifying your map experience can help save some memory as well.

As I mentioned before, if you're exceeding 90MB today, then you're likely violating some of these principles and tuning will be required to target 256MB devices. If you're not exceeding 90MB, tuning the memory usage of your app is less urgent but still has its benefits.

To enable apps to use up to 90MB on 256MB devices without jeopardizing the overall integrity of the system, we improved paging support in the OS with the Windows Phone 7.5 Refresh to better manage and distribute memory between background services/processes and the foreground app. While paging is generally abstracted from you, apps may perform slower or glitch occasionally if they push the device to its limits. Apps that use less than 60MB of memory will generally not be impacted by paging. Apps that use between 60MB and 90MB of memory will participate in paging, more so as you approach 90MB. Apps that fall in this range will be more likely to suffer from slower performance or glitches depending on the rest of the activity on the system. The smaller your app's memory footprint, the less likely it will be impacted by this variability.

In addition to having better performance, apps that use less memory are more likely to fast resume. A precondition to fast resume is that the OS has enough free RAM available to keep apps dormant (in memory) in the back stack. On 256MB devices, free RAM is not as abundant as on 512MB devices, so an app that approaches 90MB of memory usage will be tombstoned immediately as it leaves the foreground to free up RAM for the incoming app. Apps that use less memory are more likely to be kept alive in the back stack. It should be noted that the Task Switcher (tap and hold Back to visualize the back stack and quickly navigate to a given app) will always be available on 256MB devices. What we're discussing here is merely the mechanism by which a 7.1 app will fast resume (the existing app instance is returned to the foreground from memory) vs. resume from tombstoning (where the app instance is torn down when it is placed in the back stack, and a new app instance is created when the app returns to the foreground). Apps that use less memory are more likely to benefit from fast resume.

Tuning memory usage is a critical component of optimizing apps for 256MB devices. After becoming comfortable with these guidelines, it will become quite natural for you to build very efficient apps. It's a lot easier to build efficient apps from the beginning than to try and tack on efficiency after you've architected your app, so take comfort in knowing that the knowledge you gain tuning your existing apps (and seeing the results you achieve) will be directly applicable to your future Windows Phone projects. At the end of the day, your users will notice and appreciate the efficiency gains.

Windows 8 and the Windows Phone SDK, pt. 2

Larry Lieberman — Fri, 06 Apr 2012 00:06:53 GMT

Last month, I posted to let developers know that we were aware of some of the challenges that were present in running the Windows Phone SDK on the Consumer Preview of Windows 8. In that post I mentioned that we were working on addressing those problems. My colleague Cliff then followed up with the announcement of the release of the Windows Phone SDK 7.1.1 update, which does unblock the use of our SDK on Win 8, (although not officially supported).

Lots of people are digging into the new development platform opportunities provided by Windows 8, and we understand there are a lot of questions about what they may portend for Windows Phone developers. While we aren’t yet ready to talk about our future plans, we do believe there are certain things we can tell you. In fact, we’ve already talked quite a bit about this at the //BUILD conference last September (see our sessions recorded online at http://wpdev.ms/phoneatbuild).

With regard to existing applications: today’s Windows Phone applications and games will run on the next major version of Windows Phone. Driving application compatibility is a function of Microsoft’s commitment to its developers. Regardless of what we release in terms of new developer features and functionality, we have made a large investment in protecting your existing investments.

We’ve also heard some developers express concern about the long term future of Silverlight for Windows Phone. Please don’t panic; XAML and C#/VB.NET development in Windows 8 can be viewed as a direct evolution from today’s Silverlight. All of your managed programming skills are transferrable to building applications for Windows 8, and in many cases, much of your code will be transferrable as well. Note that when targeting a tablet vs. a phone, you do of course, need to design user experiences that are appropriately tailored to each device.

Microsoft is committed to creating an ecosystem that maximizes your investments. This is not an overnight endeavor, but we’re confident you’ll be pleased with where we’re going with the Windows Phone developer platform. As always, please let us know in the comments, or in our forums, if you have questions or concerns; we can’t answer every question just yet, but I hope we’ve dispelled some of your concerns.

Optimize Startup Time

Mike Battista — Tue, 03 Apr 2012 16:48:00 GMT

The first of the four principles I mentioned in Optimizing Apps for Lower Cost Devices is Optimize Startup Time.

Fast startup is an essential component of any mobile application. It is the first impression a user has of your app and is the first chance you have to either impress or frustrate your users.

If you're wondering just how fast your startup time can get on Windows Phone, use the VS Project Templates as a starting point. Create a new project, deploy it to the device, and experience how quickly the app starts up.

A general principle to keep in mind is that any regressions in startup time from the VS Project Templates are the result of app code delaying the rendering of the first frame. The more app code you can remove or delay before the first frame is rendered, the closer your startup time will match the baseline startup time of the VS Project Templates.

To fully understand the areas of opportunity for improving startup time, it's important to understand the workflow of a launching application.

The App constructor is called in App.xaml.cs.
XAML in App.xaml is parsed.
Application_Launching is called in App.xaml.cs.
The Page constructor of your MainPage is called.
XAML in your MainPage is parsed.
OnNavigatedTo is called in your MainPage.

Once you understand this workflow, it is easy to conclude that any app code or XAML introduced in this workflow will result in startup time regressions from the VS Project Templates.

To minimize the impact of app code in this startup path, you should either remove code from these events or execute code on background threads to unblock the UI thread. Only code executing on the UI thread will have a severe impact on startup performance. Deferring activity to background threads will allow your first frame to render quickly. Use Dispatcher.BeginInvoke from background threads to return back to the UI thread when necessary.

To minimize the impact of XAML parsing on startup time, you can simplify and remove unnecessary XAML from both your MainPage and from App.xaml.

Remove unnecessary namespaces declared in <phone:PhoneApplicationPage>.
1. If your XAML elements aren't prefixed by a declared namespace, then the namespace declaration can be safely removed.
Avoid explicit declarations of default attribute values.
1. Grid.Row="0", for instance, is the default value if Grid.Row is not declared, so just don't declare it.
2. SupportedOrientations="Portrait" and Orientation="Portrait" can be removed as well for portrait only pages since this is the default.
3. Understand default values and remove redundant XAML.
Avoid retemplating controls in App.xaml.
1. Retemplating controls can require complex XAML which is expensive to parse.
2. For Metro-style apps that are theme-aware, this is less of a concern. If you need to retemplate controls to support a branded experience, for instance, then understand what is necessary to override and what can be omitted.
3. If templates are only needed for particular pages, consider moving the custom templates to the pages that need them. This will delay the cost of parsing the XAML until the necessary page is loaded rather than require the cost to be paid at startup.
Normalize Style declarations.
1. If you are consistently setting FontFamily, FontSize, and Foreground in a similar way on several TextBoxes, for instance, then consider using Styles instead.
Simplify page layouts.
1. Don't use nested Grids and StackPanels when one root container would be sufficient to layout your page.
Declare your app bar in code.
1. This will be faster to process than parsing the XAML and is actually the only way to localize your app bar components.

With your first frame rendered quickly, you can then turn your attention to indicating progress to the user while the rest of your content loads. Perceived startup time can go a long way to minimize the amount of frustration content load times can impose on users. The first frame of your app should always include the chrome of your application (system tray, app title, page title, pivot titles, app bar, etc.) as well as a ProgressIndicator to indicate that your content is loading. You'll want to use the ProgressIndicator over other progress bars as (1) the ProgressBar control has known performance issues and (2) the ProgressIndicator will provide the most consistent experience with the rest of the built-in experiences on the phone.

Note that the system tray and app bar are shell components and so will render more quickly than the content in your PhoneApplicationPage. You can take advantage of this to improve perceived startup time even further. You'll notice in the Weather app that the system tray and app bar appear first followed by the rest of the page content. If you're using the system tray ProgressIndicator as recommended above to indicate progress, it will appear as well immediately when the system tray is rendered.

A bonus to using both the system tray and app bar is that these components render together and provide a recognizable chrome for your app while it loads. Many apps hide the system tray and use only an app bar. If you've used these apps, you'll notice often that the app bar renders first before the rest of the content loads. The lack of symmetry in this case introduced by not showing the system tray actually contributes to the perception of lag that the user experiences. By adding the system tray, you can eliminate this perception while also providing a consistent chrome that is recognizable across apps. If you don't want to show the system tray but want to take advantage of it for the reasons mentioned above, show the system tray on launch with an opacity of 0. Using an opacity of 0 means the system tray won't affect your page layout at all. Once the rest of your content loads, you can then hide the system tray if you'd like.

Many apps use a splash screen to solve the perceived startup problem as it is cheap to implement and can promote the brand of the app. While this is a great practice, you may find that after following the guidance above, the splash screen will actually slow down your startup time. Adding a splash screen to the Weather app, for instance, would actually harm its startup performance. With your startup time optimized, assess whether a splash screen is really necessary. Your apps will actually feel more like integrated experiences if they don't use a splash screen, so don't be afraid to leave it off completely. The combination of fast startup time, no splash screen, and extensibility points like secondary tiles will really make your apps shine on Windows Phone.

Globalizing and Localizing a Windows Phone App

Kim Cameron — Mon, 02 Apr 2012 16:05:00 GMT

With Marketplace recently launching in 13 new markets, it's more important than ever to have a globalized, localized app that can reach as many of your customers as possible – but doing so can seem daunting. This blog post seeks to demystify the process and help enable you to write a truly global app.

What is a globalized app?

A globalized app displays things like dates and money in a way that's familiar to a user. If you have a calculator app, some people will expect to see a dollar sign, and others will expect a euro. Or even more important, consider a financial app where a difference between a period in one country/region and a comma in another can change the currency amount by a factor of ten! Dates also differ by country/region – sometimes the month comes before the day, sometimes after. By globalizing your app, it'll feel natural to your customers, no matter where they are.

Globalizing your app is fairly straightforward, and can be done using the CultureInfo class. Check out How to: Build a Globalized Application for Windows Phone for a code example of how to use it.

This blog post will mostly focus on localizing your app – a meaty topic that can be tricky to understand.

What is a localized app?

You can think of a localized app as one that's been translated into one or more languages. There's a few things you can localize in your app:

App Text - menu headings, help text, etc.
App Description - seen in the marketplace
App Title - appears in the application list and on the app title
Application Bar text - if you include an Application Bar

Do I have to localize my app to publish in multiple markets?

No – the two actions are separate. When you submit your app to App Hub, you'll eventually reach a Pricing page where you can choose where your app will be published. You can either select specific markets or 'Worldwide distribution' to include them all.

It's important to understand that this is the only way you can choose where your app is published. Localizing your app is a separate process, and has no impact on where your app ships.

As a note, there are certain countries/regions that have stricter than usual content guidelines. If you decide to publish your app in these marketplaces, make sure you've read requirement 3.10 listed at Content Policies. Also keep in mind that your app must pass certification for all markets you choose – this means that if you choose 'Worldwide distribution', your app must pass certification for all of the supported markets. If you have trouble passing certification for certain markets, an option is to unselect those markets on the Pricing page.

If that's the case, why should I localize my app?

Because you want customers around the world to enjoy – and use – your app.

Let's say you write an app in English, and publish it worldwide. Even if they can physically see your app in their marketplace, someone who can speak and read only Spanish won't be able to understand your app description, and your app likely wont be useful to them. By localizing your app into the Spanish language, that customer would be able to use and understand your app.

When would I not want to localize my app?

There are a couple of cases where it might not make sense to localize:

App Title

Localizing your app title is often a good thing. Say you've created a calculator app, and the title is something obvious like 'Calculator'. By localizing your app title into French (France) and calling it 'Calculatrice', someone in the French marketplace will easily know what your app is.

On the other hand, what if your app title is your company name, such as 'Contoso App'? In this case your name is your branding – you don't necessarily want to localize that into other languages, because you're promoting your app under, and as, your company name.

Language-specific apps

Usually, you'll want to localize your app into multiple languages so you can reach the most customers. But what if, for whatever reason, you decide you only want to ever target a certain group of customers in a certain market? For example, you've written a Spanish news app that you want to market only to Spanish-speaking customers in Spain. In this case, you can save time and energy by not localizing your app into other languages.

That being said, even if your app only supports one language, it's still a good idea to structure your app so that it can be easily localized into other languages in the future.

I'm sold – how do I localize my app?

Localization includes multiple tasks – there are primarily four areas to consider, but we'll mostly focus on localizing app text.

App Title

The app title appears in the application list on the app tile. You can localize your app title by creating a resource-only DLL file for each language. How to: Localize an Application Title for Windows Phone has a full write-up of how to do this.

App Description

You've created an app, you've localized your app text into multiple languages, and you're ready to submit to App Hub. During the ingestion process, App Hub detects which languages you support and will prompt you to enter a language-specific description (and some other metadata) for each language you support.

Be sure that each description matches the language in question, as otherwise you'll fail certification. For example:

Application Bar

When it comes to localization, the Application Bar is handled differently than other controls in your app. If you include an Application Bar in your app, you can localize the text labels on each button. How to: Build a Localized Application for Windows Phone has a code example at the bottom of the page that you can use to do this. Also check out BindableApplicationBar on CodePlex for a third party solution. But before dealing with your Application Bar, you'll need to understand how to localize your app text, which brings us to…

App Text

App text is essentially any text that appears in your app except for the app title or Application Bar text.

How to I localize my app text?

Let's start with the most common case, and then move on to some edge cases. Basically, rather than hard-coding your text into a specific language in XAML, we'll localize your app text by using data binding to obtain the localized values of a word or string from a resource file.

To localize your app text, you'd do the following:

Specify the Neutral Language

Decide the language you want to be the 'default' for your app. This language in Visual Studio is known as the neutral language.

By default, Visual Studio sets the neutral language to the language you choose when installing the SDK.

This is important to understand because App Hub assumes that your neutral language is your default language. If you install the SDK with language set to English, unless you change the neutral language, any app you create will have its neutral language set to English. You need to make sure you change the neutral language to whatever your default language actually is.

This language has to be supported by Windows Phone, meaning it's listed in the Display languages table at Culture and Language Support for Windows Phone. If you choose something else that's not listed at the Culture and Language Support topic, you'll fail certification.

To set the neutral language in Visual Studio, open the project properties, click the Application tab, and then click Assembly Information.

For in-depth coverage on how to change the neutral language, see How to: Build a Localized Application for Windows Phone.

Create Resource Files for Each Language

Create a resource file for each language that you plan on supporting.

You'll first set up your default resource file, AppResources.resx. Your strings in this file have to be the same language of what you chose for your neutral language in step 1, or you'll fail certification.
Every other language besides your default is set up in its own file, labeled with the correct "culture name". For example, if you plan on supporting Spanish (Spain), you'd name your AppResources file 'AppResources.es-ES.resx'. For a full list of culture names you can use, see Culture and Language Support for Windows Phone. To learn more about how culture names are constructed, see the CultureInfo class. Put your language strings into each resource file, translated into that language.

Replace Hard-coded Text with Data Binding

Replace hard-coded text in your app and use data binding to reference values from your resource files.

For in-depth coverage on how to create these resource files, see How to: Build a Localized Application for Windows Phone.

What happens if I don't localize in some languages? Can those users read my app?

Yes. For example, let's say you've written an app in French (France). You want all of your text to be in French most of the time, but there's one or two strings you want to be different just for people with the Spanish (Spain) display language set.

You'd do the following:

Set your neutral language to 'French (France)'
Create a default AppResources.resx file and put your strings, in French, in the file
Create a AppResources.es-ES.resx file (es-ES is the culture name of Spanish (Spain))
Put only the selective strings in there that you want to be different for people with the Spanish (Spain) display language setting

So, what happens if someone with the Spanish (Spain) display language setting opens up your app? What about someone who is using English (United States) or any other display language?

Windows Phone uses the following algorithm to determine what text to display:

What display language is set on the device?
Is there a resource file in the app that matches that display languages?

a. If yes:

A. Is the string in the app located in the resource file?

i. If yes:

I. Show the translated string

ii. If no:

                                      I. 'Fall back' to the default language, in this example, 'French (France)', and show that string instead. In our example, this means that someone with English (United States) set will see the French (France) string, because there is no AppResources.en-US.resx file with a corresponding string.

      a. If no:

               A. 'Fall back' to the default language, in this example, 'French (France)', and show that string instead.

Notice that the same fall back behavior happens if either the resource file is missing entirely, or if the string isn't found in the file.

Based on the above algorithm, someone with the Spanish (Spain) display language set will only see a Spanish string if you've set that string up in the AppResources.es-ES.resx file. If not, you'll see the default (French) equivalent since it's set as the neutral language.

Likewise, if someone has English (United States) or any other display language set, they will only ever see the French strings, since there are no resource files or strings set up for those display languages.

How do I localize for specific regions?

Most languages have multiple regions associated with them. For example, there's the Spanish language, but there's different versions of it depending on region, such as Spain and Mexico. Each display language supported on Windows Phone is a specific combination of language and region, such as Spanish (Spain) or French (France). Where it gets tricky is that a user can control both their display language and the 'Region format' – and Region format shows far more options than the supported display languages.

Since not all strings are the same between language regions, what if you have an app that you want to localize for both the supported display language Spanish (Spain), and the unsupported Spanish (Mexico)?

Technically, you can do this by following steps similar to what you did in the previous example:

Choose Spanish (Spain) for your neutral language since it's the supported display language of the two, and add those strings in your default AppResources.resx file
Create a new resource file for Spanish (Mexico), which has a culture code of es-MX. You'd create AppResources.es-MX.resx, and put your Spanish (Mexico) strings in there.

Note: You can find a large list of culture codes at the National Language Support (NLS) API Reference page.

Seems like it would work, right? The problem is, even if the user has set their Region format to Spanish (Mexico), your AppResources.es-MX.resx file will not load. This is because Windows Phone will look for a resource file that matches whatever the user has selected for their display language, it will not look for a file based on the Region format.

There's a workaround that lets you get around this, you'll just need to add one line of code to the Application_Launching method of App.xaml.cs:

AppResources.Culture = CultureInfo.CurrentCulture;

By using this code, your app will show text from the resource file matching the Region format of the phone, not the display language. Like always, if you don't have a resource file that matches, the fall back process happens.

You can use this workaround to target any language region, as long as a user is able to select it on the settings page.

Make sure you choose the right neutral language!

Even with this workaround, for certification reasons, you need to make sure that the neutral language you choose is a supported display language.

Are regional descriptions supported on App Hub?

Let's say you submit the Spanish app we've been talking about to App Hub – you have Spanish (Spain) set up as your neutral language, you've created a regional file for Spanish (Mexico), and you have the right code in your app so the regional strings will display.

App Hub will only detect one language – Spanish. It maps this language to the display language we support, in this case, Spanish (Spain). You'll notice on App Hub that on the Pricing page, you'll be prompted to add a description and metadata for 'Spanish (Spain)', with no option to input different info for Spanish (Mexico).

How do I localize for a language that isn't supported?

We've talked through localizing for a region that a user can select on the phone, using Region format. But what about cases where you can't select the language or region at all?

For example, you decide to write an Icelandic news reader app. Even though Icelandic isn't officially supported on Windows Phone, the text would display in Icelandic to the user, because the phone supports the right fonts. But your app will fail certification because it must be localized in at least one supported display language. What to do?

There's a workaround for this, too. If you plan on shipping an app that is written in a language we don't support, and it's not available in Region format, you can do the following:

1. Hard code your app to be written in the unsupported language, if you don't plan on supporting more languages in the future. OR, create your default AppResources.resx file and put your unsupported language strings in there, if you plan on supporting more languages in the future or will support additional languages in your submission.

2. Set your neutral language to one of the supported display languages. For example, 'English (United States)'.

3. On App Hub, you will be prompted to input metadata and a description for the neutral language you chose (for the above example, you'll be prompted for English). You must include the following three items in the 'Detailed description' field to pass certification:

A note, such as ‘The language of this application is [unsupported language name]’. This note must be written in the same language as the neutral language. For example, if you chose 'English (United States)' as your neutral language, the note must be written in English (United States). This note must be the first item in the ‘Detailed description’ field.
Your app description, in the same language as the neutral language.
Your app description, in the unsupported language.

At the risk of making things sound even more complicated, you can technically do this one other way. Let's say you already have a news reader app that's localized into many languages, and you want to add support for Icelandic (an unsupported language). You can still do this, you'll just need to set up an additional resource file, using any one of the supported display languages you don't plan on localizing for, and go through the same metadata/description steps on App Hub.

Other localization resources

If you're porting an app from Windows Phone OS 7.0, take a look at this blog post by Mike Francis. He calls out some common errors you might run into when submitting your app to App Hub.
If you're localizing for any English variant, be aware that App Hub refers to them by different names than what's listed in the supported display languages table. See this Support post for more info.
And of course, there are also the MSDN docs.

Marketplace now open in 13 new markets. Are your apps available?

Todd Brix — Wed, 28 Mar 2012 21:55:12 GMT

Marketplace opened for customers today in 13 new markets—a milestone my colleague Mazhar talks about on our consumer blog.

As I’ve written, the news is just another reminder that if you haven’t started cross-submitting your apps for publishing (here's how), now’s the time so phone owners in these new markets can start downloading them.

Before signing off, I wanted to quickly address a question I often get: Why isn’t the developer App Hub expanding at the same pace as the consumer Marketplace? It’s a great question with a complicated answer. Simply put, it takes a lot of legal and engineering work to bring App Hub to new markets. We know you want to see App Hub expand, and we’re working hard to do that while guaranteeing a good experience for you. Setting up registration and payment infrastructure, complying with local laws and regulations, and doing all the other work necessary to ensure you have the tools you need to publish free and paid apps—and get compensated properly—takes time to put into place.

That’s one reason why we created our global publisher program, which lets you publish apps in markets not yet supported by App Hub.

Windows Phone SDK 7.1.1 Update Now Available

Cliff Simpkins — Mon, 26 Mar 2012 17:00:00 GMT

I’m pleased to announce that the Windows Phone SDK 7.1.1 Update is now available for your download; it’s the final version of the CTP we released last month, and enables Windows Phone developers to do two things:

Develop apps that work well on the new 256 MB devices
Use the WPSDK 7.1 to develop on machines running Windows 8

While I’ll circle back to these two points in a moment, I’d like to take a moment and highlight what’s actually in this update.

The 7.1.1 Update is really just that – it’s an update to the existing WPSDK: it doesn’t add much in the way of new features to your WPSDK installation; it updates your existing install to do a few new tricks:

The Visual Studio IDE is patched to enable selection from a list of emulators, and launching it (note that the WPSDK can only support connecting to one at a time, though)
The Windows Phone [512 MB device] emulator image is updated to use build 8773
A second, new emulator device image is included, allowing you to emulate running your app on a 256 MB device
The Microsoft Advertising SDK is updated to the latest version (previously only available as a separate install), which fixes some issues devs were encountering at runtime
IntelliSense now supports specifying the 512 MB device requirement in your manifest file, should you choose to opt your app out from running on the new 256 MB devices
Language support is again consistent both in the IDE (the 7.1.1 Update supports all 10 of the WPSDK 7.1 languages) and in the emulator OS (Malay and Indonesian have been added)

Installing the patch is pretty straightforward process, with a standard three-step install process (accept; install; finish). Because the patch contains two virtual OS images (256 MB device image; 512 MB device image), the patch is pretty beefy (weighing in at just under 300 MB) and it can take time to install as it initializes each image as part of the installation. During the virtual image initialization process, each Windows Phone OS device image is booted up and then paused at the point where the OS is ready to accept an app install; while the initialization process adds some pain up front, it saves you lots of time in the long-run as you don’t have to watch the OS boot-up screen every time you start up the emulator to deploy/debug your code.

On my machine, I was looking at the following screen for about 15 minutes:

After you’ve installed the update, the most noticeable change for most folks is you’ll now see a couple nifty entries in your target selection drop-down box:

Selecting one of these will launch the selected emulator, just as you would expect. Something that you may try to do (well, the first thing I did) is launch your app in the 512 MB emulator and then also launch it also in the 256 MB emulator, so that you can compare your WP app running in both emulators, side-by-side, to compare performance; needless to say, running both emulators at the same time doesn’t work.

Running the Windows Phone SDK 7.1 on Windows 8

As Larry discussed earlier this month, the WPSDK 7.1 didn’t run on the Windows 8 Consumer Preview release. The issue involved three elements: an issue with XNA Game Studio, an issue with the Windows Phone emulator, and a requirement for .NET 3.5. The only remaining blocker for folks successfully developing for Windows Phone on Windows 8 was the emulator. I’m happy to report that this patch removes that final roadblock, and enables our mobile developer community to bring their WPSDK with them as they evaluate the new OS.

There are two caveats I should provide around running the WPSDK 7.1.1 on your Windows 8 machine:

Running the WPSDK 7.1.1 on Windows 8 works, but it is not officially supported until the RTM release of Windows
You are likely to see a performance degradation in the emulator if you have Hyper-V enabled

That being said, this update goes a long way to making it easier for folks to build apps that target both Windows Phone and Windows 8; the WPSDK 7.1.1 runs quite well side-by-side with Visual Studio ‘11’. Particularly with the Consumer Preview out, the ability to run the IDEs side-by-side has been a major request from our developer community. As you are starting to evaluate your strategy of targeting both platforms, we still continue to believe that code reuse via XAML and C#/VB.NET will continue to be your best strategy; and this side-by-side support should help make your life much easier as you can develop and debug side-by-side, as well. Look for information on this topic from Larry in the coming weeks.

Developing Apps for 256 MB Devices

I won’t drill into this topic too much given it has been covered on this blog and others; not to mention you probably already have a good understanding of this topic already if you installed the CTP.

If you haven’t yet looked what to keep in mind as you tailor your apps for 256 MB devices, here are a couple good starting points:

Mike Battista’s Optimizing Apps for Lower Cost Devices blog post
Nokia Dev Wiki’s Best Practice Tips for Delivering Apps to 256 MB Devices article [CRS1]
Inside Windows Phone episode on building for the Windows Phone 7.5 Refresh

As Todd mentioned a couple weeks ago, these new devices, coupled with the 23 new markets that went live last week, account for a nearly 60% increase in total addressable market for your apps. If you haven’t already returned to the App Hub and opted into the new markets, it’s a great time to do so. Just sayin’…

Other Random Tidbits

Can I update my CTP patch or do I have to reinstall?

Yes, in fact you can update without having to uninstall the CTP! The engineering team tells me that you should be able to install the RTW release of this patch (the one I’m announcing here; RTW being ‘Release to Web’ since these tools don’t ever really go to ‘manufacturing’) either on a pristine install of the WPSDK 7.1 or one that had been previously updated using the CTP release of this update (no need to uninstall the CTP version of the 7.1.1 Update before running the RTW patch).

How will I know if I have it installed? And would I uninstall/repair the Update?

An important note to make about this update is that it is, in fact, an update, and not a full installation. As such, you won’t find it listed in the ‘Add/Remove Programs’ area of your Windows developer machine. To locate the installation, you’ll need to go to the ‘View Installed Updates’ section of your Windows Control Panel (screen shot below, for your convenience).

Once in the Installed Updates section of the Control Panel, you’ll see a very very long list (at least my list is lengthy ) of updates that you’ve installed to applications over time. For the WPSDK 7.1.1 update, you’ll find it listed under a variety of headers (because it touches a variety of installed components), but the primary entry will be found under Windows Phone SDK 7.1 (screen shot below again, for your convenience; because I have the English localization, the actual listing is ‘Windows Phone SDK 7.1 – ENU).

It’s also noteworthy to point out that the update’s installation entry uses the KB entry to denote the installation (for English: KB2669191) instead of the actual patch name; and, if you’re comparing notes with me after you’ve installed the 7.1.1 Update for a different locale, you’ll also notice that your KB number is a bit different. Have no fear, everything is good in the world as each patch binary is required to have its own KB entry, and so this is just the way of the world [of patches].

Why is this thing 7.1.1?

Lastly, returning to the ‘what’s in a name’ point; which is invariably the second question I frequently get when discussing this patch. As you look at what is contained in this patch, it really is a patch that updates and improves the capabilities that have previously been delivered in the WPSDK instead of a big release with lots of net-new features. Furthermore, since the OS isn’t incrementing (the OS is still 7.10.8773 under the covers), a couple options had been considered: either the WPSDK 7.1.1 Update and WPSDK 7.1 March 2012 Update. Given the choice between those two options and the feedback we received last year around patch naming (for the WPDT, we released two updates: the Oct 2010 Update and the Jan 2011 Update), we went with WPSDK 7.1.1 Update. We think it clearly communicates what the Update does and it’s relation to the WPSDK 7.1.

All of That Being Said

So, all of that being said, it’s a great update, and well worth the time to download and install. Go grab it, and let us know what you think. If you have any issues, definitely poke your head into the ‘Tools for WP7’ App Hub forum and give our most excellent support guys a holler.