Getting ready for the Windows Phone 7 Exam 70-599 (Part 4)

This is the fourth part of my article series to prepare you for Microsoft's new Windows Phone 7 exam which will be available starting July 14th. For a short introduction and overview of the exam as well as a list of general learning materials please take a look at the first article. The official outline of the measured skills breaks down the topics into the following parts:

• Designing Data Access Strategies (19%) (this article)
• Designing and Implementing Notification Strategies (17%)
• Working with Platform APIs, Tasks, and Choosers (21%)
• Designing the Application Architecture (21%) (this article)
• Designing the User Interface and User Experience (22%)

The last article was all about working with specific platform APIs. In this part, we'll take a look on the overall architecture of an application and unique concepts of the Windows Phone platform as well as tuning your application for performance and marketplace certification.

A note on the MSDN documentation: all online resources in the MSDN library for the Windows Phone documentation are now the pre-release documents for Windows Phone OS 7.1 ("Mango"). The original documentation for Windows Phone OS 7.0 (which the exam is likely based on) can be downloaded for offline use here (CHM format). Often there's little difference or it is likely that the changes have no effect on the exam; however in some cases this might not be the case or there are options available in "Mango" that are not part of the RTM release, so you should carefully compare the different versions, and if in doubt, base your learning on the 7.0 documentation.

Designing the Application Architecture

When you create an application, the primary concern naturally is to implement all the features you have imagined and make the outcome just like you pictured it. However, there is more to it. Like with any other platform, there are specific topics to consider for Windows Phone 7. Some of them help you optimize your application and provide an even better user experience, others are restrictions imposed deliberately for reasons of platform consistency or security, and finally there simply are technical facts that you need to accept and work with. This part of the exam topics has all of that.

Design for threading

"This objective may include but is not limited to: use of the composition thread"

Traditionally, what you see on the screen of a computer was all calculated by the CPU. However, over the years specialized hardware took over a lot of this work. For example, modern 3D games are rendered by powerful GPUs, and displaying videos also is hardware-accelerated even by low-end video cards. The same is true on mobile devices. Special hardware can not only handle video and graphics faster and better, it even is more power efficient than general purpose CPUs in that.

On the Windows Phone platform, this is reflected in a construct named "composition thread" (sometimes also mentioned as "compositor thread"). This is an additional thread that runs in parallel to the normal UI thread, and its sole purpose is to offload certain drawing operations of UI elements from the UI thread and pass it to the GPU directly. As the name suggests, it "composes" textures and passes them on to the GPU. To this end, those textures (bitmaps) have to be created by the UI thread once and can then be reused by the composition thread until e.g. a change in the layout of controls or similar requires that the bitmap is recreated. Supported operations by the composition thread are:

• Scale transforms (as long as they are less than 50 percent of the original size)
• Translate transforms
• Rotate transforms
• Plane projections
• Changing the opacity
• Clipping

As long as the composition thread is able to handle an operation, it does not put strain on the UI thread, and the other way round is also true: operations performed by the composition thread are able to continue unaffected even if the UI thread is under heavy load. In practice this means that if you design your animations so they can make use of the composition thread you benefit in both ways; you can for example increase the responsibility of your application as well as make sure animations continue to run even if you have to do some processing on the UI thread. One noteworthy thing is that unlike in desktop Silverlight (version 5), on Windows Phone 7 there's an "auto-caching" feature, which means you don't have to configure anything to let your storyboard-driven animations run on the composition thread, as long as you make sure you're not doing anything that requires the UI thread to be involved. You can of course also manually apply a bitmap cache to an element if you want to make use of this feature explicitly. We'll see how you can make sure the features works as intended in a second.

In addition to the composition thread, you can of course make use of the other well-known threading features of Silverlight on Windows Phone too, to execute (non-UI related) computations in the background. In particular, this means that you can take advantage of the BackgroundWorker class, or if you need a more low-level approach, you can use the thread pool or dedicated threads manually.

Another little known possibility to use threading features is the use of the built-in Reactive Extensions, and in particular the Scheduler class. This class makes it very easy to execute your actions on a new thread, the thread pool, or marshal them to the UI thread, also in an recursive, timer-like manner.

• MSDN: Understanding Threads – This particular section of the "Performance Considerations" article explains the UI thread and composition thread concept in more detail.
• MSDN: How to Use a Background Worker
• MSDN: Code Samples for Windows Phone – The "Custom Indeterminate Progress Bar Sample" (article link) shows how to create a control that makes use of the composition thread for better performance.
• Channel 9, Jeff Wilcox at MIX11: Analyzing and Improving Windows Phone Application Performance – Also contains a few minutes of explanation about the compositor thread (please note that it also adds information on the upcoming Mango update features that are not part of the RTM release).
• Den Delimarsky: Scheduling tasks on Windows Phone 7

Monitor and tune performance

"This objective may include but is not limited to: frame rate counter; cache visualization; redraw regions; bitmap caching; memory usage limitations; plan for power consumption; tune bandwidth consumption; performance counters"

With the nature of limited resources on a mobile platform in place, monitoring and optimizing your application becomes an important topic. There are some built-in features to help you with the monitoring part:

• Frame rate counter: If you enable the frame rate counter, you will not only see the frames per second for both the UI and the composition thread, but it will also provide additional data about the texture memory usage, the number of surfaces and the fill rate. To make sense of and draw conclusions from these numbers, make sure you understand the description and recommendations here.
• Cache visualization: This feature helps you determine what parts on the screen are maintained by the composition thread, either because they've been automatically selected by the auto-caching feature, or because you've set the bitmap caching explicitly (see above). It's a great tool to determine whether caching works as you intended it to be, or if you put too much strain on the GPU with manual caching, for example.
• Redraw regions: By turning on this feature you can easily spot which parts of your application are redrawn each frame. Sometimes it's not obvious what layout actions cause redraws (and hence potential performance degradation) of other parts of your application; this tool helps identifying these hot spots.

Tuning performance mostly concentrates on three aspects: memory, power consumption and network bandwidth.

• The important part to know is that for memory usage, there is a fixed restriction for applications on the Windows Phone: unless the device has more than 256 MB of physical RAM, your application must not consume more than 90 MB. Mike Ormond has written a post on monitoring memory consumption here. Please note that the used class "DeviceExtendedProperties" will be deprecated in the Mango update, but is legitimate to use in the RTM release. Peter Torr has a similar helper here.
• For the aspect of power consumption, fixed requirements only exist for certain scenarios, for example when your application runs under the lock screen (the requirements in that case can be found here). But it's always worth thinking a bit about power consumption to preserve battery life. For example, one of the not so obvious recommendations is to make large numbers of small web service requests in parallel rather than sequentially, so the operating system has the opportunity to run into its configured timeouts and turn off the radio quicker (described here).
• Network bandwidth is another valuable resource on the phone. Optimizations here include indirect tuning, like making sure remote resources are optimized for the platform. For example, downloading a huge image and scaling it down on the phone would be something to avoid; instead, a prepared version for the phone with a lower resolution should be used. More direct approaches to tune this are e.g. to use formats with less overhead, for example using a JSON web service endpoint instead of SOAP can help with that in certain situations. Optimization for network bandwidth also includes scheduling large downloads for times when the phone has Wi-Fi access instead of using the radio connection. Note that we have tackled the topic bandwidth limitations and network connectivity detection in part 1 of this series already.

Further useful resources regarding monitoring and tuning performance are:

• MSDN: Performance Considerations in Applications for Windows Phone – Very comprehensive article that explains a lot of issues and considerations relevant for performance, memory and power consumption optimization.
• Channel 9: Optimizing Windows Phone Silverlight Applications – A hands on tips and tricks video on the topic. Includes download links to an accompanying paper and samples.
• Channel 9, Jeff Wilcox at MIX11: Analyzing and Improving Windows Phone Application Performance – Another interesting video on the topic. Note that it includes several explanations about the upcoming Mango update too.
• Channel 9: Optimizing for Performance – Another part of the "Jump Start" series.

Manage the application life cycle

"This objective may include but is not limited to: tombstoning; response to PhoneApplicationService events (Launching, Activated, Deactivated, Closing)"

The application life cycle on Windows Phone is one of the most discussed topics of the platform; especially the topic of tombstoning seems both of particular interest to many, and often misunderstood. In reality, it's not that difficult: on Windows Phone, only one application is allowed to run at a time. This means that whenever the user navigates away from your application or it is interrupted otherwise, it will be terminated. The operating system keeps track of some information about the terminated application, like the currently visited page and the navigation back-stack. It is this process of deactivation and termination that is called tombstoning. Your responsibility as a developer is to make use of the events the PhoneApplicationService class provides to signal deactivation and activation to create a seamless experience for the end-user. This means: when your application is deactivated (and potentially tombstoned), you have to manually persist the state of your application that is not automatically stored by the OS, and when it is activated again, you have to restore this state to give the user the impression that no termination happened at all. The reason for tombstoning of course is to optimize battery life and performance. Note: I'm not going into details about the new "Dormant" state in the Mango update – the process and concepts of tombstoning are not affected by this new feature.

What has probably caused some confusion among developers is the fact that in reality, deactivation and tombstoning are not the same. In some situations and for some choosers your application will not necessarily get tombstoned. This often is only logical: if you launch a camera capture task for example, there's really a high probability the user will return to your application, so tombstoning is deferred. Only if the user decides not to go back and instead e.g. open another application from there, tombstoning will eventually kick in. Another confusing detail is that there's a differentiation between transient storage to temporarily store data that you want to restore only in case your application is re-activated from tombstoning, and persistent storage for that kind of data that is vital and needs to be kept even if your application never returns from its tombstoned state (… but is started as a new instance from the start screen later on). We have learned about this differentiation in part 1.

An important thing to know is that an application only has a limited time to finish handling any of the involved events (Launching, Activated, Deactivated, Closing). If it hasn't finished after 10 seconds, it will be silently terminated. Therefore it is important to pay attention to this detail and optimize e.g. the process of data persistence during the deactivation and closing process (for example, you should save data incrementally as the application runs to minimize the efforts here).

• MSDN: Execution Model Overview for Windows Phone – Note that the "Dormant" state is specific to Mango.
• MSDN: Execution Model Best Practices – A compact list of Dos and don'ts on the topic.
• MSDN: How to articles on preserving and restoring application state as well as page state.
• App Hub: Running Your App in the Background (Tombstoning) – A sophisticated explanation of the topic.
• James Ashley: Re-examining WP7 Launchers and Choosers – An overview of what choosers defer tombstoning.
• Jaime Rodriguez: Windows Phone 7 Tombstoning – An article in MSDN magazine that contains additional remarks on potential pitfalls and further suggestions.
• Andrea Boschin: The application lifecycle

Prepare the application to meet Windows Phone 7 marketplace requirements

"This objective may include but is not limited to: Windows Phone 7 Application Certification Requirements; design for localization and globalization; plan for trial versions; work with WMAppManifest.xml; design for icon requirements for marketplace"

The Application Certification Requirements are divided into several parts:

• Application Policies: This section contains general requirements of applications in the marketplace.
• Content Policies: Lists the policies about content restrictions, for example regarding violence, adult content, logos & trademarks etc.
• Application Submission Requirements: Contains all the requirements related to the submission process, for example regarding the XAP file size and code validation. It also contains a description of the language detection process and what the restrictions are for localization/globalization. Also part of this section are the requirements for application icons, screenshots and tile images. A separate paragraph describes the process of phone capabilities detection and how you can work with the WMAppManifest.xml file to make sure your application is prepared for the certification process.
• Technical Certification Requirements: This has the requirements for application reliability in it (e.g. proper exception handling), and additional information about the behavior of the back button, application responsibility, security topics, trial applications and more.
• Additional Requirements for Specific Applications: Focuses on certain types of applications, like location aware apps, software that uses the Push Notification Service and that runs under the lock screen.

It's not necessary to memorize all these requirements and know them all by heart down to every detail. However, you should have at least thoroughly read through them and remember the most essential and common parts and key values. It's a good idea to go over them once more before you start implementing a special feature, and before you submit your application. Over time you will reach a great level of understanding and knowledge of the requirements automatically; at that point you will see that a bell rings in the back of your head automatically when you read something somewhere and remember the docs have some policy for that in it.

Some of the requirements are just common sense (e.g. that your application cannot contain viruses or that you are not allowed to prevent the user from using phone features), others are simply arbitrary decisions that had to be made at some point when Microsoft defined the requirements (like the exact time limits your application must obey to until it shows a splash screen or responds to user input). In some cases the same information can also be found in the normal MSDN documentation and other places repeatedly, which also helps to internalize them (for example the how to articles about creating splash screens or screenshots again list information from the submission requirements section etc.).

• MSDN: Globalization and Localization for Windows Phone
• MSDN: Application Manifest File for Windows Phone
• MSDN: Creating Trial Applications for Windows Phone
• MSDN: Publishing Applications to the Windows Phone Marketplace
• The Windows Phone Developer Blog: Ready for take-off? – A ten part article series about things to check when you think you are done with your application.
• App Hub: Publishing Your Application in the Marketplace  - Comprehensive article with lots of additional links to further resources on the topic.

Summary

A good amount of this part was about analyzing and optimizing your application. There are quite a few helpers and tools you can make use of to get an idea of where bottlenecks are, and then optimize your code to utilize features like the threading options of the Windows Phone platform to get rid of them (this situation will even improve with the Mango update and its advanced profiling features). We've also covered the execution model, particularly the famous tombstoning mechanism, and finally dealt with the certification requirements you need to comply with to get your application into the marketplace. This concludes part 4, and leaves us with only one topic left for the final part.