Mike Battista's Blog

Respond to User Input

Mike Battista — Sun, 22 Apr 2012 21:42: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.

Handle Feature Reductions

Mike Battista — Sun, 15 Apr 2012 21:11: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.

Reduce Memory Usage

Mike Battista — Sun, 08 Apr 2012 20:53: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.

Optimize Startup Time

Mike Battista — Wed, 28 Mar 2012 23:42: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>.

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.

Grid.Row="0", for instance, is the default value if Grid.Row is not declared, so just don't declare it.
SupportedOrientations="Portrait" and Orientation="Portrait" can be removed as well for portrait only pages since this is the default.
Understand default values and remove redundant XAML.

Avoid retemplating controls in App.xaml.

Retemplating controls can require complex XAML which is expensive to parse.
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.
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.

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.

Don't use nested Grids and StackPanels when one root container would be sufficient to layout your page.

Declare your app bar in code.

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.

Weather v2.0

Mike Battista — Sun, 11 Mar 2012 01:44:40 GMT

Recently I updated the Microsoft Weather app to take advantage of new Windows Phone 7.5 features like background agents, secondary tiles, and FAS. The update hit the Marketplace today.

In addition to having new features, this version was architected from the ground up for performance following many of the guidelines I call out in my recent blog post Optimizing Apps for Lower Cost Devices.

I encourage you to follow the same performance/UX principles demonstrated by this new Weather update. Following these principles will ensure your apps perform great regardless of the device.

Hope you like the new update and have fun building for Windows Phone!

Optimizing Apps for Lower Cost Devices

Mike Battista — Fri, 09 Mar 2012 18:29:00 GMT

The recent announcement of lower cost Windows Phones like the Lumia 610 brings with it a great opportunity for you to reach many more users with your apps.

See http://windowsteamblog.com/windows_phone/b/wpdev/archive/2012/03/07/optimizing-apps-for-lower-cost-devices.aspx for some high-level guidance regarding how to optimize your apps for these lower cost devices.

Also watch http://channel9.msdn.com/Shows/Inside+Windows+Phone/Inside-Windows-Phone-33--Windows-Phone-75-Refresh--60-more-Opportunity for some more context about the release and what it means for you and your apps.

Geocoding and Routing with Bing Maps

Mike Battista — Tue, 18 Jan 2011 00:21:00 GMT

Location-aware applications offer some of the richest experiences on a smartphone that really showcase the smartphone's unique blend of portability and network connectivity. These applications often use geocoding and route calculation to power their experiences. With the Bing Maps Control and Bing Maps Web Services, you can incorporate these features into Windows Phone applications to bring your location-aware concepts to life.

Get a Bing Maps Key

In order to access the Bing Maps Web Services for geocoding and route calculation, you'll first need to get a Bing Maps key for your application. This key identifies your application to Bing and is sent with every request to the Bing Maps Web Services.

Configure Service References

The next step is to configure service references in your application to create proxy classes for interfacing with the Bing Maps Web Services.

In Visual Studio, right click on your application project and select "Add Service Reference...".
Enter http://dev.virtualearth.net/webservices/v1/GeocodeService/GeocodeService.svc for the Geocode Service and click Go.
Once the service is discovered, enter "GeocodeService" for the namespace and click OK.
Repeat steps 1-3 using http://dev.virtualearth.net/webservices/v1/RouteService/RouteService.svc for the Routing Service and "RouteService" for the namespace.

Add a Reference to the Bing Maps Control

The Bing Maps Control ships with the Windows Phone Developer Tools but resides in an assembly that is not referenced by default in the Visual Studio project templates. Right click on your application project, select "Add Reference", and then select the Microsoft.Phone.Controls.Maps assembly to add the necessary reference.

Import the MapHelper Class

The Bing Maps Interactive SDK provides sample code for interacting with the Bing Maps Web Services. I felt that the necessary modularity needed to make this code truly reusable was missing, so I wrapped the sample code in a helper class called MapHelper that exposes three public methods of interest.

Geocode(string address, Map map)
ReverseGeocode(double latitude, double longitude, Map map)
CalculateRoute(string source, string destination, Map map)

These methods wrap the results from the service proxy responses into EventArgs objects and expose them in the GeocodeResultAvailable, ReverseGeocodeResultAvailable, and RouteResultAvailable events, respectively. Simply add the attached MapHelper.cs file to your project, update its namespace to match the default namespace of your project, and then call the above methods with the desired parameters like below.

var Map = new Map()
{
    CredentialsProvider = new ApplicationIdCredentialsProvider("[ApplicationId]")
};

Observable.FromEvent<GeocodeResultAvailableEventArgs>(
    ev => MapHelper.GeocodeResultAvailable += ev,
    ev => MapHelper.GeocodeResultAvailable -= ev).
    Where(args => args.EventArgs.Address.Equals("One Microsoft Way Redmond WA")).
    Take(1).
    Subscribe(
    (args) =>
    {
        if (args.EventArgs.GeocodeResult != null)
        {
            MessageBox.Show(args.EventArgs.Address + " = " + args.EventArgs.GeocodeResult.DisplayName);
        }
        else
        {
            MessageBox.Show("No match for " + args.EventArgs.Address);
        }
    });


MapHelper.Geocode("One Microsoft Way Redmond WA", Map);

In the above example, I create the Map control in code for simplicity. If you already have a Map control in XAML, you can reference it via its x:Name. I also use the Reactive Extensions for Windows Phone to provide more robust event handling.

To verify that you can in fact talk to the Bing Maps Web Service at this point, copy the above code into your main page's constructor. Replace "[ApplicationId]" with your Bing Maps key created earlier, add references in your project to Microsoft.Phone.Controls.Maps, Microsoft.Phone.Reactive and System.Observable if they are not already there, and add using statements for Microsoft.Phone.Controls.Maps and Microsoft.Phone.Reactive. If all goes well, you should receive a message box with the geocode result for "One Microsoft Way Redmond WA" when you launch your application.

Plot the Results on a Map

The above example simply displays the results in a message box in order to demonstrate how the MapHelper class simplifies talking to the Bing Maps Web Services. In many scenarios, you will want to plot the results on the Bing Maps Control.

Attached is a Windows Phone Application Page I created for a local events application that contains a Bing Maps Control, a Progress Bar, and some additional map layers used for plotting results. The code behind file contains callbacks for plotting geocodes as well as route calculations. This particular page will try to calculate a route first and fall back to a geocode of the destination if a route cannot be calculated. The page also contains logic so that the map will remember its state during tombstone scenarios.

While I don't expect this page to compile for you, I feel that it is a good reference for how to use the Bing Maps Control and MapHelper class in practice.

Conclusion

The possibilities for location-aware applications on smartphones are endless. With the Bing Maps Control and the MapHelper class, you should be well equipped to light up the location-aware features of your Windows Phone applications.

Handling Events with Reactive Extensions

Mike Battista — Thu, 02 Dec 2010 21:31:00 GMT

If you've had a chance to play around with Silverlight for Windows Phone, you've likely realized the importance of asynchronous programming and event handling. Pushing tasks off thread keeps your UI responsive and allows users to interact with your application while you perform important tasks in the background.

While standard event handler patterns work well for simple scenarios, you may have at some point wished you had more flexibility in the way you handle events. Maybe you'd like to filter the events firing at you and only respond to a subset of those events based on criteria that you specify. Maybe you've listened for a stream of web service responses only to find that a user action has invalidated that stream, and you'd like to ignore any stale responses that might come back and just start listening for new ones.

You might typically solve these problems by adding Boolean flags and other state handling artifacts into your code to manage all the state required to describe your scenarios. Though achievable this way, these solutions add bloat to your code and distract someone reading the code from its primary objective.

Over my experience building Windows Phone applications, I've encountered several common scenarios like the ones above that I was able to implement elegantly using the Reactive Extensions for .NET. These extensions support a different model for handling events that has the flexibility and power to handle the above scenarios elegantly without requiring much effort. The resulting solutions succinctly describe their desired behavior and at the same time avoid some of the common pitfalls associated with the standard event handler patterns.

Deregistering Event Handlers

Let me start with a simple example of how Reactive Extensions handles a common pitfall with the standard event handler patterns.

Have you ever forgotten to deregister an event handler? If you have, you may have experienced the unpredictable behavior caused by event handlers firing an unexpected number of times.

With Reactive Extensions, the deregistering of event handlers happens automatically once the behavior you describe is accomplished. If you're only interested in one instance of an event, Reactive Extensions will deregister that event handler for you once the event is raised. This is accomplished with code like the following.

Observable.FromEvent(
    (EventHandler<EventArgs> ev) => new EventHandler(ev),
    ev => App.Initialized += ev,
    ev => App.Initialized -= ev).
    Take(1).
    Subscribe(
    (args) =>
    {
        SearchInProgress = false;
    });

Since you specify that you are only interested in one Initialized event with Take(1), the Reactive Extensions will deregister the event handler for you once it receives that one instance of the event. The discipline of deregistering event handlers is enforced by the declaration of the behavior.

Another advantage of this model is that the deregistering of the event handler is grouped along with the qualifiers for the event and the definition of the event handler, making a compact unit that clearly describes the trigger for the behavior as well as the behavior itself. This improves code readability and is easy to extend and modify later.

Filtering Events

With standard event handling patterns, your event handlers are triggered every time an event is raised. This requires that you add logic to your event handlers to ignore undesirable events, which can obscure your code's intentions.

With Reactive Extensions, you can easily define qualifiers for an event stream that will filter undesirable events for you automatically. This means that your event handler will only be triggered when a desirable event occurs, saving you from having to add filter logic. This keeps your event handlers clean and compact and removes the risk of introducing bugs with custom filter logic.

I've leveraged Reactive Extensions this way in a helper class I use to get the phone's current location.

Observable.FromEvent<GeoPositionStatusChangedEventArgs>(
    ev => GeoCoordinateWatcher.StatusChanged += ev,
    ev => GeoCoordinateWatcher.StatusChanged -= ev).
    Where(args => args.EventArgs.Status == GeoPositionStatus.Ready || args.EventArgs.Status == GeoPositionStatus.Disabled).
    Take(1).
    Subscribe(
    (args) =>
    {
        if (args.EventArgs.Status == GeoPositionStatus.Ready)
        {
            RaiseCurrentLocationAvailable(new CurrentLocationAvailableEventArgs(GeoCoordinateWatcher.Position.Location));
        }
        else
        {
            RaiseLocationServicesDisabled();
        }
    },
    () =>
    {
        GeoCoordinateWatcher.Stop();

        RequestInProcess = false;
    });

This code is similar in structure to the previous example with a few important additions.

You'll notice that before the Take(1) I have added a Where clause that specifies that I am only interested in the Ready and Disabled statuses. With this line of code, I add qualifiers to the StatusChanged event so that my event handler doesn't have to care about extraneous events. Not only is this clean, but the event handlers will be deregistered automatically as described above once either a Ready or Disabled status is reached.

Another important addition here is the inclusion of a finalizer action in the second parameter of the Subscribe method. The first parameter of the Subscribe method contains your typical event handler code. This code will execute once for every interesting event that is raised. The finalizer action will execute once after all of the interesting events have been raised. This is your chance to perform any cleanup like you would in the finally block of a try catch statement. You'll notice above I take this opportunity to stop the GeoCoordinateWatcher and update some state.

MSDN has a great article about using Reactive Extensions in other ways to emulate and filter location data from the phone's location services.

Composing Multiple Web Service Requests

A common feature among Windows Phone applications is a search page. In some cases, a single search query might seed multiple web service requests that should all be joined and presented to the user as a single set of search results.

A solution to this would be to track all of the intermediate results and present the entire set of results to the user once all of the intermediate results are obtained. The ideal solution would not only compose the multiple web service requests into a single set of search results but would also ignore stale results from potentially old search queries.

This scenario is actually called out in the Reactive Extensions for .NET Overview for Windows Phone as a typical mobile scenario for Reactive Extensions. I was able to implement this solution with the following.

Observable.FromEvent<SearchResultsAvailableEventArgs>(
    ev => Provider.SearchResultsAvailable += ev,
    ev => Provider.SearchResultsAvailable -= ev).
    Where(args => args.EventArgs.Query.Equals(query)).
    Take(3).
    Subscribe(
    (args) =>
    {
        if (ActiveSearchQuery.Equals(query))
        {
             SearchResults[args.EventArgs.Type] = args.EventArgs.SearchResults;
        }
    },
    () =>
    {
        if (ActiveSearchQuery.Equals(query))
        {
            var List = new List<ISearchable>();

            List.AddRange(SearchResults[typeof(Type1)]);
            List.AddRange(SearchResults[typeof(Type2)]);
            List.AddRange(SearchResults[typeof(Type3)]);

            RaiseSearchResultsAvailable(List);
        }
    });

The basic structure of this code should look familiar as it is essentially identical to the previous example. In this scenario, I am using one search query to seed three searches for three different types of results.

With the Where clause and the Take(3), I specify that I am interested in three instances of the SearchResultsAvailable event where the results are for the search query just entered. By passing the search query through as the Query property in the SearchResultsAvailableEventArgs, I can reference it in the Where clause with args.EventArgs.Query, which allows me to compare the entered query against the query associated with the returned search results.

In both the event handler code and the finalizer action, I ignore stale results by comparing the query associated with the returned search results against the active query I have stored in the ActiveSearchQuery property. While the results from all search queries will be processed, the search results will only be composed for results from the active search query. This protects against overlapping search queries when the network is slow or when the user otherwise initiates overlapping search queries.

Once all of the search results for the active search query are obtained, I compose the results in the finalizer action and raise an event to notify listeners that the search results are available.

Conclusion

The Reactive Extensions for .NET are a powerful tool to have in your arsenal. The examples above are practical applications of handling events with Reactive Extensions that I have encountered in my experience building Windows Phone applications.

While no one article can really do justice to the power of Reactive Extensions, I hope the above examples have shed some light on the elegance and expressiveness that Reactive Extensions has to offer.

For more information about what Reactive Extensions can do for you, check out Rx Wiki as well as Channel 9.