Jeff Wilcox » Windows Phone

Exploring List capacities and growth on the Windows Phone

Jeff Wilcox — Wed, 18 Aug 2010 01:33:15 +0000

Since the generic .NET list (List documentation) is a pretty common data structure found in phone apps, I figured it was worth a few minutes to direct everyone’s attention to how the list and its capacity works on the phone.

Unlike desktop computers, where we’re often dealing with gigabytes of potential memory on a modern operating system, the phone has a number of fun and unique memory challenges that managed code developers should be cognizant of.

If you’re using the generic lists in your Windows Phone application, it’s OK to have a bunch sitting around – their default capacity is actually zero until you add items, but you can alter this behavior.

Constructed capacity is ZERO

When you create a new List, the constructed capacity is 0. This means that the cost of creating a new list of pretty minimal, and creating one does not typically allocate any memory for items.

List myList = new List();
// myList.Capacity == 0

I’ve heard of developers who used to think that at construction the list had a large capacity, and that setting an initial size to a few digit number was a performance win. This is often not the case.

First item brings the capacity to 4 items

The first time that you add a single item (or a few), you’ll notice that the capacity size on the Windows Phone will be 4. This is because the internal default number of 4.

List myList = new List();
// myList.Capacity == 0

myList.Add("hello");
// myList.Capacity == 4

You can add 4 items and the capacity will remain at 4.

List myList = new List();
// myList.Capacity == 0

myList.Add("hello");
// myList.Capacity == 4

myList.Add("world!");
// myList.Capacity == 4

myList.Add("bonjour");
// myList.Capacity == 4

myList.Add("le monde!");
// myList.Capacity == 4

Capacity + 1 grows the capacity exponentially

Once the Count == Capacity, it will exponentially grow the capacity. So the capacity will move from 4 to 8 to 16 to 32, 64, 128, 256, … 1024, and so on.

List myList = new List();
// myList.Capacity == 0

myList.Add("hello");
// myList.Capacity == 4

myList.Add("world!");
// myList.Capacity == 4

myList.Add("bonjour");
// myList.Capacity == 4

myList.Add("le monde!");
// myList.Capacity == 4

myList.Add("a fifth item.");
// myList.Capacity == 8

Clipping the capacity back

If you’re in a situation where you’ve added say 500 names from a database, but the capacity is going to be at 1024 at this point, it might be worth clipping back the capacity. Just call the TrimExcess method on the generic list instance.

myList.TrimExcess();

Initializing to a set size

And if you want to keep from potentially re-allocating memory as you add a lot of items, you can always initialize your list to a smart default number that is much larger than 0 or the default capacity of 4 by providing a size in the constructor.

List myList = new List(900);
// myList.Capacity == 900

Note that the capacity will exactly match the number you provide – it won’t jump up to the next exponent or anything like that. Of course it’s possible that behind the scenes the CLR is allocating a specific type of memory on the heap, but as far as numbers exposed to managed code, this is what you get.

Hope this helps.

Windows Phone performance progress bar update: part 2, remember to turn IsIndeterminate off when not needed!

Jeff Wilcox — Tue, 17 Aug 2010 21:38:28 +0000

Your application’s progress bar should look good, but it should minimize its cost as much as possible to ensure that the available CPU cycles are spent doing your hard work – parsing code, making and processing web requests, and responding to the user’s touch input – all of which happens on the UI thread.

On top of my previous post with a high performance progress bar, I’ve identified uses of progress bars where the IsIndeterminate value is hard-coded to True, and only visibility collapsing is used to show/hide the effect. This actually also has a negative effect on performance when not in use, as the animation defined when IsIndeterminate==True is continuous, forever looping, and going to have some effect on the main user interface thread just computing animation states, properties, and communicating with the core platform.

This came up as I was involved in a code review of a really sweet Windows Phone application that’s under development… Really sweet looking app, world class devs, and quality code – even a nicely architected lightweight model-view design. The application was using multiple indeterminate progress bars, plus my template, but was seeing performance degradation at times of 15-25 fps less than what we would hope for given the concious work to improve perf.

Turns out, having a bunch of progress bars on screen, with Indeterminate mode on, but collapsed, was still having a toll on the frame rates as all animations incur some cost, even if you never see them on screen.

This was an easy fix and I wanted to add this as guidance for having a good experience with progress bars in your phone apps.

1: Use PerformanceProgressBar over the built-in ProgressBar style

Step one: please use my PerformanceProgressBar in your application. It’s very easy to add in about 5 minutes and will pay dividends as your app gets faster. Progress bars as especially important to have low cost as they typically are only shown during potentially expensive operations.

As a recap, the IsIndeterminate=”True”/> control built into the platform has an adverse effect on the user interface thread’s frame rate. This is because it the indeterminate animation is built up of 5 sliding rectangles, built from Slider controls with custom thumbs, and all that work needs to happen five times over every single frame on the UI stack. You can read more about it if you like.

2: Turn off IsIndeterminate when not needed

When looking at this particular app, this was being used to show/hide the indeterminate progress bar. It means that the continuous animations and storyboard is always costing computing resources, so this is not what you want.

Try not to do this:

Now this should have also data bound the IsIndeterminate property. Since there’s a Visibility converter being used already here, this is an easy fix – just directly bind the bool property that the converter was using as an input. So this is additive.

Do try this:

So to properly “turn off” the indeterminate (continuous animation) from the progress bar, whether using the built-in progress bar or the template in my performance progress bar, you want to:

Bind or set the IsIndeterminate property: It should be False when you no longer need the continuous animations
Collapse the Visibility of the progress bar when not needed

Hope this helps.

Blend tip: finding default styles using “Edit a Copy”

Jeff Wilcox — Thu, 12 Aug 2010 00:43:42 +0000

If you’ve spent much time re-templating controls in Silverlight, WPF, or the Windows Phone, it’s clear that sometimes you want to understand the essence of a control through its template… but that XAML doesn’t feel easy to find at first glance.

Silverlight has the default styles and templates published on MSDN… for example, list boxes, content control, and auto complete box. You’ll find nice documentation with the actual template parts, visual states, and then the style that is built into the control library’s Themes\Generic.xaml resource dictionary.

However if you talk to an Expression Blend voodoo master, you will learn that it’s easier than searching on MSDN. Easy as in like 10 seconds.

Here’s a quick tutorial to something that comes up pretty often on discussion lists. I’m going to grab the

Looking ahead: Panorama and Pivot controls for Windows Phone developers

Jeff Wilcox — Wed, 11 Aug 2010 05:10:42 +0000

Apps in Windows Phone 7 make it easy to explore and experience information thanks to two similar navigation controls: panorama and pivot controls. We’ve made it easy for developers to build applications with these experiences by putting these Silverlight controls and associated tooling in the next release of the free developer tools (didn’t make the beta).

The controls are simple & easy to use, but I’ve seen enough rumbling on forums to know that developers are anxious to learn more about their capabilities. In lieu of bits, I’m going to introduce these controls and how they appear from a simple API & XAML perspective, so that you’ll have what you need while planning your apps to know how these experiences can fit into your apps.

Note: this post contains pre-release information and is subject to change at any time.

Panorama control inside of the Visual Studio design surface for the Windows Phone 7.

Learning about the native experience

Since phones are just beginning to trickle out, if you’d like to see what the built-in applications look like, there’s some multimedia up at WindowsPhone7.com.

A panorama powers the people, music + videos, parts of Office, and more. Many of these have a large background and can be explored by panning and flicking between items. When you’re at one item, you will be able to see a little bit of the next item as well – a hint that there’s more to be explored. When you reach the far side of the panorama, you can keep going to wrap around to the beginning again, saving time.

A pivot control powers the e-mail and calendar pages, operating systems, etc. The top of the pivot control shows the headers for all the different items, and you can swipe and pan between the pages. Just like panorama, the control wraps infinitely – so when you reach the final item, instead of having to flick all the way back to the first item, you can just flick once more.

Key Features

Both of the controls are lightweight enough to have great performance, while visually engaging and responsive to touch. Some features:

Simple XAML and application programming interfaces
Standard items controls that feels natural to developers, individual items are built from PanoramaItem and PivotItem content controls
Complete data binding support, content template properties and item container styles
Automatic support for light and dark phone themes
Built-in touch navigation: flicks move quickly, while panning past a threshold and releasing the touch will snap to the next item
Beautiful easing animations for sliding during navigation
Extensibility offered through events, visual states, and the ability to re-template
Great tooling comes standard, including app and page templates

So let’s take a look at the two controls!

Panorama

A visual depiction of the actual contents of the panorama control stretching beyond the physical size of the screen.

From the UI design and interaction guide for Windows Phone 7, the UX folks say:

Unlike standard applications that are designed to fit within the confines of the phone screen, these applications offer a unique way to view controls, data, and services by using a long horizontal canvas that extends beyond the confines of the screen.

…

Elements of a panoramic application serve as the starting point for more detailed experiences.

…

The background image is the lowest layer and is meant to give the panorama its rich magazine-like feel. Usually a full-bleed image, the background is potentially the most visual part of the application.

As all things in design go, what is not on the screen is as important as what is there: the control has a lot of empty space that helps keep the eye focused on the rich experience and data.

Panorama XAML

The Panorama control is placed on pages of your application and accepts a title and a background. Panorama sections are defined by PanoramaItem controls, and each has a header. The Title and Header are easiest to use when you’re just inserting text, but they also have associated HeaderTemplate and TitleTemplate dependency properties for data binding scenarios.

About wide horizontal sections

The panorama allows for special sections that are wider than the screen. Built-in phone hubs often use this for sets of thumbnails, albums, and other displays. If this is the appropriate effect you want for a section, make sure that the PanoramaItem declares that intent by setting the orientation to horizontal. Here’s what the minimized XAML looks like:

Panorama APIs

The key application programming interface for the Panorama builds on top of ItemsControl: so you get the standard items control properties (Items, ItemsSource, etc.), but also additional properties for setting the header, title, and reacting to the currently selected items by the user.

Microsoft.Phone.Controls.Panorama

Dependency Properties

DefaultItem

Sets the default item that moves into display. Allows your application to store the user’s most recently used panorama item to return to it later, just like the native operating system’s built-in hubs.
HeaderTemplate
SelectedIndex
SelectedItem
Title
TitleTemplate

Events

SelectionChanged

Allows the developer to hook up to selection changes (navigations from one panorama item to another).

Microsoft.Phone.Controls.PanoramaItem

Dependency Properties

Header
HeaderTemplate
Orientation

Setting the orientation to Horizontal will allow the item to be of a larger size than the control so that the user can pan and navigate within it. By default, this property is Vertical, which means that panning or flicking should instead bring you to the next panorama section.

Pivot control

The pivot control is a lot like the a tab control, but designed specifically for the phone and touch interaction. The entire pivot control (often the size of the screen and the root element on a page) can be panned, flicked, and manipulated – it’s not just about those headers (though those can be touched to navigate, too).

A simple pivot sample application running in the emulator. Notice that the phone’s theme in the emulator has been set to the light theme, and the control just works without the developer having to do anything.

From the design guidelines document:

A pivot control provides a quick way to manage views or pages within the application. This control can be used for filtering large datasets, viewing multiple data sets, or switching application views. The control places individual views horizontally next to each other, and manages the left and right navigation. Flicking or panning horizontally on the page cycles the pivot functionality.

Pivot XAML

Pivot APIs

Microsoft.Phone.Controls.Pivot

Dependency Properties

HeaderTemplate

A single data template that can be used for all headers in data binding scenarios.
SelectedIndex
SelectedItem
Title
TitleTemplate

Events

LoadedPivotItem
LoadingPivotItem
SelectionChanged
UnloadedPivotItem
UnloadingPivotItem

Microsoft.Phone.Controls.PivotItem

Pivot item is a simple content control and does not have any other special properties.

Visual Studio & Expression Blend Tooling

The tools are fully integrated with the design tools: if you click on an item in XAML, that item will become the one active in the design surface. There’s also an easy way to add additional items, well-defined control property editing, and so this all makes it really easy to get started building immersive apps.

Start with a complete application template

You can start off with an app powered by a panorama or pivot control: File > New Project has built-in templates for these apps.

Add New Pages

When you want to add a new Windows Phone page to your app, you can also add one that’s all ready to go with either a panoramic experience or pivot control, too. Just go to the Project menu and select Add New Item:

This makes it really easy to build out applications as quick as you can click.

Blend Assets

If you need to add either control to an existing app, in Blend you’ll find them in the Assets window, so they’re right where you’d expect to find them when you need ‘em.

Easy property editing

Key properties are easily accessible in the property editor. In this screen capture, you can see how easy it is to change an item to Horizontal mode, or to change the Header property:

Right-click, add new panorama item or pivot item

Integrated into the design surface you can also add extra items to the controls by right-clicking.

Visual Studio design surface

Expression Blend

Other notes

The controls can be found in the Microsoft.Phone.Controls namespace of the Microsoft.Phone.Controls.dll assembly, installed with the official Windows Phone Developer Tools.

As we get closer to launch, I’m sure we will have a good list of caveats and suggestions for the controls. Here are a few things that I had in mind that I wanted to share ahead of time, in case you are designing your application experiences and pages today.

Exposing scrolling data

If you look at applications on the phone such as Mail, you’ll often see that the Pivot control is used to filter and sort data. So when you move to the “unread” pivot item, you have unread mail items; flicking your finger again, you’ll get to “flagged”, listing the messages that you have flagged.

You could easily have hundreds of items in a single pivot item.

If you want to enable scrolling, you must either use a scrolling control like ListBox, or add a ScrollViewer to the pivot or panorama item. Scrolling is not enabled by default. This helps ensure that items are always sized to the parent container like you’d expect in the Silverlight-powered layout system.

Here’s how to add a scroll viewer or list box to a pivot item. Note that you’ll only want to offer a vertical scrolling experience, since horizontal manipulations (pan or flick) are part of the navigation experience with these two controls.

The example uses data binding to the data context, as well as custom-defined data templates from the application’s resources, so don’t just paste it into your app… but you get the idea I hope.

Items control API

These controls do both derive from ItemsControl, but they do have subtle differences.

Both controls

Items can be added in XAML
Items can be added in code, Items.Add(new PivotItem(…)) or Items.Add(new PanoramaItem(…))
ItemsSource can be used for data binding
Do not support alternative types of items: Pivot controls must use PivotItem, Panorama must have PanoramaItem

Differences

Panorama exposes a DefaultItem property
SelectedIndex and SelectedItem are settable in Pivot but not in Panorama

Migration

There are a number of alternative implementations of these controls out there, so for release, we’ll be working to blog guidance on migrating from one of those other experiences to these controls if you would like to.

Stay tuned!

Hope this helps prepare to design and build apps. I’ll be posting again once we release so that you can get started with panorama and pivot control!

TiltContentControl for Windows Phone

Jeff Wilcox — Sat, 07 Aug 2010 23:07:52 +0000

An enjoyable feature found in Windows Phone is a neat interactive effect that our designers have dubbed “tilt”. Tilt gives a little motion to standard controls during manipulations (when they’re being touched).

Although the operating system’s menus and core applications use this effect in many places, applications built for the platform by default don’t pick up any tilt effects. It’s a pretty complex problem to try and make assumptions about which controls and interface elements users would like to have a tilt added to.

We decided for now not to include the tilt effect for Silverlight apps on the phone, which is why you don’t see the tilt in the beta of the phone developer tools.

It’s a subtle effect, but you do see it when you use a device. It lets you know something’s responsive. So, if you click on the N in New Orleans in a list box like the one I have in a sample below:

Tilt in effect: the New Orleans entry has been touched and has tilted in reaction to the manipulation. When the manipulation is done, it will move back to its standard position.

Introducing Luke’s TiltContentControl

So one of our excellent devs on the Silverlight mobile team, Luke Longley, went ahead and coded up this control we’re calling TiltContentControl. I’m sharing this control on his behalf today as we wanted to get this out for people to experiment with.

This lets you wrap any element that you’d like to have receive a tilt-like experience. You can also add it to data templates or re-template controls like Button to make it easy to apply throughout your app in a standard way.

ContentControl vs Attached Property

Since this control derives from ContentControl, it is designed to wrap a single control that should have the effect. It can also be placed inside of custom templates and styles to make it easy to apply, instead of having to manually wrap all controls you’d like to tilt enable with the control.

Another approach other than using a wrapping content control is to use an attached property. Peter Torr from the Windows Phone application platform team created an implementation of tilt that does just that.

Both these implementations are slightly different, so check them both out – they’re interesting lessons in the platform. This content control responds to manipulation deltas, so you’ll get a very similar effect to that of the rest of the phone controls while your finger is still on the screen.

Adding the control to your project

As a simple derived content control, you can add TiltContentControl to your project just by dropping this single C# file into your project.

TiltContentControl.cs (code also duplicated below)

How to use the control within your project

So here’s how to use it in-place:

Here’s how to re-template something to use it – in this case I’m retemplating Button. You could put this style one time in your project, in App.xaml or a resource dictionary, then easily use it wherever without having to actually wrap the individual control instances.

So to have a Button use it, just set the style to the static resource:

The XML namespace I’m using (this should go at the top of any pages or resource dictionaries you place the tilt content control in):

xmlns:unofficial="clr-namespace:Microsoft.Phone.Controls.Unofficial"

Now in the sample image above, I show a ListBox with items that all have the tilt effect enabled. Here’s how you can do the same by adding the control within a data template and setting that to the ItemTemplate of your list box. I also have ended up using ItemContainerStyle to make the entire width of the item tilt-enabled:

I’m sure there are other ways to do this, too. Which type of solution is really up to you.

Creating and using a custom easing function

The easing function defined for the tilt up operation is not a standard one found in Silverlight. As a result, the choice is either to implement a custom easing function in C#, or to find a similar one in the platform.

Here’s what the UX people say:

Silverlight’s easing functions take in a normalized time value from 0 to 1. This means that if the double animation is really one second-long duration, then at half a second (500ms) the normalized time value will be 0.5, and at one second, 1.0. But never outside the range of [0, 1].

To implement a custom easing function, you just create a new class that derives from EasingFunctionBase from the System.Windows.Media.Animation namespace. The tilt control has this as a nested private class, since we aren’t exposing it for use elsewhere.

/// 
/// An easing function of ln(t+1)/ln(2).
/// 
private class LogarithmicEase : EasingFunctionBase
{
    /// 
    /// Constant value of ln(2) used in the easing function.
    /// 
    private const double NaturalLog2 = 0.693147181;

    /// 
    /// Overrides the EaseInCore method to provide the logic portion of
    /// an ease in.
    /// 
    /// Normalized time (progress) of the
    /// animation, which is a value from 0 through 1.
    /// A double that represents the transformed progress.
    protected override double EaseInCore(double normalizedTime)
    {
        return Math.Log(normalizedTime + 1) / NaturalLog2;
    }
}

We’ve only overwritten the EaseIn method here. Pretty simple, you don’t need to be a mathematician!

In code, you can just use an instance of the LogarithmicEase type now for any animation’s EasingFunction value. You’ll see this implementation has a single static readonly instance of it that’s reused every time.

Quick perf lesson #1: Avoid custom easing functions as they have a negative performance implication

Custom easing functions are called per frame on the user interface thread. This is a much more expensive operation than a standard easing function which is implemented in native code by Silverlight, and able to run in the compositor thread (previously known as the render thread or independent animations thread).

The callback into C# is time that the user interface thread could have spent handling operating system events, handling input, letting property change notifications propagate, or the layout system to perform a full measure-arrange pass.

We’ve decided to use a custom easing function because the platform’s designers have explicitly designated this as the tilt-up animation’s ease.

Quick perf lesson #2: Store a single static instance of property paths when creating animations in code

If you look through the code, you’ll see that the storyboard and double animations are created in code. To minimize the additional number of new object allocations, the code has 3 static readonly properties for the paths.

/// 
/// Single instance of the Rotation X property.
/// 
private static readonly PropertyPath RotationXProperty = new PropertyPath(PlaneProjection.RotationXProperty);

/// 
/// Single instance of the Rotation Y property.
/// 
private static readonly PropertyPath RotationYProperty = new PropertyPath(PlaneProjection.RotationYProperty);

/// 
/// Single instance of the Global Offset Z property.
/// 
private static readonly PropertyPath GlobalOffsetZProperty = new PropertyPath(PlaneProjection.GlobalOffsetZProperty);

This decreases the number of objects that have to be allocated, which decreases the cost of garbage collection. It’s probably a minimal improvement, but it’s something to think about.

Does this tilt exactly match the OS?

No, the effect doesn’t completely match.

The phone has an additional feature, a “global camera,” that I’m told takes into account the element’s position on screen. The global camera effect is why buttons near the bottom of the screen have an exaggerated tilt effect.

You won’t get that specific effect from this Silverlight implementation today. So this Silverlight implementation is more simple, but in my mind still achieves the goal of offering the tilt effect on elements.

We’ll see how people like it and maybe we’ll find a way to match the platform even closer in the future.

Workaround note for beta tools developers

There was a bug in the beta release of the platform where objects within a perspective transform that used bitmap caching would not necessarily react to the changing perspective. We’ve since fixed this internally.

To enable this file to be relevant to developers today (using beta tools) as well as in the future, I’ve coded in a workaround for beta tools users.

If you are using Beta tools, you should uncomment the #define statement near the top of the file (line 13 I think).

If you’re using post-beta tools, you can hopefully just use the file as-is.

Full implementation of TiltContentControl.cs

Here’s the full implementation, you can just drop this into your phone project:

// (c) Copyright Microsoft Corporation.
// This source is subject to the Microsoft Public License (Ms-PL).
// Please see http://go.microsoft.com/fwlink/?LinkID=131993 for details.
// All other rights reserved.

// ---
// Important Workaround Note for developers using the BETA:
// There is a workaround in code that removes any CacheMode from the content of
// the control. It works around a platform bug that is slated to be fixed for
// release.
//
// If you are using the beta tools, remove the comment below:
// #define WORKAROUND_BITMAP_CACHE_BUG
// ---

using System;
using System.Diagnostics;
using System.Windows;
using System.Windows.Controls;
using System.Windows.Input;
using System.Windows.Media;
using System.Windows.Media.Animation;

namespace Microsoft.Phone.Controls.Unofficial
{
    /// 
    /// A content control designed to wrap anything in Silverlight with a user
    /// experience concept called 'tilt', applying a transformation during
    /// manipulation by a user.
    /// 
    public class TiltContentControl : ContentControl
    {
        #region Constants
        /// 
        /// Maximum angle for the tilt effect, defined in Radians.
        /// 
        private const double MaxAngle = 0.3;

        /// 
        /// The maximum depression for the tilt effect, given in pixel units.
        /// 
        private const double MaxDepression = 25;

        /// 
        /// The number of seconds for a tilt revert to take.
        /// 
        private static readonly Duration TiltUpAnimationDuration = new Duration(TimeSpan.FromSeconds(.5));

        /// 
        /// A single logarithmic ease instance.
        /// 
        private static readonly IEasingFunction LogEase = new LogarithmicEase();

        #endregion

        #region Static property instances
        /// 
        /// Single instance of the Rotation X property.
        /// 
        private static readonly PropertyPath RotationXProperty = new PropertyPath(PlaneProjection.RotationXProperty);

        /// 
        /// Single instance of the Rotation Y property.
        /// 
        private static readonly PropertyPath RotationYProperty = new PropertyPath(PlaneProjection.RotationYProperty);

        /// 
        /// Single instance of the Global Offset Z property.
        /// 
        private static readonly PropertyPath GlobalOffsetZProperty = new PropertyPath(PlaneProjection.GlobalOffsetZProperty);
        #endregion

        /// 
        /// The content element instance.
        /// 
        private ContentPresenter _presenter;

        /// 
        /// The original width of the control.
        /// 
        private double _width;

        /// 
        /// The original height of the control.
        /// 
        private double _height;

        /// 
        /// The storyboard used for the tilt up effect.
        /// 
        private Storyboard _tiltUpStoryboard;

        /// 
        /// The plane projection used to show the tilt effect.
        /// 
        private PlaneProjection _planeProjection;

        /// 
        /// Overrides the method called when apply template is called. We assume
        /// that the implementation root is the content presenter.
        /// 
        public override void OnApplyTemplate()
        {
            base.OnApplyTemplate();
            _presenter = GetImplementationRoot(this) as ContentPresenter;
        }

        /// 
        /// Overrides the maniupulation started event.
        /// 
        /// The manipulation event arguments.
        protected override void OnManipulationStarted(ManipulationStartedEventArgs e)
        {
            base.OnManipulationStarted(e);

            if (_presenter != null)
            {
#if WORKAROUND_BITMAP_CACHE_BUG
                // WORKAROUND NOTE:
                // This is a workaround for a platform bug related to cache mode
                // that should be fixed before final release of the platform.
                UIElement elementContent = _contentElement.Content as UIElement;
                if (elementContent != null && elementContent.CacheMode != null)
                {
                    elementContent.CacheMode = null;
                }
#endif
                _planeProjection = new PlaneProjection();
                _presenter.Projection = _planeProjection;

                _tiltUpStoryboard = new Storyboard();
                _tiltUpStoryboard.Completed += TiltUpCompleted;

                DoubleAnimation tiltUpRotateXAnimation = new DoubleAnimation();
                Storyboard.SetTarget(tiltUpRotateXAnimation, _planeProjection);
                Storyboard.SetTargetProperty(tiltUpRotateXAnimation, RotationXProperty);
                tiltUpRotateXAnimation.To = 0;
                tiltUpRotateXAnimation.EasingFunction = LogEase;
                tiltUpRotateXAnimation.Duration = TiltUpAnimationDuration;

                DoubleAnimation tiltUpRotateYAnimation = new DoubleAnimation();
                Storyboard.SetTarget(tiltUpRotateYAnimation, _planeProjection);
                Storyboard.SetTargetProperty(tiltUpRotateYAnimation, RotationYProperty);
                tiltUpRotateYAnimation.To = 0;
                tiltUpRotateYAnimation.EasingFunction = LogEase;
                tiltUpRotateYAnimation.Duration = TiltUpAnimationDuration;

                DoubleAnimation tiltUpOffsetZAnimation = new DoubleAnimation();
                Storyboard.SetTarget(tiltUpOffsetZAnimation, _planeProjection);
                Storyboard.SetTargetProperty(tiltUpOffsetZAnimation, GlobalOffsetZProperty);
                tiltUpOffsetZAnimation.To = 0;
                tiltUpOffsetZAnimation.EasingFunction = LogEase;
                tiltUpOffsetZAnimation.Duration = TiltUpAnimationDuration;

                _tiltUpStoryboard.Children.Add(tiltUpRotateXAnimation);
                _tiltUpStoryboard.Children.Add(tiltUpRotateYAnimation);
                _tiltUpStoryboard.Children.Add(tiltUpOffsetZAnimation);
            }
            if (_planeProjection != null)
            {
                _width = ActualWidth;
                _height = ActualHeight;
                if (_tiltUpStoryboard != null)
                {
                    _tiltUpStoryboard.Stop();
                }
                DepressAndTilt(e.ManipulationOrigin, e.ManipulationContainer);
            }
        }

        /// 
        /// Handles the manipulation delta event.
        /// 
        /// The manipulation event arguments.
        protected override void OnManipulationDelta(ManipulationDeltaEventArgs e)
        {
            base.OnManipulationDelta(e);
            // Depress and tilt regardless of whether the event was handled.
            if (_planeProjection != null)
            {
                DepressAndTilt(e.ManipulationOrigin, e.ManipulationContainer);
            }
        }

        /// 
        /// Handles the manipulation completed event.
        /// 
        /// The manipulation event arguments.
        protected override void OnManipulationCompleted(ManipulationCompletedEventArgs e)
        {
            base.OnManipulationCompleted(e);
            if (_planeProjection != null)
            {
                if (_tiltUpStoryboard != null)
                {
                    _tiltUpStoryboard.Begin();
                }
                else
                {
                    _planeProjection.RotationY = 0;
                    _planeProjection.RotationX = 0;
                    _planeProjection.GlobalOffsetZ = 0;
                }
            }
        }

        /// 
        /// Updates the depression and tilt based on position of the
        /// manipulation relative to the original origin from input.
        /// 
        /// The origin of manipulation.
        /// The container instance.
        private void DepressAndTilt(Point manipulationOrigin, UIElement manipulationContainer)
        {
            GeneralTransform transform = manipulationContainer.TransformToVisual(this);
            Point transformedOrigin = transform.Transform(manipulationOrigin);
            Point normalizedPoint = new Point(
                Math.Min(Math.Max(transformedOrigin.X / _width, 0), 1),
                Math.Min(Math.Max(transformedOrigin.Y / _height, 0), 1));
            double xMagnitude = Math.Abs(normalizedPoint.X - 0.5);
            double yMagnitude = Math.Abs(normalizedPoint.Y - 0.5);
            double xDirection = -Math.Sign(normalizedPoint.X - 0.5);
            double yDirection = Math.Sign(normalizedPoint.Y - 0.5);
            double angleMagnitude = xMagnitude + yMagnitude;
            double xAngleContribution = xMagnitude + yMagnitude > 0 ? xMagnitude / (xMagnitude + yMagnitude) : 0;
            double angle = angleMagnitude * MaxAngle * 180 / Math.PI;
            double depression = (1 - angleMagnitude) * MaxDepression;
            // RotationX and RotationY are the angles of rotations about the x-
            // or y-axis. To achieve a rotation in the x- or y-direction, the
            // two must be swapped. So a rotation to the left about the y-axis
            // is a rotation to the left in the x-direction, and a rotation up
            // about the x-axis is a rotation up in the y-direction.
            _planeProjection.RotationY = angle * xAngleContribution * xDirection;
            _planeProjection.RotationX = angle * (1 - xAngleContribution) * yDirection;
            _planeProjection.GlobalOffsetZ = -depression;
        }

        /// 
        /// Handles the tilt up completed event.
        /// 
        /// The source object.
        /// The event arguments.
        private void TiltUpCompleted(object sender, EventArgs e)
        {
            if (_tiltUpStoryboard != null)
            {
                _tiltUpStoryboard.Stop();
            }
            _tiltUpStoryboard = null;
            _planeProjection = null;
            _presenter.Projection = null;
        }

        /// 
        /// An easing function of ln(t+1)/ln(2).
        /// 
        private class LogarithmicEase : EasingFunctionBase
        {
            /// 
            /// Constant value of ln(2) used in the easing function.
            /// 
            private const double NaturalLog2 = 0.693147181;

            /// 
            /// Overrides the EaseInCore method to provide the logic portion of
            /// an ease in.
            /// 
            /// Normalized time (progress) of the
            /// animation, which is a value from 0 through 1.
            /// A double that represents the transformed progress.
            protected override double EaseInCore(double normalizedTime)
            {
                return Math.Log(normalizedTime + 1) / NaturalLog2;
            }
        }

        /// 
        /// Gets the implementation root of the Control.
        /// 
        /// The DependencyObject.
        /// 
        /// Implements Silverlight's corresponding internal property on Control.
        /// 
        /// Returns the implementation root or null.
        public static FrameworkElement GetImplementationRoot(DependencyObject dependencyObject)
        {
            Debug.Assert(dependencyObject != null, "DependencyObject should not be null.");
            return (1 == VisualTreeHelper.GetChildrenCount(dependencyObject)) ?
                VisualTreeHelper.GetChild(dependencyObject, 0) as FrameworkElement :
                null;
        }
    }
}

Namespace: Microsoft.Phone.Controls.Unofficial

One change since the ProgressBar template I blogged about: I’m using the namespace Microsoft.Phone.Controls.Unofficial now. Unsupported sounded harsh; obviously these types of controls will be improved upon over time and they’re out in the public, so either on StackOverflow.com or Twitter or whatever there will be some place for people to talk about what’s good and bad with these controls.

Hope this helps.

Creating high performance Windows Phone apps – THE WHITEPAPER

Jeff Wilcox — Sat, 07 Aug 2010 18:53:24 +0000

Our perf whitepaper has made it out in the wild, please take a look at “Creating high performance Silverlight applications for Windows Phone” – the download includes not only the whitepaper, but also sample applications.

Some of the features it covers:

Compositor thread and user interface thread
Frame rate counter & cache visualizations
Cache mode
Fill rate concepts
Loading images larger than 2000 x 2000
Navigating into pages in other assemblies

Some tips it includes:

Using Opacity = 0 to hide objects and reduce the fill count
Using images over XAML for some graphics that don’t need to be vectors
Minimizing the code in constructors and initialization code paths
Using Dispatcher.BeginInvoke at startup to get initialization work happening quickly, but after rendering the screen
Using async

It includes sample apps that demonstrate concepts:

Examples about fill rate
How to hide objects using Opacity = 0
Loading large images
Per-frame callback implications
How to split code across DLLs to improve app startup time

This was created by performance experts on the phone and Silverlight teams, and even I’ve even contributed to the whitepaper – the frame rate counters image from my blog is in there.

I’ll also be covering many of these topics in depth on this blog going forward.

Hope this helps.

A high performance ProgressBar for Windows Phone

Jeff Wilcox — Mon, 02 Aug 2010 12:01:10 +0000

The ProgressBar template for Silverlight that is built into the Windows Phone today looks beautiful but comes at a cost to performance in indeterminate mode (the animating dots that often indicate loading during an operation of unknown time).

Here I offer a workaround which is identical in looks, but with excellent performance. It uses the render thread exclusively for animation, instead of the UI (user interface) thread. I’ve touched on this previously in a post of performance and frame rate counters for the Windows Phone.

8/17/10 Update

A quick update since I originally posted this on August 2nd: you should also take care to toggle the IsIndeterminate property through binding or code when not needed, on top of collapsing the visual of the control. This was identified through app code reviews and is another important part of speeding up your apps. More info in my 8/17 post.

The original post follows:

Moving the indeterminate animation to the render thread frees up the UI thread to handle application events, messages, interact with the networking stack, and otherwise keep the app running smoothly.

Using the PerformanceProgressBar in your app

This workaround requires you to add a simple control (a .cs file) to your Windows Phone project, as well as set the ProgressBar style to the alternative, and should take about 5 minutes. This is what you want if you want to give your users that “progress indicator” visual style while data or information is loading, and using this version will let the app continue to look responsive to your customers.

Get the code

Download and add the source file RelativeAnimatingContentControl.cs to your project (it is open source)

Add the PerformanceProgressBar style

Open the App.xaml file in your Windows Phone project (or generic.xaml if a composite control library). Next, add the following XMLNS declaration at the top element – this is important as it tells the parser to look in your project for the code you added above:

xmlns:unsupported="clr-namespace:Microsoft.Phone.Controls.Unsupported"

Now, go into the Resources section of the file and add this style (you can also download as PerformanceProgressBarStyle.txt):

Add this alternate ProgressBar control style everywhere

Now, whenever you or your designers place a ProgressBar in your app, set the style to be PerformanceProgressBar and it will be picked up from the App.xaml.

In XAML:

In code:

Style style = (Style)App.Current.Resources["PerformanceProgressBar"];
if (style == null) { throw new InvalidOperationException("The style was not found."); }
ProgressBar bar = new ProgressBar
{
    IsIndeterminate = true,
    Style = style,
};
LayoutRoot.Children.Add(bar);

That’s it! Read on if you want to learn about how this all actually works, why it isn’t built into the system (there’s a good reason), and just general info about the performance-improving workflow I went through.

The back story

When people started seeing poor performance on applications that were using indeterminate progress bars, it was a stumper. I’m pretty sure there were hallway conversations including: “what the heck? how’s this so bad? there’s nothing happening here – it’s just animating rectangles! WTF? is there a bug in the animation system? what’s really the issue? this is a super simple animation! fix it!”

I jumped in and started looking at the root of the potential performance problem. It was definitely interesting because the emulator experience was pretty good (though still heavy in the UI thread), but once these same apps were on real developer devices, the issue manifested. The emulator is just that – it emulates, so there will be differences.

Working to unpeel the onion and diagnose the indeterminate ProgressBar as the root of the performance issue, some of what was tried:

Noting applications were sluggish on hardware devices when a progress bar would appear in indeterminate mode
Removing networking calls, commenting out any data parsing, and cutting out application logic – leaving just simple states and the progress bar
Building a repro application with an indeterminate ProgressBar, the UI thread was still stressed according to the frame rate counters
Adding several progress bars compounded the problem
Trying to understand why the render thread frame rate was doing fine (above 50 fps), but the UI was below 10 fps at times
Reviewing the default control style and template’s visual state animations and code to look for complex animations or opportunities for improvement (BitmapCache was not being used for instance, but it wasn’t a big enough difference to explain the cause)
Identifying that the method used to move the small rectangles on the screen by animating the Value property of Slider would cause per-thread callbacks to the property change handler of the Slider control, forcing the animations to the UI thread instead of the independent animations render thread

So there, the issue was in the animations and underlying template for the indeterminate ProgressBar and its use of Slider controls.

Why Slider is in the template

The default style and control template for the Windows Phone was created to meet the UX & user interface guidelines that the Windows Phone team has created. A consistent and good-looking set of controls is an important part of the platform and so the progress bar has a very slick appearance.

In “indeterminate” mode, five small rectangles in the user’s accent color, that move into the screen one just briefly after another. It’s mesmerizing and more fun than the standard Silverlight one you may have seen on the web before.

Trouble is, the animation defined for the rectangles is impossible to declare in XAML markup – there’s no way to provide an animation frame description which says “at this keyframe, the rectangle should be positioned 1/3 of the width of the control”: Silverlight happily will let you define a specific fixed position (like translating 75 pixels), but not a variable or ratio-based size for the animation.

But wait! There’s another control in the core platform that can do this visual concept.

Enter Slider. Slider is a nice control because it calculates a position based on the width and effectively a percent (the Value divided by the Maximum provides the ratio), then uses that to update the Thumb/Track template part of the control.

Here’s some short XAML that helps demonstrate how this ratio works for offsetting the thumb:

And you’ll see that even though the Value is 30 in each case, the Sliders are different sizes based on their parents’ size: effectively allowing for moving the thumb based on a ratio applied to the actual width:

This let the designers create the ratio-based animation for the rectangles (thumbs of a slider) that makes them smoothly move in thirds. The rectangles enter to one third the width of the screen while fading in, then move at a different rate from 1/3 to 2/3 the width of the screen, and then fly and fade out.

So indeterminate mode progress bar was destined to use a set of Sliders to move those rectangles. The progress bar defines 5 Slider controls.

Here’s a snippet from the default style template in the beta release of the Windows Phone developer tools:

The static style resource defines a custom look for the Slider to create an accent colored rectangle, instead of looking like the normal phone Slider control you may place on the page.

Nesting controls within templates is how Silverlight was designed to work, so it isn’t the composition of controls that necessarily degrades performance in this case (though simplicity is always key, especially on a device that has very different computing properties than your PC).

Now here’s a small chunk of the Storyboard animation code that animates the Slider instances. Note the Value target property:

And now we are finally to the root of the problem: the trouble is that Value is a DependencyProperty defined by the nested Slider controls, and it has some performance implications.

Animating the Slider::Value property means the animation happens on the UI thread (not good!)

The Value DependencyProperty of Slider comes from its parent class, RangeBase. The declaration for the property shows that there is a property change callback, OnValueChanged, that is called whenever the property changes, so in our case, when the progress bar animations animate the Slider.Value target property – which will be every single frame, it’s an animation.

The platform allows dependency properties to optionally have these callbacks to perform logic and states changes, validation, and other operations. In real world control development, I’d guess that it’s 50/50 whether a property has that callback. So it’s not a design flaw of a property, they are there for a good reason, but can have unintended consequences to performance, especially once you start doing wild things with those properties.

If you open up Reflector to look at Slider, you’ll see a call to UpdateTrackLayout. This is the meat of the control that updates the size of the template’s special Grid columns or rows to simulate the movement of the Slider.

The callback will always happen on the UI thread, as all core UI interactions on the platform need to happen on the UI thread, and the runtime guarantees this.

That means that the five animations for the value property cannot happen on the separate render thread.

What needs to change in ProgressBar? Should we build our own?

So maybe the default style on the phone is a little “heavy”; but the ProgressBar control implementation is fine. There are no code fixes or changes required to the actual control.

I recommend just using a special C# file and re-templating the standard ProgressBar, though it would be easy enough to package this up into an independent control library or ship with some kind of toolkit. We’ll see what people do.

Why can’t MSFT update the progress bar in the platform?

I’m really only talking here about the beta version of the developer tools for the Windows Phone.

In my opinion, changing this in the platform while matching the Windows Phone user interface guidelines is a big technical challenge (again, the lack of ratio-based translation key frames in Silverlight), so in the meantime, please use mine – I’ll make sure it continues to work through the release of the phone and will blog and tweet updates as necessary.

This could change in the future, but since this workaround doesn’t change the ProgressBar control itself, it is easy enough to pull out the workaround – just remove the custom Style setter!

Shouldn’t everything just be fast and have great performance anyway?

We all wish. There is a lot of give and take in application development and especially tweaking for perf.

On the Silverlight mobile team we’re very serious about performance, but don’t expect performance to be free: we’re doing our part to drive performance improvements through the product, but we need application developer’s help as well to optimize their applications for the phone experience.

What’s this RelativeAnimatingContentControl I added to my project?

I designed this custom content control that makes adjustments to the storyboards of the visual states attached to it. When the layout is updated (i.e. there is a known size), the control will go through the storyboards and update the properties that are designed to be “relative”, using its initial ratio.

The control has some magic number trickery to accomplish this, and only works with double animation elements and double animations with key frames. Instead of hard-coding numbers and using that, the control interprets the initial values of the animation properties as a percentage. If you’re interested in the inner workings, let me know and I am happy to post more about it. Quickly, if a From, To, or keyframe Value has an initial value ending in “.1” (such as 33.1, or 75.1, or 0.1), the property is interpreted as a percentage ratio based on the width of the control – 0 to 100. The .1 is stipped off. If the magic number decimal is instead .2, like 50.2, then the height of the control is used for the calculation instead. The idea is that a designer and coder work to define the special template with these magic numbers, but it doesn’t keep the designer from defining other animations that are not ratio-based.

Since the control must be the root of the ProgressBar template, it is an opt-in model and won’t affect any other uses of ProgressBar either.

This is all to work around the lack of ratio animation properties in Silverlight, and it’s a pretty good solution, magic numbers aside. I feel a little sick about the magic numbers part. I’m sharing this feedback with the team of course and we’ll see what the future holds.

Why’s the control in the Microsoft.Phone.Controls.Unsupported namespace?

I wanted to make it clear to everyone that this is not an official Microsoft control. It’s a way to work around a limitation in Silverlight, and probably not a good general-purpose solution.

That said, the namespace probably should be JeffWilcox.Controls.Supported: I’m always happy to look at the feedback I get on these posts and update the content to be relative and address issues.

What changed in the PerformanceProgressBar style

You’ll see that the ProgressBar style looks very similar. Here are some of the differences:

The root of the control template is this special RelativeAnimatingContentControl. The control updates the visual state storyboards when the size of the control changes, giving the animations a ratio to the size of the control based on the initial value stored in the storyboard.
The 5 Slider controls have been replaced by 5 simple Rectangle instances
The rectangles have BitmapCache turned on
Each rectangle has a defined TranslateTransform which is used to move the rectangle instead of the UI animation from the standard (which animated the Value property, on the UI thread, which then made the item move after a layout pass with the underlying grid in the template)

So here’s the part with the rectangles:

And here’s some of the animation code. Note the “magic” numbers ending in 0.1 – those tell the system it’s a ratio based on the width of the control. A hacky overload of a property, but something that can work and give us a real perf win today!

Feedback

I hope everyone uses this ProgressBar to make their apps rock. Remember that one key to great perf is to let the UI thread “breath”: don’t bog it down, let it do its job, and especially in loading, downloading and parsing scenarios, really important to use a progress bar that won’t inhibit the progress.

This is pre-release information and is subject to change. I’ll try and keep the post updated. Let me know how it goes!

Frame rate counters in Windows Phone

Jeff Wilcox — Mon, 26 Jul 2010 16:29:25 +0000

While developing Windows Phone applications, it’s good to have some simple but important performance tips and tricks in your back pocket. Here’s a quick reference to enabling frame rate counters plus an overview of what the values represent.

Enable frame rate counters in code

In your App.xaml.cs or MainPage.xaml.cs, in the constructor, set the host property to true for this diagnostic mode:

Application.Current.Host.Settings.EnableFrameRateCounter = true;

Make sure the System Tray is not visible

By default in the beta tools, the MainPage.xaml sets the system tray to be visible. When this happens, the frame rate counters are hidden by the operating system shell.

Method 1: XAML

The default page template includes an XMLNS declaration for “shell”, and has this in the phone application page constructor:

shell:SystemTray.IsVisible="true"

Just change the IsVisible property to False:

shell:SystemTray.IsVisible="false"

Method 2: Code

Microsoft.Phone.Shell.SystemTray.IsVisible = false;

In a future release of the phone tools, this is actually going to be less of an issue, as the counters will actually be right-aligned on the screen instead.

Adding a simple check box to toggle the counters

A lot of app developers add a check box to debug builds that lets them toggle this sort of diagnostic display. In one of our ‘Scenarios’ test applications, we have a check box on the first page, and in XAML it connects the Checked and Unchecked events to this method.:

private void FrameRateCounters_Checked(object sender, RoutedEventArgs e)
{
    var checkbox = (CheckBox)sender;
    var newValue = checkbox.IsChecked.GetValueOrDefault();

    Application.Current.Host.Settings.EnableFrameRateCounter = newValue;
    SystemTray.IsVisible = !newValue; // Hides frame rate counter otherwise
}

Enabling frame rate counters only on debug builds

You can also use conditional compilation to just have your debug builds display this information. Add this to your App.xaml.cs:

#if DEBUG
    Application.Current.Host.Settings.EnableFrameRateCounter = true;
    Microsoft.Phone.Shell.SystemTray.IsVisible = false;
#endif

This assumes you remember to eventually ship your app on the marketplace with a release build .

Accelerated graphics note: If you still don’t see a frame rate counter

The frame rate counter only appears when your system has a supported DirectX 10 graphics card that allows the Windows Phone emulator to use accelerated graphics.

If you set the frame rate counter visibility to True, the system tray is hidden, and you still don’t’ see the counters, then unfortunately your system does not have a supported card for displaying this information.

All Windows Phone devices will show the frame rate counter, so once phone hardware is more widely available, you’ll still have an option to test the performance of your apps.

Exploring the frame rate counter data

This has been covered countless times, but I figure if you’re [using your search engine of choice to find this] here that it doesn’t hurt to duplicate.

The Beta tools display frame counter information on the top of the page.

Shipping frame counter information is displayed on the right of the screen.

So moving through the counters, we have the following.

Render Thread FPS: The number of frames per second that the independent simple animations and rendering thread is using. Keeping around 60 will provide a great experience, while a number of 30 fps will begin to show a poor experience to the end user.

Under 30 fps this counter will turn red in post-beta builds.

User Interface Thread FPS: The number of fps that the primary user interface thread is experiencing. Property change notifications, data binding, primary managed code execution, and animations not handled on the render thread use this threads’ resources.

Turns red when the count is at or below 15 fps.

Texture Memory Usage: A specialized memory counter indicating the video memory used for storing application textures.

Surface Counter: A count of the number of surfaces that are passed to the graphics chip.

Intermediate Texture Count: The number of intermediate textures created for compositing.

Screen Fill Rate: A metric representing the number of complete phone screens being painted each and every frame.

This counter was not present in the Beta tools and is a new metric for post-Beta use.

Target frame rates for good performance

When testing on a Windows Phone device, here are key performance metrics to try for. Understand that the emulator (XDE) performance may not be indicative of actual device performance.

Frame rate counters may be 0 when there is no animation being updated on the thread at any particular moment. You can add a very simple, continually animating and repeating, animation to your application during development & testing if you want to ensure that there is always some frame rate value available.

Counter	Ideal Minimum	Best Experience	Theoretical Max
Render Thread	30 fps	60 fps	120 fps
UI Thread	15 fps	> 15 fps	120 fps
Screen Fill Rate	1.0	<= 2.0	N/A

Future posts will cover tips for improving the frame rate and application performance. Hope this helps.

Updated Silverlight Unit Test Framework bits for Windows Phone and Silverlight 3

Jeff Wilcox — Thu, 27 May 2010 21:02:52 +0000

Here are updated quasi-official unit test framework bits for Silverlight 3 and Windows Phone developers. These are not intended for Silverlight 4 developers, since the same framework built for SL4 is included in the April 2010 Silverlight Toolkit.

This brings the new features from the Silverlight 4 version to developers who have a business reason to continue with Silverlight 3 development for the time being:

Updated user interface
Integrated “tag expression” support for selecting subsets of tests to run
Performance improvements
Removal of dependencies on XLinq and System.Windows.Browser assemblies

These are also the bits you want for Windows Phone testing.

Why wasn’t there one for Silverlight 3 already?

Since the April 2010 toolkit release was targeted for Silverlight 4 developers only, these bits were not released for version 3 (though were built from the same source).

Why doesn’t the April 2010 toolkit work for Windows Phone development & testing?

The Windows Phone development environment is based on a version of Silverlight 3 today, and so that means that you need to use Silverlight 3 binaries and class libraries when re-using Silverlight apps and code – not Silverlight 4.

These bits work well for phone developers and replace the older bits I had posted to my MIX talk site.

Download the binaries

[Silverlight 3 binaries for the Silverlight Unit Test Framework, Zip 452KB]
You may need to ‘unlock’ the binaries for security reasons once downloading and extracting the assemblies from the .Zip. To do this, right-click on the file and select the ‘Unlock’ button.

These binaries are strong named as before, but are not Authenticode signed, so they are not official. This helps work around some Windows Phone signing issues I’ve heard reports of.

Hope this helps,
Jeff

Windows Phone? Sounds exciting!

Jeff Wilcox — Fri, 21 May 2010 19:35:22 +0000

As an FYI, I wanted to let people know that I’m now focusing much more exclusively on the Windows Phone project here at Microsoft. Though the organization boundaries aren’t that exciting, I am still part of the great Silverlight team – only now more focused on the phone development story.

It’s a familiar crowd: many of the brightest from across the company have been joining the ranks, and a lot of the classic Silverlight Toolkit team members are a part of the effort.

The focus of this blog won’t be changing much at all – I continue to be involved in Silverlight Toolkit, the Silverlight Unit Test Framework, and anything else I can get my hands on.

“Peppermint” MIX demo sources

Jeff Wilcox — Fri, 26 Mar 2010 21:30:53 +0000

At MIX, during my talk on unit testing Silverlight and Windows Phone applications, I demoed a simple application called ‘Peppermint’. Here’s the source; I’ll be writing up a full tutorial on Windows Phone later, so these are just ‘bleeding-edge bits’.

Peppermint-Demo.zip [Zip, 1.2 MB]

Silverlight:

Requires Visual Studio 2010 (or express)
Requires the Silverlight Toolkit
Requires the test framework binaries included in the zip

Windows Phone:

Requires the Windows Phone development tools CTP
Requires the test framework binaries included in the zip

Displaying 2D QR barcodes in Windows Phone applications

Jeff Wilcox — Fri, 26 Mar 2010 18:37:51 +0000

Last year, enthused by the Starbucks Mobile Card application for the iPhone, I built an app that displays 2D QR barcodes in Silverlight. Today, in two minutes, I got that running on the Windows Phone. Talk about an awesome development experience.

These barcode-displaying apps let you get rid of the plastic in your wallet and use your phone instead. Many airports and carriers have been using these barcodes for paperless boarding passes, too.

The barcode within the Windows Phone app on the left is QR encoded and stores the text ‘Hello World’

So, background: when I did this first implementation in September of ‘09, I wanted to see how quickly I could adapt existing .NET libraries for the desktop to work with Silverlight. I was really happy to find that it was simple, taking an existing .NET library for generating 2D QR barcodes and doing some WriteableBitmap work.

This really demonstrates how awesome the app platform for the Windows Phone can be – building on top of not only existing Silverlight knowledge, code, and libraries – but also full-fledged .NET libraries.

Here’s the app, and you’ll even see on the design surface that the barcode is showing up in real-time:

I expose the barcode through a simple control. Here’s the XAML that binds the barcode’s encoded text to the text box’s text – yes, you can type on the phone in real-time and watch the barcode update:

Download the source to this Windows Phone app

JeffWilcox.WindowsPhone.Barcode.zip [Zip, 1.12 MB]

Requires the Windows Phone development tools CTP (info)

Hope this helps.

Data binding user settings in Windows Phone applications

Jeff Wilcox — Fri, 26 Mar 2010 01:02:23 +0000

Thanks to the rich data binding system built into Silverlight for Windows Phone, you can easily store rich user settings without using code behind files.

The canonical example of user settings is a “Show this welcome screen at startup” checkbox so that your application can offer a nice out-of-box experience.

By writing a simple type with some properties, adding a few helper files, and setting up a two-way data binding, you can store any settings without having to write special code.

Here’s what the completed project’s two-way data binding looks like for the checkbox shown to the right:

You’ll see these components in the data binding:

Source is a static resource, a strongly typed settings class you define
Path points to the property name to bind to
Binding is two-way so that the value is stored automatically
Value and type converters can be applied as always in bindings if necessary

Let’s quickly implement this functionality in a quick app. We’ll also add a text box to the main application page, to let the value always be persisted between application runs, and even application updates.

Getting started

You can use the free Windows Phone development tools, or just Visual Studio 2010 if you have the phone tools CTP installed already.

Create a new ‘Silverlight for Windows Phone’ application project.

Adding some helper code

Either add the class library project I have for download here, or just add the 4 C# files that make up the helper code:

SettingsHelperCode.zip (8 KB, zip)

Creating your configuration/settings type

Next, we need to create a strongly typed configuration class that derives from my SettingsProvider type. This class must:

Implement INotifyPropertyChanged, so that bindings work well
Have properties of the appropriate type for the settings you are interested in. Optionally, include the DefaultValue attribute to provide defaults.

Here is the MySettings.cs file I’ve created for this app. It defines two properties that I always want to have stored:

HelloWorld is just some text I let the user edit in the user interface. A more realistic setting might be “best friend” or a list of people to show on the home screen of the app.
IsFirstRun is a true/false value that indicates whether the welcome screen should be shown.

// (c) Copyright Microsoft Corporation.
// This source is subject to the Microsoft Public License (Ms-PL).
// Please see http://go.microsoft.com/fwlink/?LinkID=131993 for details.
// All other rights reserved.

using System.ComponentModel;
using JeffWilcox.Settings;

namespace Sample
{
    /// 
    /// My settings class for storing application data and setting specific to
    /// the user.
    /// 
    public class MySettings : SettingsProvider
    {
        private bool _isFirstRun;
        private string _hello;

        public MySettings() : base("MySettings.xml") { }

        [DefaultValue("What's up?")]
        public string HelloWorld
        {
            get { return _hello; }
            set
            {
                _hello = value;
                NotifyPropertyChanged("HelloWorld");
            }
        }

        [DefaultValue(true)]
        public bool IsFirstRun
        {
            get { return _isFirstRun; }
            set
            {
                bool old = _isFirstRun;
                _isFirstRun = value;
                if (value != old)
                {
                    NotifyPropertyChanged("IsFirstRun");
                }
            }
        }
    }
}

Looking closer, inside the MySettings file:

MySettings type derives from SettingsProvider, part of the helper code downloaded above.
The constructor calls the base class’s constructor with the name of a settings file to use within the isolated storage area for the phone application
Properties have backing fields and fire change notifications
Default values

Add the settings object to your App.xaml

Now, open up App.xaml. Add an XMLNS prefix declaration for your project. I named my app project “Sample”, so it’s short:

xmlns:local="clr-namespace:Sample"

And then add your settings object to the resources (I’m omitting all the theme resources in App.xaml to make it clear where this goes only).

AlwaysSaveOnChange needs to be set to true for Windows Phone applications: if you’re building a regular Silverlight app, the Application.Exit event works well and can be used to store. But on the phone, since an app may be in a paused or unknown state, this property tells my helper code to save the settings whenever a binding has a change notification. For performance impact should be minimal.

A simple TextBox binding

Now on my MainPage.xaml, I am just going to bind to the Hello World property from the MySettings type. Any time you type characters into the text box, they will be saved, and always there when you run the app. No need to write code to save or read settings.

Good to go

To pull it in, I’m going to add a page called FirstRun.xaml to the project. This will be the content that I want first-time users to see. Then, I need to add the code to call this from main page at startup:

I define a loaded event for this that checks whether the current instance has run the page yet (hacky, and not a permanent setting), and then checks whether the user wants to see the screen (which defaults to true in my settings file):

if (!((App)App.Current).HasFirstRunCheckHappenedYet)
{
    ((App)App.Current).HasFirstRunCheckHappenedYet = true;

    MySettings settings = (MySettings)App.Current.Resources["MySettings"];
    if (settings != null && settings.IsFirstRun)
    {
        NavigationService.Navigate(new Uri("/FirstRun.xaml", UriKind.Relative));
    }
}

It then uses the navigation service to navigate, if needed.

If you’d like to learn more about Silverlight data binding, do check out this MSDN resource: http://msdn.microsoft.com/en-us/library/cc278072(VS.95).aspx

Some people have experimented with directly binding to the isolated storage settings file, but this approach gives your some separation – by having your own class, you can provide default values, even upgrade logic, and do some neat work.

This is based on a classic WPF post by Patrick Danino which used the full .NET configuration classes. Enjoy!

Silverlight Toolkit and the Windows Phone: WrapPanel, and a few others

Jeff Wilcox — Sun, 21 Mar 2010 20:27:34 +0000

Are you looking for WrapPanel for your Windows Phone application? Look no further. The Silverlight Toolkit has several controls that work pretty well on the Windows Phone.

I wanted to provide my own informal look at how it’s working with Silverlight for Windows Phone today.

Note that this information is only current as of today, 3/21, when used with the MIX-related CTP of the tools and emulator, and the November 2009 Silverlight Toolkit. A lot could change, and this is not exhaustive.

I’m also including some controls that are found in the Silverlight SDK today. I present these in order of how much I have used the components while building apps.

WrapPanel and DockPanel

Found in the Silverlight Toolkit, System.Windows.Controls.Toolkit.dll (SWC.Toolkit).

Work great.

If you just need the WrapPanel, and don’t want to include the entire toolkit assembly, you can just paste these source files into your application project instead (license: Ms-PL):

Charting and Data Visualization

There is a known issue with LINQ that prevents the controls today from working perfectly. A small, targeted fix has been made in the charting codebase and a future release will work well on the device.

Re-templating and styling the control is very important, and required, for working on the phone in an acceptable manner. I hope to share any decent templates I can come up with.

HeaderedItemsControl, HeaderedContentControl

Work great. Split between System.Windows.Controls (SWC) and SWC.Toolkit.

TreeView

SWC. Functional; requires massive re-templating and styling. Font sizes are much too small, and the theme and visuals do not appear code-name “Metro” compatible.

AutoCompleteBox

Found in the System.Windows.Controls.Input SDK library of the Silverlight 3 SDK.

Works OK, not ready for general development use.

Drop-down appears well. Major features all work. However, touching an entry in the drop down only performs selection. A second touch is required to verify the choice, effectively requiring a double-tap in use.

Calendar, DatePicker

SWC. Limited functionality, too small visually. Not designed for touch – not enough space to reliably click on a date. Require massive re-templating. Do not resemble the same experience as the date picker built into the Windows Phone operating system.

GridSplitter

Works, but may pose difficult to use on a device: requires much larger padding and custom templates to make the touch area visible and useful.

Not yet checked

DataGrid, DataPager, ChildWindow, Label, NumericUpDown, DomainUpDown, DataForm, Rating, TimePicker, TimeUpDown, GlobalCalendar, TransitioningContentControl, TreeMap, BusyIndicator, Viewbox, Expander, Accordion, drag and drop features, and many more.

We’re also still developing a story for the toolkit’s phone story moving forward. As there is a lot of momentum around the phone in the company, it’s very likely that some set of phone tools, samples, and toolkits come out.

Hope this helps.

Unit Testing Silverlight & Windows Phone Applications – talk now online

Jeff Wilcox — Wed, 17 Mar 2010 22:07:26 +0000

My MIX 10 talk, an introduction to unit testing on Silverlight and the Windows Phone, is now online for streaming and download. Thank you to everyone who attended.

An early preview set of bits are online at http://jeffatmix.com/ – and the next release of the Silverlight Toolkit when Silverlight 4 ships will contain support for the phone officially. Stay tuned for more.

Over the next few weeks, I’ll be blogging plenty on these subjects.

Jeff Wilcox » Windows Phone

Exploring List capacities and growth on the Windows Phone

Constructed capacity is ZERO

First item brings the capacity to 4 items

Capacity + 1 grows the capacity exponentially

Clipping the capacity back

Initializing to a set size

Windows Phone performance progress bar update: part 2, remember to turn IsIndeterminate off when not needed!

1: Use PerformanceProgressBar over the built-in ProgressBar style

2: Turn off IsIndeterminate when not needed

Blend tip: finding default styles using “Edit a Copy”

Getting started

Add the control that you’d like the template or style of

Use the Edit Template menu right-click option

View the XAML

Note: Nested styles and templates

Note: Windows Phone developer tools theme XAML

Looking ahead: Panorama and Pivot controls for Windows Phone developers

Learning about the native experience

Key Features

Panorama

Panorama XAML

About wide horizontal sections

Panorama APIs

Microsoft.Phone.Controls.Panorama

Dependency Properties

Events

Microsoft.Phone.Controls.PanoramaItem

Dependency Properties

Pivot control

Pivot XAML

Pivot APIs

Microsoft.Phone.Controls.Pivot

Dependency Properties

Events

Microsoft.Phone.Controls.PivotItem

Visual Studio & Expression Blend Tooling

Start with a complete application template

Add New Pages

Blend Assets

Easy property editing

Right-click, add new panorama item or pivot item

Other notes

Exposing scrolling data

Items control API

Both controls

Differences

Migration

Stay tuned!

TiltContentControl for Windows Phone

Introducing Luke’s TiltContentControl

ContentControl vs Attached Property

Adding the control to your project

How to use the control within your project

Creating and using a custom easing function

Quick perf lesson #1: Avoid custom easing functions as they have a negative performance implication

Quick perf lesson #2: Store a single static instance of property paths when creating animations in code

Does this tilt exactly match the OS?

Workaround note for beta tools developers

Full implementation of TiltContentControl.cs

Namespace: Microsoft.Phone.Controls.Unofficial

Creating high performance Windows Phone apps – THE WHITEPAPER

A high performance ProgressBar for Windows Phone

8/17/10 Update

The original post follows:

Using the PerformanceProgressBar in your app

Get the code

Add the PerformanceProgressBar style

Add this alternate ProgressBar control style everywhere

The back story

Why Slider is in the template

Animating the Slider::Value property means the animation happens on the UI thread (not good!)

What needs to change in ProgressBar? Should we build our own?

Why can’t MSFT update the progress bar in the platform?

Shouldn’t everything just be fast and have great performance anyway?

What’s this RelativeAnimatingContentControl I added to my project?

Why’s the control in the Microsoft.Phone.Controls.Unsupported namespace?

What changed in the PerformanceProgressBar style

Feedback

Frame rate counters in Windows Phone