Arik Poznanski's Blog : Windows Phone 7

Using Windows Phone As Windows 7 Accelerometer Sensor

arik — Sat, 13 Aug 2011 15:54:20 GMT

I just had a cool idea! (actually I had it like 6 month ago, but bear with me).

My idea involves mixing some of the features in Windows 7 with some of the features in Windows Phone 7, to create a glorious mix!

Windows 7

One of the new features in Windows 7 is the Sensor API which provides a standard interface for accessing sensors of various types, like accelerometer, etc..

I wrote in the past about how you can consume this API from a C# application using Windows API Code Pack.

Windows Phone 7

Windows Phone 7 comes with a few sensors out of the box, among them: accelerometer!

Idea

What if we use Windows Phone 7 accelerometer sensor as a standard device on Windows 7?

Roadmap

So how can we accomplish that? let's break the idea to steps:

Step 1: Create a software driver

I’ll start with creating a dummy software driver. This driver will implement what's necessary to be a standard Windows 7 Accelerometer sensor, but at this stage will simply return constant data.

In order to write a sensor driver for Windows 7 I’ll need to use User Mode Driver Framework (UMDF), a COM-like, C++ framework for writing user-mode drivers in Windows 7.

Step 2: Transfer Windows Phone 7 sensor data into the PC

The next step is to find a way to transfer the accelerometer data from a Windows Phone device into the PC. One possible way of doing this implementing a local WCF service on the desktop that the Phone will keep calling with accelerometer data. This will require an application to run on the phone to keep the data flowing.

Step 3: Consume the WCF service from the phone

Using the service from the previous step we can now consume it in a simple Windows Phone application that all it does is getting the accelerometer sensor data using the phone API and call the WCF service with the latest data.

Step 4: Make the software driver consume the Windows Phone 7 data

Now that I have a software driver that returns dummy accelerometer data and a way to get real accelerometer data from the Windows Phone, all I need to do is connecting the dots and make my accelerometer driver return the real data. To do this I'll need some kind of inter process communication to transfer the data from the WCF service to the driver.

Long Story Short…

I present to you the Windows Phone Accelerometer Driver for Windows 7!

The full source code for this project can be found on the CodePlex project site.

Some Implementation Details

The actual driver was fairly easy to implement since I used the CodeProject article "Writing a Sensor Driver for the Wiimote on Windows 7" by Rajasekharan Vengalil as a base for my Windows Phone 7 driver. You can find the driver source code in the project named WP7AccelerometerDriver.

As mentioned earlier I've implemented a simple local WCF service for transferring the accelerometer data from the phone to the driver. You can find the service source code in the project named WP7AccelerometerService. The service uses named pipes to communicate with the driver.

The phone application is a very simple one that consumes the WCF service and call it whenever a new accelerometer value is available. You can find its source code in the project named WP7AccelerometerClient.

Finally, if you want to check the functionality of the accelerometer driver you can use either the SensorDiagnostics project or the more fun PlaneDemo project, which I borrowed for Sergey Zwezdin blog.

How to Install?

1. Download and extract project binaries or source from the CodePlex project site.

2. Open CMD as administrator

3. Go to the folder \Driver\Install\

4. According to the bitness of your OS Run install_wp7_driver_32bit.bat or install_wp7_driver_64bit.bat to install the driver.

5. When the following notification appears, select "Install this driver software anyway":

This should take around 1-2 minutes to complete.

6. Enable installed Sensor in the Control Panel

7. Run the WCF service from as administrator. If you run it from Visual Studio, make sure you ran Visual Studio as administrator.

8. Run the Windows Phone client on a real device while connected to the PC and enter your PC (LAN) IP

9. That's it! you can now sit back and enjoy the ride using the PlaneDemo application or SensorDiagnostics, or any other software that uses the accelerometer sensor.

How to Uninstall?

If you want to uninstall the driver simply go to the Device Manager, select the "WP7 Accelerometer Sensor" device from the Sensors category, select uninstall from the context menu and make sure you mark the checkbox to delete the driver.

Final Note

I've seen the project works both on a real device and using the phone emulator, however it's not a one-click install. I expect users to have problems with the installation. If you encounter some problems, please post on the CodePlex project site forum page and I'll do my best to help.

Also, if you want to improve the source code (maybe adding GPS support?) or the installation procedure, I'll be happy to include your improvements and even include you as one of the project members on CodePlex.

This project was pure fun since it combines many useful technologies to create real value. Among the technologies you can find: C++, COM, UMDF, C#, WCF, WP7, etc..

That's it for now,
Arik Poznanski.

Windows Phone Tutorial Published [HEB]

arik — Thu, 04 Aug 2011 21:09:31 GMT

I've recently published a 41 chapters tutorial in Hebrew about developing application using Windows Phone. The tutorial is hosted on the great Hebrew developers community site: WebMaster.org.il

The tutorial is based on Windows Phone Mango and it teaches Windows Phone development from the first step, using Visual Studio 2010 Express, provided freely by Microsoft.

Following is the index for all chapters:

Coming next: A Silverlight guide and a WPF guide (with technology specific details and screenshots).

That's it for now,
Arik Poznanski.

Sela Developer Days 2011 – Save the Date!

arik — Fri, 20 May 2011 18:04:28 GMT

Sela Technology Center is proud to present Sela Developer Days 2011 which will be held on June 26-30.

One stage - hottest topics - Israel and world lead experts.
A rare opportunity to hear all about the next big things in our technological world.

25 full-day workshops
15 lead experts
5 days

You can find the full agenda on the conference website.

Although I recommend ALL the lectures, I believe my blog readers will most enjoy the following workshops:

26/06 Silverlight 5 by Alex Golesh
27/06 LOB Application Development with Silverlight by Alex Golesh
28/06 Introduction to Windows Phone 7 by Tomer Shamam
29/06 Windows Phone Mango by Alex Golesh
30/06 WPF and Silverlight - Smart Client Architecture Deep Dive with MVVM and Beyond by Elad Katz

See you there!

That's it for now,
Arik Poznanski.

Managing Tombstone State in a Windows Phone 7 Application

arik — Sun, 01 May 2011 13:07:07 GMT

Before we continue, I trust that you know exactly the meaning of tombstone state in a Windows Phone 7 application. If this is not the case, simply read Yochay’s great posts on the application execution model (Part 1, Part 2, Part 3).

Every Windows Phone 7 application needs to manages tombstoning correctly to provide a better user experience and pass the application certification requirements.

When your application goes into tombstone state, it is your responsibility to save all the application and page state, so that when the page gets reloaded it can recover properly and reload the previous data. This was the user doesn’t even realizes that the application process got terminated and reloaded.

To ease the handling of the tombstone state I’ve created a simple StateManager class which helps serializing the data when going into tombstone state and deserializing the data when you get back.

How to Use StateManager?

Suppose your current page has the following data members you want to save across tombstoning:

LastPosts
Posts
Comments
Images

Now all you need to do is to save them when the application goes into tombstone state and reload them when it gets back from tombstone state.

Saving the Data

The proper place for the code that saves the data resides in the OnNavigatedFrom method. In this method you should call the helper extension method SaveState for each member of the page that you want to save, passing the value and the key on which to save it:

protected override void OnNavigatedFrom(NavigationEventArgs e)
 {
     this.SaveState("LastPostsKey", LastPosts);
     this.SaveState("PostsKey", Posts);
     this.SaveState("CommentsKey", Comments);
     this.SaveState("ImagesKey", Images);
 }

Loading the Data

The proper place for the code that loads the data when returning from tombstone state resides in OnNavigatedTo method. In this method you should call the helper extension method LoadState for each member of the page that you want to load, passing the key related to the member’s value:

protected override void OnNavigatedTo(NavigationEventArgs e)
 {
     LastPosts = this.LoadState<ObservableCollection<RssItem>>("LastPostsKey");
     Posts = this.LoadState<ObservableCollection<RssItem>>("PostsKey");
     Comments = this.LoadState<ObservableCollection<RssItem>>("CommentsKey");
     Images = this.LoadState<ObservableCollection<ImageItem>>("ImagesKey");
 }

Definition of StateManager

So how is the StateManager class defined? It is as simple as the following two extension methods:

/// <summary>
 /// State Manager
 /// </summary>
 public static class StateManager
 {
     /// <summary>
     /// Saves a key-value pair into the state object
     /// </summary>
     /// <param name="phoneApplicationPage">The phone application page.</param>
     /// <param name="key">The key.</param>
     /// <param name="value">The value.</param>
     public static void SaveState(this PhoneApplicationPage phoneApplicationPage, string key, object value)
     {
         if (phoneApplicationPage.State.ContainsKey(key))
         {
             phoneApplicationPage.State.Remove(key);
         }
 
         phoneApplicationPage.State.Add(key, value);
     }
 
     /// <summary>
     /// Loads value from the state object, according to the key.
     /// </summary>
     /// <typeparam name="T"></typeparam>
     /// <param name="phoneApplicationPage">The phone application page.</param>
     /// <param name="key">The key.</param>
     /// <returns>The loaded value</returns>
     public static T LoadState<T>(this PhoneApplicationPage phoneApplicationPage, string key)
         where T : class
     {
         if (phoneApplicationPage.State.ContainsKey(key))
         {
             return (T)phoneApplicationPage.State[key];
         }
 
         return default(T);
     }
 }

Note: this code was first published as part of the “Using Pivot and Panorama Controls” lab found in the Windows Phone Training Kit for Developers, which I wrote for Microsoft.

That’s it for now,
Arik Poznanski.

MIX 2011: Enhanced Push Notifications and Live Tiles for Windows Phone

arik — Fri, 15 Apr 2011 14:58:38 GMT

This session was delivered by Thomas Fennel, Program manager, from Microsoft.

Thomas stated his session by showing what push notifications and tiles are.

Push notification is how you can engage the user when your app is not on the foreground. Tiles are the squares on the Windows Phone home screen.

Toast notifications – on the top.

Tile notifications – most popular – includes data for count, title (of app or arbitrary string) and background image.

Then, Thomas explained the normal architecture for a push notification application:

Following are the typical scenarios / applications that you would want to use push notifications:

This includes:

Weather apps
Send to WP7
Turn based games
Twitter clients
Traffic map
etc.

Thomas then continued with several code samples of these technologies.

That’s it for now,
Arik Poznanski.

MIX 2011: Sensor and Camera Access in the Next Version of Windows Phone

arik — Fri, 15 Apr 2011 12:51:10 GMT

This session was delivered by Mark Paley, Principal Lead Program Manager from Microsoft.

The next version of Windows Phone will support a few new sensors, like Gyro and Compass sensors.
Mark started the session by showing several camera and sensors demo.

Some common usage scenario:

Sudoku solver
Barcode scanner
Custom photo application
etc.

So, what sensors are supported?

Accelerometer – standard on all windows phone devices, provides acceleration data over 3 axis
Compass – gives magnetic heading
Gyroscope – gives rotation velocity (in radians per second) over 3 axis

Mark showed a simple compass application:

And explained the compass measures bearing coordinate system.

Then Mark presented the new Motion sensor, which is basically all the sensors combined with some math and an easy interface.

The motion sensor is the recommended sensor to use, if available.

What it does is it combines the data from all 3 sensors (gyro, compass, accelerometer) to give more accurate information. Since every sensor has it’s own (different) stability problems, we can use all the data combined to eliminate correct the data.

Mark also showed a nice demo of using the motion sensor and how it improves the stability of the measured data.

The motion sensor provides its data in 3 representation:

Euler angles
Rotation matrix
Quaternion

All the sensors have similar API. They all got an IsSupported property, i.e. Accelerometer.IsSupported, Compass.IsSupported, Gyroscope.IsSupported

To use any of the sensors, one needs to create an instance of the sensor, register for the CurrentValueChanged event and start the sensor by using the Start() method.

The compass sometimes needs calibration and thus has a Calibrate event which is raised when needed.

Also, all sensors have a TimeBetweenUpdates setting which controls how often does the event gets generated.

The accelerometer sensor also supported a polling mode where one can use the property accelerometer.IsDataValid and get the current value using accelerometer.CurrnetValue.

Then, Mark showed another demo, this time using the motion sensor and XNA.

So, when you shouldn't use the motion sensor?

When you want data specific to the sensor reading
When you want to do advanced usages like custom motion algorithms or gestures detection
When Motion.IsSupported is false. Note, the motion sensor will work even without a hardware gyroscope sensor

Next, Mark started to talk about the camera sensor.

He showed some demos and presented two ways of using the camera sensor:

Using the PhotoCamera class, which is new in the next version of Windows Phone
Using Silverlight 4 WebCam API, ported from desktop SL, with a few features specific for phone

So, when should you use each API?

You should use the PhotoCamera class when you:

Want to take high resolution photos
Want to handle the hardware camera button
Want to handle focus and flash

You should use the WebCam API when you:

Want to reuse Silverlight 4 knowledge
Want to easily target desktop and phone
Want to record video and audio into a file

Next Mark showed another camera demo, using the PhotoCamera class which has the following APIs:

ButtonHalfPress event – raised when the camera hardware button is half pressed
ButtonFullPress event – raised when the camera hardware button is fully pressed
ButtonRelease event – raised when the camera hardware button is released
CaptureCompleted event – raised when the capture of an image is completed
camera.Focus() method – will cause the camera to focus
camera.CaptureImage() method – will starts to capture an image from the camera sensor

A few more things that are good to know:

Most scenarios requires hardware for debugging, only accelerometer and location have an emulator
Motion sensors will try to return a result, even if not all 3 sensors exists
The camera video output is MP4

That’s it for now,
Arik Poznanski.

MIX 2011: What’s New in the Windows Phone Developer Tools

arik — Thu, 14 Apr 2011 16:17:23 GMT

This mini-session was delivered by Vibhor Agarwal, Senior Program Manager from Microsoft.

Vibhor presented only the new Emulator enhancements and the new profiler provided in the next version of the developer tools.

Some of the new emulator enhancements:

Memory model improvements
Media support for H.264, AAC
Sensor support – Accelerometer and Location

Vibhor showed a demo about the new accelerometer emulation:

and new location emulation:

Then, Vibhor presented how one can use the new profiler to analyze a windows phone application for finding performance issues.

The profiler has two supported modes, execution profiling and memory profiling. It was suggested that the memory profiler should be used only when you are sure this is actually a problem. The starting point should be the execution profiling.

We’ve seen several different graphs, including:

Frame Rate graph
CPU usage %
Memory usage
Storyboards
Image loads

Of course, we can drill down and see how much CPU time we have spent in each function, like any normal profiler.

It should be noted that the profiler is a CPU sampling based profiler.

Also shown was the profiler analyzer that searches for common anti-patterns that developers sometimes use and recommends how to detect issues related to them.

All in all, very interesting presentation of an important tool.

That’s it for now,
Arik Poznanski.

MIX 2011: Get Ready for Fast Application Switching in Windows Phone

arik — Thu, 14 Apr 2011 16:07:35 GMT

This mini-session was delivered by Adina Trufinescu.

The agenda for this session was:

Application Resume User Experience
Application Lifecycle
Phone Resource Management
Key Developer Scenarios

Adina started by discussing the next version of Windows Phone, codenamed Mango, where there is much improvements in the area of returning to a previously active application.

To take advantage of this in your application you will need to recompile your application against the new developers tools.

Adina then explained the new application lifecycle in Mango, which includes a new “dormant” state.

This “dormant” state is another stage before tombstoning. In this state the application resources are almost entirly freed, except memory usage but the process is not closed.
So, returning from a dormant state doesn’t requires you to deserialize your data and reload state. Only if the application was actually tombstoned you must reload your state.

To know whether you came back from “dormant” state or “tombstoned” state you can check a new property named IsAppInstancePreserved.

Adina then presented exactly what kind of resources are cleaned on “dormant” state and who is in charge of getting them back once reactivated.

That’s it for now,
Arik Poznanski.

MIX 2011: Day 2 Keynotes Summary

arik — Thu, 14 Apr 2011 14:01:34 GMT

Yet another post on MIX 2011 second day keynotes.

The Keynotes started by Joe Belfiore presenting some information about how Windows Phone Updates are done.
Specifically, Joe answered the common questions:

Why the update came later than anticipated? (deployments bugs..)
Who decides when to update? (MS and the operators)

Joe stated that there are currently almost 13K apps in the Windows Phone market.
The next edition of Windows Phone Ecosystem will support 16 additional languages and up to 35 countries will be able to both publish and consume applications from the market.

The new version of Windows Phone 7 was announced, codename Mango.
Among its capabilities:

Internet Explorer 9 on the phone, with the same HTML 5 support. There was a nice comparison of the mobile browsers iPhone vs. Android vs. Windows Phone Mango.
Enable custom ringtones
Improved Panorama and Pivot controls
Sockets support
Built-in SQL Server
More launchers and choosers
Calendar integration
Motion Sensor
Multi-tasking via fast application switching and running certain apps in the background.
and many more…

A Motion Sensor now wraps the complex math around the accelerometer and compass sensors.

Then Scott Guthrie came to the stage and presented some new features of the Mango developer tools like the accelerometer emulation and location emulation.

And the new Windows Phone profiler that will come free as part of the developer tools.

Scott also presented many performance optimizations that where done in the Mango operating system, specifically in the following areas:

Getting user input while scrolling
Decoding images loaded from the net
Garbage collection
Memory usage

Also in Mango, support for Silverlight 4, this is a nice improvement that didn’t got enough attention, IMHO.

Next Silverlight 5 Beta was announced to be available for download.

Silverlight 5 presents many new features, among them:

Media improvements (hardware accelerated decoding)
New 3D XNA-based APIs
Binding in style setters
Implicit data template
Data binding debugging
and more…

Finally, the Kinect SDK for Windows was announced with a small surprise: every MIX attendee will get a free Kinect sensor to play with at home…

That’s it for now,
Arik Poznanski.

MIX 2011: Deep Dive MVVM

arik — Wed, 13 Apr 2011 16:26:18 GMT

This session was delivered by Laurent Bugnion, the creator of MVVM Light.

In this session Laurent talked about advanced MVVM topics that every WPF/SL developer face sooner or later.

Laurent used a demo application an showed how to solve some common issues.

For example, how can one share view-models between several different platforms (Silverlight / WP7), short answer: add shared files as links.

Also discussed: what strategy should be used to create view-models and exposes them. Short answer: Either create them in advance and expose them as properties or generate them on the fly, this is of course scenario-dependent.

Laurent also discussed the ancient MVVM question of how can one open a dialog from the view-model (short answer: IDialogService), or navigate from the view-model (S.A.: INavigationService) or invoking animations from the view-model (S.A.: States + Behaviors).

Finally Laurent discussed some common issues when unit-testing view-models.

All in all, it was an excellent lecture. It’s always nice to see top developers struggles with the same issues you face on the everyday. And if you have the same solution that’s also something..

That’s it for now,
Arik Poznanski.

Shake Gestures Library – A Windows Phone Recipe

arik — Sat, 02 Apr 2011 03:34:51 GMT

Note: the following article was first published as part of the Windows Phone Recipe “Shake Gestures Library” found here, which I wrote for Microsoft, together with Yochay Kiriaty.

Document Purpose

This document introduces a helper library for identifying shake gestures by using the accelerometer built into Windows Phone 7 devices. It explains how to use the library, how the library works internally, and how you can configure the library’s parameters to adapt gesture detection to your needs.

Library Features

The shake gestures library uses the accelerometer to detect movement in three directions:

Left-Right (X direction)
Top-Bottom (Y direction)
Forward-Backward (Z direction)

If you’re looking for a general purpose shake gesture and don’t care about the direction of the gesture, then you can simply use any combination of one or more of the supported gestures. However, sometimes you need to have better control and to understand if the gesture was in the “right” direction.

How to Use the Shake Gesture Library

Since the shake gesture library is doing all the heavy lifting for you, using the library requires very little effort from you.

Step 1: Add reference to shake gestures library: ShakeGestures.dll

Step 2: Add a using statement to file header

using ShakeGestures;

Step 3: Register to ShakeGesture event

// register shake event
 ShakeGesturesHelper.Instance.ShakeGesture += new EventHandler<ShakeGestureEventArgs>(Instance_ShakeGesture);
 
 // optional, set parameters
 ShakeGesturesHelper.Instance.MinimumRequiredMovesForShake = 5;

Step 4: implement the ShakeGesture event handler from step 3

private void Instance_ShakeGesture(object sender, ShakeGestureEventArgs e)
 {
     _lastUpdateTime.Dispatcher.BeginInvoke(
         () =>
         {
             _lastUpdateTime.Text = DateTime.Now.ToString();
             CurrentShakeType = e.ShakeType;
         });
 }

The ShakeGestureEventArgs holds a ShakeType property that identifies the direction of the shake gesture.

Finally, you need to activate the library, which binds to the phone’s accelerometer and starts listening to incoming sensor input events.

// start shake detection
 ShakeGesturesHelper.Instance.Active = true;

Note: You can continue working directly with the phone’s sensor. The ShakeGesturesHelper class doesn’t block any sensor events—it just listens to them.

Note: The ShakeGesture event arrives on a thread different from the UI thread, so if you want to update the UI from this event you should dispatch your code to run on the UI thread. This can be done by using the method myControl.Dispatcher.BeginInvoke(), where myControl is the control you want to update.

How Does the Shake Gesture Library Work?

We need to figure out what a shake gesture is and how to identify a shake when it occurs. Then we need to classify the shake according to the gesture direction.

The accelerometer sensor in a Windows Phone measures the gravity forces applied on the phone and reports an AccelerometerReading event about 50 times per second. When you move the phone up and down in 3D space, you’re getting a lot of readings (the sensors are quite noisy), and you don’t really know the phone’s orientation or the distance that the phone moved, since all you have are changes in the relative gravity force on the phone during a given period of time.

With that in mind, we set out to create a simple, high-performance shake gesture library, and came up with the following shake gestures detection process:

Noise reduction
Segmentation into "Shake" and "Still" signal segments
Shake direction classification

We report sensor readings as vectors, since we obtain 3-axis readings (X, Y, and Z, with each having a double value associated with it). We can set the initial point to (0, 0, 0), hence a vector.

Noise Reduction

Before performing gesture detection, the noise must be removed from the accelerometer’s input vectors. This is done by passing the raw input vectors through a low-pass filter. This smooth the signal so that it ignores small changes and only takes into account any “large enough” changes. We’re using an existing noise reduction implementation by Dave Edson. For more details on Dave’s algorithm, check out this blog post.

Figure 1: Before noise reduction

Figure 2: After noise reduction

As you can see, the signal after noise reduction is much cleaner and easier to work with.

Segmentation into Shake and Still Signal Segments

After cleaning the signal, our next step is to separate shake and still segments. Basically, we want to identify shake segments when the following conditions are satisfied:

The magnitude of one or more of the vectors (X, Y, or Z) crosses a certain threshold.
The vector stays above this threshold long enough so that we don’t mistake a one-time blip for a shake.

Note: We don’t use a system timer to measure time. Instead, we depend on the fact that the Windows Phone sensor generates about 50 events per second, so the time between each event is around 20 msec. Therefore, five events total roughly 100 msec. You’ll see in the code that we measure event intervals and not real world clock time.

Figure 3: Signal segmentation

Ignore for a second how we calculate vector magnitudes; we’ll address that topic in the next section. For now, look at Figure 3. You can see from the green line pattern that it’s very clear when the phone was in a shake segment and when it was in a still segment. Therefore, our goal is to be able to understand when a series of vectors represents a shake segment. Once we identify a shake segment, we’ll further process it to extract the shake type and raise the shake event.

Calculating Gravitation Vectors

To start with, we need a reference point that reflects the still state of the phone. The Still segment is used to compute something we call the last-known-gravitation-vector. The last-known-gravitation-vector will be used later to eliminate the effect of gravitation when classifying the shake type.

Note: We can't assume that the gravitation vector will always have the value (0,-1, and 0) for two reasons:

Gravity isn’t exactly 1G everywhere on earth. It varies somewhat according to location and altitude.
The direction of the gravity vector depends on how you hold your phone. If you rotate it, the direction varies. If you’re moving, your hand direction varies.

To calculate the gravitation vector, we take the most recent vectors in the still signal (MaximumStillVectorsNeededForAverage parameter) and average the vectors that have very low magnitude (StillMagnitudeWithoutGravitationThreshold parameters. In case we don't have enough still vectors for a representative sample (MinimumStillVectorsNeededForAverage parameter), we abort the calculation, since we won't get a valid gravitation vector.

The gravitation vector is re-calculated for each new still segment that we get, to account for any changes in how you hold your phone. Remember that we’re looking for real time effects; therefore, we need to maintain an accurate state of the current gravitation forces that are affecting the phone.

Finding Signal Boundaries

Now, let’s assume the user starts shaking his phone. We need to find the shake segment starting and ending points. To do so, we use the following algorithm:

There are only two possible states:

Shake state – Indicates that we’re currently in the middle of a shake signal
Still state – Indicates that we’re currently in the middle of a still signal (that is, not in the middle of a shake signal)

Based on the current state and the input vector type, we decide what the next step is. Each time we get a new input vector from the accelerometer (after noise reduction), we check whether the vector magnitude is equal or larger than a certain shake threshold ShakeMagnitudeWithoutGravitationThreshold parameter. If it’s larger, then this input vector is addressed as a potential shake vector. Otherwise, it’s considered a still vector.

Per each input vector and the current “shake” state we use the following state-machine to determine the next state…

Condition: The current state of the phone is still, and the new vector has a still magnitude value.
Operation: Add the vector to the still signal array (the array is a cyclic array).
Condition: The current state of the phone is still, and the new input vector has a magnitude that is higher than the minimum shake threshold.
Operation: Set shake state, process still signal, add vector to shake signal array (this doesn’t mean that we identified a shake, we’re just adding it to the array for further processing later).
Condition: The current phone state is shake, and the new input vector has a shake magnitude.
Operation: Add vector to shake signal, try to process shake signal array. Here we’re actually trying to identify a shake, since we already got a few shake vectors in the array. Again, we need to wait for the minimum amount of shake vector before we can start processing a shake single.
Condition: The current phone state is shake, and the new input vector has a still magnitude (it’s below the minimum shake magnitude).
Operation: Add vector to shake signal, unless we’ve already received too many sequential still vectors (StillCounterThreshold parameter), in which case move the still vectors to the still signal and change the phone state to still state.

Shake Type Classification

It’s time to dive into the actual vector processing. The following describes the algorithm we’re using, but for performance reasons the code performs some of the processing while the shake vectors are being collected, but the idea remains the same.

Neutralizing Gravitation Effects (Removing Earth Gravity Effects)

All input vectors include the earth’s gravitation forces. And since we don’t have any idea about the position of your phone in 3D space, we don’t know which of the vectors (X, Y, or Z) is affected by the earth’s gravity. Therefore, we need to remove the earth’s gravity effect.

To eliminate the effect of gravity, we first reduce the last known gravitation vector from all the vectors in the shake signal. In this way, when we get acceleration in some axis we can be certain that the user moved the phone along that axis instead of wondering whether this is just the force of gravity trying to fool us. Therefore, for each input vector we’re subtracting the last known gravity vector.

Finding Shake Main Direction

Now we want to find the main direction of the shake signal, which can be one of the following three directions:

X (left-right)
Y (top-bottom)
Z (forward-backward)

To do this, we first need to find the main direction of each vector in the shake signal. We do this by checking which of the vector products has the biggest absolute value. To get a better feeling of why we’re breaking the vector into its products, let’s review a 2D vector. As you can see in Figure 4, the red vector products are broken into the X and Y values [Red value = sqrt(pow(x,2) + pow(y,2))].

Figure 4: Illustration of classifying a 2D vector

It’s clear that the red vector should be classified as an X axis vector, because its X product is much stronger than its Y product. The same methodology is implemented in the library for 3D vectors.

At this stage, we’ve got a vector that isn’t affected by the earth’s gravity, we’ve broken the vector into its products, and we know the main direction of the vector.

Our next step is to create a histogram of the vectors’ products, and then to select the direction with the most products in it. Remember, we started with a vector whose magnitude is strong enough to be considering a shake vector. We removed the earth’s gravity effect, and we broke it into its distinct products, and classified them. For example, Figure 5 shows a histogram of a shake signal that has most of its vectors pointing in X direction, hence the shake signal’s main direction will be X.

Figure 5: Histogram of vector directions in a shake signal

To prevent weak vectors (WeakMagnitudeWithoutGravitationThreshold parameter) that got into the shake signal from affecting the histogram result, we’ll only consider vectors above a certain threshold when calculating the histogram.

In addition, we’ll consider the histogram result as valid only if the number of vectors in the main direction passes a certain threshold (MinimumShakeVectorsNeededForShake parameter). This will enable us to eliminate false results due to histograms done on small amounts of data.

Recognizing the Gesture

Up until now, we’ve identified a movement of the phone in 3D space that’s fast (powerful) enough to be consider a shake. Basically, we know the shake signal’s axis, but that isn’t sufficient. In order to make sure the movement we detected is really a shake gesture, and not just a random (single) movement in one direction, we need to count several intervals of movement and, more importantly, changes in the vector direction. A shake is defined as a movement of the phone on one axis back and forth a few times.

To check whether the shake signal is a shake gesture, we’ll check the sign of the main direction coordinate. For example, if we found that the main direction of our shake signal was X, then we’ll inspect the sign of the X products of all the vectors in the signal. On a real shake gesture, we expect the sign to change a few times, since we move the phone back and forth and thus keep changing the force (acceleration), which translates to a direction change.

For example, in the following figure we see a normalized (without gravitation) shake signal of a real shake gesture. You can clearly see the main direction being Z, and the Z values go back and forth between positive and negative.

Figure 6: Example of a shake vector

In order to identify the gesture, we’ll count how many times the X values goes from positive to negative and back. If the count is bigger than MinimumRequiredMovesForShake, we’ll finally raise the shake gesture event!

Configuring Parameters

During the coding and testing of the library, we found that shake is very individualized. It depends on the nature of the application and the actual shake gesture made by the phone’s user. There are alternative algorithms available that are adaptive and learning algorithms. While these might be more accurate, they require a learning phase that we didn’t want to force on the end user and on the developer building the app. Therefore, we give you plenty of different properties to tweak and tune for your own purposes.

These parameters control various aspects of the gesture detection algorithm. By changing these parameters, you can change your application’s sensitivity to shakes and to the duration of a shake. All parameters have default values kept as constants in the library.

The following section describes the available parameters. Each parameter is mentioned in context in the above algorithm.

ShakeMagnitudeWithoutGravitationThreshold

Description: Any vector that has a magnitude (after reducing gravitation force) bigger than this parameter value is considered as a shake vector.

Default value: 0.2

StillCounterThreshold

Description: This parameter determines how many consecutive still vectors are required to stop a shake signal.

Default value: 20 (about 400 msec)

StillMagnitudeWithoutGravitationThreshold

Description: This parameter determines the maximum allowed magnitude (after reducing gravitation) for a still vector to be considered.

Default value: 0.02

MaximumStillVectorsNeededForAverage

Description: The maximum number of still vectors needed to create a still vector average. Instead of averaging the entire still signal, we just look at the top recent still vectors. This is performed as runtime optimization.

Default value: 20

MinimumStillVectorsNeededForAverage

Description: The minimum number of still vectors needed to create a still vector average. Without enough vectors, the average won’t be stable and thus will be ignored.

Default value: 5

MinimumShakeVectorsNeededForShake

Description: Determines the number of shake vectors needed in order to recognize a shake.

Default value: 10

WeakMagnitudeWithoutGravitationThreshold

Description: Shake vectors with a magnitude lower than this parameter won’t be considered for gesture classification.

Default value: 0.2

MinimumRequiredMovesForShake

Description: Determines the number of moves required to get a shake signal.

Default value: 3

Summary

In this document we showed how you can use the Shake Gestures Library in your application. We did an in-depth tour of the algorithms used for recognizing shakes. Finally, we skimmed through the various parameters that you can change to better fit gesture detection to your application’s needs.

Shake it up!

That’s it for now,
Arik Poznanski.

Ways to Load Applications Faster – A Windows Phone Recipe

arik — Fri, 25 Mar 2011 05:05:12 GMT

Note: the following article was first published as part of the Windows Phone Recipe “Ways to Load Applications Faster” found here, which I wrote for Microsoft, together with Yochay Kiriaty.

Purpose of This Document

This document introduces the loading procedure for Windows Phone Silverlight applications. It explains common mistakes that application developers make during application launch, and how those errors can increase the total application load time and harm the user experience. Next, this document describes some possible solutions for overcoming long load times and explains their implementation.

Application startup is also discussed in Performance Considerations in Applications for Windows Phone. That paper provides excellent background information and can help make your Windows Phone applications shine.

Windows Phone Application Flow: Launching, Running, and Closing

We can't talk about proper loading techniques and optimizing application startup time without explaining Windows Phone application lifetime events. The following section providers a short overview; for more detailed information, see Execution Model for Windows Phone.

Windows Phone provides developers with a series of events and APIs for handling tombstoning and other application state changes, which include launching and closing. The PhoneApplicationService class, found in the Microsoft.Phone.Shell namespace, provides access to various aspects of the application’s lifetime, including management of the application’s state when it becomes active or inactive.

The PhoneApplicationService class exposes four main lifetime events. For any auto- generated Windows Phone application (generated by Visual Studio 2010 Express for Windows Phone or Visual Studio 2010), the App.xaml.cs file includes four methods directly related to the execution model. These methods are your application handlers for the lifetime events exposed by the PhoneApplicationService class:

Application_Launching
Application_Activated
Application_Deactivated
Application_Closing

The names of these methods are self-explanatory. However, there are some subtleties that we need to cover:

Application Launching – A Windows Phone application is considered to be launched when it’s started by a means other than by the user pressing the Back button to return to a previous application. An application is launched when the user taps the entry for the application in the phone’s applications list or the tile for the application on Start. An application can also be launched when the user taps a toast notification.
Application Deactivated occurs when a different application takes control of the foreground; for example, when the user launches a chooser or presses the Start button. In both cases, your application will be deactivated; the Deactivated event is raised, as opposed to the Closing event when your application exits. However, unlike an application that’s closed, a deactivated application will most likely get tombstoned. Don’t become confused: A tombstoned application’s underlying process still gets terminated, so your application does “close.” But unlike a closed application (which has exited), where the Windows Phone operating system removes any trace of the application from memory, in the deactivated scenario the Windows Phone operating system stores a record (a tombstone) of the application's state. Basically, the Windows Phone operating system keeps a tombstone of the application that becomes part of the phone’s application back-stack, which is a journal that enables the use of the Back button to enhance navigation functionality.
Application Activated – After an application has been deactivated, it’s possible that it will never be reactivated. However, it’s also possible that the user will return to the application by pressing the Back button enough times to reach the application. When the user returns to a deactivated application, it’s reactivated and the Activated event is raised. Windows Phone then navigates to the last page viewed by the user in order to give the user the feeling that the application is simply continuing. Note that unlike Launching, some data objects in an Activated application might still be initialized.
Application Closing is simply the outcome of the user pressing the Back button enough times to navigate backwards through the pages of your application, and past the application’s first page. Currently, this is the only way for a user to exit your application. Once your application is closed, its process is terminated, the operating system removes any trace of that application from its memory, and there’s no way to return to the application other than by launching a new instance.

Note that Launching and Activated events are mutually exclusive, as are the Deactivated and Closing events.

These events play a critical role in your application’s loading and closing times. Loading time also applies during application tombstoning and, more importantly, for applications resuming from tombstone.

One last note before we continue. There’s a certain sequence of methods that gets called during launching and tombstoning. This method sequence is critical for optimizing load time operations.

For the most part, when your application is launching or returning from tombstone, the following methods are being executed in the following order:

Application constructor –App() found in App.xaml.cs
Application launching – Application_Launching found in App.xaml.cs
Your application’s “first page” constructor
Your application’s “first page” OnNavigatedTo method

Note: When returning from tombstone, the “first page” is the last page the application was showing, and not necessarily the actual first page of the application.

Note: When your application returns from a tombstone state, this entire sequence is executed. However, in cases where tombstoning is relaxed, and your application is deactivated but not tombstoned, the Application constructor and the Page constructor aren’t executed. For additional information about Application Lifetime events and tombstoning, see Execution Model for Windows Phone.

Application launch time is defined from the time Windows Phone loads your application into memory and starts executing the application constructor (the first method in the sequence) until the end of the execution of the OnNavigatedTo method first page.

Startup and Shutdown Times

Windows Phone enforces a series of time limits on application startup and shutdown in order to preserve a consistent and responsive user experience across the phone’s built-in applications and 3^rd-party applications. If your application exceeds the allowed time for startup or shutdown, it will be forcibly terminated and removed from the back-stack. This means your application doesn’t get tombstoned, it’s simply terminated, and the user can’t use the back button to reactivate it. The following table outlines launch shutdown, deactivated, and reactivated times:

Table 1-1. Application Startup / Shutdown times

Application Event	Limit
Starting the application (application Launching event)	10 sec
Forward navigating away from the application (application Deactivated event)	10 sec
Returning to the application using the Back key (application Activated event)	10 sec
Exiting from the application (application Closing event)	10 sec

You can see that you have up to 10 seconds of real-world time (this doesn’t mean that you have 100% of the CPU for 10 seconds) to handle each application lifetime event. If for some reason your code takes longer than 10 seconds to execute, the Windows Phone system will terminate your application.

Note: Besides the operating system safeguards, part of the Marketplace ingestion process is to check the time it takes to launch and to return from tombstoning. The user experience guidelines are even stricter, and require less than 10 seconds to properly launch your application. According to Windows Phone 7 Application Certification Requirements, the application must render the first screen within five seconds after launch, even when there’s a splash image. Therefore, optimizing and understanding the load sequence are critical to your application’s success.

Startup time – Includes launching or returning to a tombstoned application. It’s the time from when your application process starts executing until your application becomes active or visible. Your application becomes visible only after the execution of the OnNavigatedTo method ends of the page the application navigates to upon launch or returning from tombstoning. Until then, the application’s splash screen is displayed and the application isn’t considered active.
Shutdown time – Includes deactivating and exiting from the application, and mostly consists of the time from when the forward navigation was invoked until the Deactivated or Closing methods execution ends.

Demonstrating the Problem

As explained in the previous section, the application must complete its loading and display its first page (or any page when returning from tombstoning) within 10 seconds or the OS will kill the process. Moreover, even if your application launches in five or eight seconds, you still need to optimize the user experience by loading the application and displaying something as soon as possible; otherwise, the impatient user might tap the Back or Windows button to navigate away from your application.

So let's see how easy it is to create a well-behaved application. In the following demo we’ll create a Windows Phone Silverlight application that needs to execute some long operations while loading.

Note: Our example application describes a very simple scenario for a Silverlight application that displays some information on the first page. This information should be obtained from some web service or local storage. To illustrate the problem, we create a fake workload that intentionally takes about 10 seconds to complete.

To simulate a long operation, we’ll simply trigger a function that sleeps for a second and reiterate that 10 times. (See the MyService.Init methods below.)

To experience this firsthand, simply follow these steps:

Step 1: Create a Windows Phone Application

Step 2: Create long workloads

public class MyService
 {
     private const int NumberOfIterations = 10;
 
     public static void Init()
     {
         for (int i = 0; i < NumberOfIterations; ++i)
         {
             Thread.Sleep(TimeSpan.FromSeconds(1));
         }
     }
 
     public static void Init(Dispatcher dispatcher)
     {
         for (int i = 0; i < NumberOfIterations; ++i)
         {
             if (dispatcher != null)
             {
                 dispatcher.BeginInvoke(() =>
                 {
                     Thread.Sleep(TimeSpan.FromSeconds(1));
                 });
             }
         }
     }
 }

Essentially, both methods perform the same operation: they sleep for about 10 seconds to mimic a long workload. The second Init method accepts a Dispatcher as an input parameter that we use each in sleep period. This forces a sync with the main user interface (UI) page (since that’s the dispatcher we’re passing in), as it isn’t reasonable to write code that completely blocks the UI thread for 10 seconds. Eventually, calling the dispatcher allows Windows Phone to terminate faster, as you’ll see later.

Step 3: Call the long workloads from various locations in your application

Call the function MyService.Init from either one or all five methods:

1. App constructor

public partial class App : Application
 {
     public App()
     {
         ...
 
         MyService.Init();
     }
 
     ...
 }

2. Application Launching event

This event is raised when the user launches the application by tapping on the application’s icon.

public partial class App : Application
 {
     ...
 
     private void Application_Launching(object sender, LaunchingEventArgs e)
     {
         MyService.Init();
     }
 }

3. Application Activated event

This event is raised when the user taps the Back key to return to the application, or after returning from a chooser or a launcher.

public partial class App : Application
 {
     ...
 
     private void Application_Activated(object sender, ActivatedEventArgs e)
     {
         MyService.Init();
     }
 }

4. Page constructor

This function is called when the Page class is created.

public partial class MainPage : PhoneApplicationPage
 {
     public MainPage()
     {
         InitializeComponent();
             
         MyService.Init(this.Dispatcher); //Or you can run MyService.Init();
 
     }
 
     ...
 }

5. Page OnNavigatedTo method

This function is called when the page is navigated to, either from another page or when the application gets launched/activated.

Note: The problem shown in this demo also can occur when your application comes back from a tombstone state, so you need to make sure you don't have lots of work in the constructor and OnNavigatedTo functions of any of your pages in the application.

public partial class MainPage : PhoneApplicationPage
 {
     ...
 
     protected override void OnNavigatedTo(NavigationEventArgs e)
     {
         MyService.Init(this.Dispatcher); //Or you can run MyService.Init();
 
     }
 }

Step 4: Run your application

Simply run your application from your phone and observe that the operating system terminates your application. When it terminates your application depends on specific implementation criteria, as explained below.

Note: To test whether the Windows Phone terminates your application when your application’s load time exceeds the 10-second limit, you must run your application on a real device without attaching the debugger. You need to deploy the application to the phone and then run it. Don’t run the application from Visual Studio, as when the debugger is attached (either to your Windows Phone device or to Windows Phone emulator); the relevant watchdog timers are disabled and the application will simply load after all the fake workload methods complete their task.

If you use the Init without the dispatcher, then the sleep (on the main UI thread) prevents any operations from executing on the main thread (which is the main application thread). This is rather extreme and doesn’t represent a real-life scenario. So we’ve added a call to the dispatcher during each sleep period in order to sync back to the UI thread, and give the Silverlight runtime a chance to do what it’s supposed to do (terminate your application). Therefore, you’ll notice that when calling the MyService.Init method without the parameter, the application will eventually get terminated, but only after all the sleep periods occur (depending on how many times you called the MyService.Init method). When you pass the dispatcher as an input param (this is only possible in the MainPage), you’ll notice that your application terminates faster.

Try removing the MyService.Init method from the Application constructor and Launching method, but leave them in the MainPage constructor and OnNavigatedTo methods. You’ll see that it still takes about 11 or 12 seconds for the operating system to terminate your application. This again proves that it takes only one misbehaving method to significantly impair your application’s load time.

The Solution – Optimizing Your Application Load Time

Now that you understand the Windows Phone Silverlight application launch sequence and the problem of long launch times, it’s time to present some ways to optimize your application load times.

The solution is composed of four action items:

Use a splash image
Defer work
Do work on a background Thread
Use a loading page

Action Item 1: Use a Splash Image

The first thing you can do is to help to solve the user experience issue. If the user sees an image of the application that says "Loading…", he’ll wait a few more seconds before pressing the Back key out of frustration. Therefore, be smart and use a splash screen.

In fact, all Windows Phone project templates include a splash screen image. By default, this image is named SplashScreenImage.jpg, and it automatically appears when your application is starting. The default image looks like this:

Make sure to change the default image to something that suits the theme of your application. That way, when users see the splash screen (which happens instantly), they’ll recognize it as part of your application. Changing the default splash screen is also a Marketplace requirement.

Note: The image must have:

A size of 480 by 800 pixels
The filename set to SplashScreenImage.jpg
The Build Action set to Content

Action Item 2: Defer Work

This against everything your parents taught you, but when it comes to loading an application on Windows Phone, never do now what you can do later.

Postponing non-mission-critical work until after the application loads is always a good technique. At that point you aren’t constrained by time issues, and you might have time to run workload between user actions.

For example, suppose you write a Sudoku game for Windows Phone. You might be tempted to generate the Sudoku game map when the application loads. However, it would be best to delay this action until the application is loaded and the user selects "New game." At this point you can show some nice animation during the game setup process.

You should defer any workload that isn’t critical to the application launch and doesn’t have a severe impact on the user experience when the application loads. Always prefer lazy initialization of objects, which promotes deferring non-essential workloads.

Unfortunately, not every workload in your application launch sequence can be postponed. There are certain scenarios in which you can’t defer the workload to a later time in the application or until the user performs some operation. Some scenarios require you to run a workload as close as possible to the application start time. For example, consider an application that shows the top 10 trends currently on Twitter. Without the trends information, there’s nothing real to show on the application’s main page. However, we can't afford for the application to be terminated just because it’s getting the latest trends over the network.

To address scenarios in which your application has to complete some work close to startup time, you need to run some or all of the workloads in the background. This is exactly what we explain in the next section.

Action Item 3: Do Work on a Background Thread

This is probably the most important step in optimizing your application load time. To keep your application from hanging or terminating, the launch methods sequence must complete as soon as possible. If you can't defer a certain workload, you have to run that work in the background, that is, on a background thread.

You can use the following options:

1. Manually create a thread

using System.Threading;
 
 Thread thread = new Thread(() => { MyService.Init(); });
 thread.Start();

For additional information about manually creating threads, see the Thread Class documentation.

2. Queue work item into the thread pool

using System.Threading;
 
 ThreadPool.QueueUserWorkItem((o) => { MyService.Init(); });

For additional information about using the thread pool, see the ThreadPool Class documentation.

3. Use BackgroundWorker class

By using the BackgroundWorker class, you can assign a delegate that will perform the workload, as well as a callback method that will be executed once the delegate completes its operation.

To use the BackgroundWorker class, you’ll need to add a using statement for System.ComponentModel.

using System.ComponentModel;
 
 BackgroundWorker backgroundWorker = new BackgroundWorker(); 
 
 backgroundWorker.DoWork += 
     (s,e) => 
     {
         // runs on background thread
         MyService.Init(); 
     };
 
 backgroundWorker.RunWorkerCompleted +=
     (s, e) =>
     {
         // runs on UI thread        
     };
 
 backgroundWorker.RunWorkerAsync();

For additional information about using the BackgroundWorker class, see the BackGroundWorker Class documentation

When working with a background thread, you can’t directly update any UI control without marshaling to the UI thread from your back-thread. Silverlight offers a simple mechanism to do that by using the Dispatcher.BegineInvoke method.

Deployment.Current.Dispatcher.BeginInvoke(() =>
 {
     //This happens on UI thread, if you want to marshal info back to UI thread from any other background thread.
 });

Note: When working with background threads, you should always remember that UI components in Silverlight have thread affinity; that is, you can access a control only from the thread that created the control. So if you need to update the UI with progress/completed reports from the background thread, you should dispatch your code to run on the correct thread. This can be done by using the method myControl.Dispatcher.BeginInvoke(), where myControl is the control you want to update.

Action Item 4: Use a Loading Page

Now that you’ve moved some of the workload to the background, your application will load much faster and you should see your application’s first page rather quickly. However, most likely you’ve got nothing meaningful (such as the new data you’re fetching) to show, since the background thread is still executing. Therefore, If you started some work on a background thread , you should consider showing a busy/loading indicator, like a progress bar, during the wait time.

You should avoid having a separate page for the loading indicator UI, since it would become part of the application’s page back stack. This would create a strange scenario in which pressing the Back button from the main page would return the user to the loading page rather than exiting the app.

Instead, in your main page, add a grid that contains two controls: the “loading control” that will show loading information (indicator), and the actual main page content. Toggle the Visibility property of the two controls according to the current loading state. Also, if you set the ProgressBar’s IsIndeterminate property to true , turn it off once you no longer need the loading screen, or you’ll have performance issues. You can read more about this at A ProgressBar With Text For Windows Phone 7.

For example, the following XAML shows how a main page could be structured:

<Grid x:Name="ContentPanel" Grid.Row="1" Margin="12,0,12,0">
     <Grid x:Name="loadingContent">
         <TextBlock 
             HorizontalAlignment="Center"
             VerticalAlignment="Center"
             Margin="0,-30,0,0"
             Text="Loading..." 
             />
         <ProgressBar
             x:Name="progressBar" 
             Minimum="0"
             Maximum="100"
             />
     </Grid>
     <Grid x:Name="mainPageContent" Visibility="Collapsed">
         <TextBlock 
             VerticalAlignment="Center"
             HorizontalAlignment="Center" 
             FontSize="56"
             Text="Main page data" 
             />
     </Grid>
 </Grid>

The following code shows how to use the BackgroundWorker class to do the work in the background, update the progress bar, and toggle Visibility when the work’s done:

MyService.BackgroundWorker = new BackgroundWorker()
 {
     WorkerReportsProgress = true
 };
 
 MyService.BackgroundWorker.DoWork +=
     (s, e) =>
     {
         MyService.Init();
     };
 
 MyService.BackgroundWorker.ProgressChanged +=
     (s, e) =>
     {
         progressBar.Value = e.ProgressPercentage;
     };
 
 MyService.BackgroundWorker.RunWorkerCompleted +=
     (s, e) =>
     {
         loadingContent.Visibility = Visibility.Collapsed;
         mainPageContent.Visibility = Visibility.Visible;
     };
 
 MyService.BackgroundWorker.RunWorkerAsync();

In order to receive progress updates from the background thread, we passed the BackgroundWorker to MyService class, and use the ReportProgress method:

public class MyService
 {
     private const int NumberOfIterations = 10;
 
     public static BackgroundWorker BackgroundWorker { get; set; }
 
     public static void Init()
     {
         for (int i = 0; i < NumberOfIterations; ++i)
         {
             Thread.Sleep(TimeSpan.FromSeconds(1));
 
             if (BackgroundWorker != null)
             {
                 BackgroundWorker.ReportProgress((i+1) * 100 / NumberOfIterations);
             }
         }
     }
 
     ...
 }

Another way to toggle between the controls is to bind the Visibility property of both the mainContent and loadingContent to a Boolean flag that signifies the loading state (for example, bool isLoading). To do that, you’ll need a class that implements IValueConverter to convert from bool to Visibility.

Summary

Windows Phone applications must load fast and provide a good user experience. This is enforced by the application certification process and by the operating system. While the sample provided in this article is rather simple, the concepts remain true for all Windows Phone applications, and the techniques explained here will work for any Windows Phone application.

Another important consideration is the actual versus the perceived user experience. There’s more than one way to show loading progress, other than a progress bar, but it’s important to show something that’s meaningful and tells the user,“Hey, soon you’ll see your favorite app.”

That’s it for now,
Arik Poznanski.

3-Screens Development using WPF, SL and WP7 - SDP 2011 Conference

arik — Wed, 16 Mar 2011 17:59:00 GMT

Yesterday I’ve delivered my lecture titled “3-Screens Development using WPF, SL and WP7” in the SDP 2011 conference.

In this lecture I’ve presented the application FlashCards.Show which has 3 clients in WPF, Silverlight and Windows Phone 7.

I showed how to share the code base between the different clients using:

MVVM
Adding files as links
Preprocessor symbols
OOP
Portable Library tools

Then I showed a few features that exist in WPF and don’t exist in Silverlight, and how one can overcome this gap.

Specifically I showed how to:

Implement Commands in Silverlight 3
Implement ClipToBounds property
Implement a DataTemplateSelector replacement

I want to thank all the people who came to my lecture today.
I really enjoyed it and I hope you too.

You can download the PowerPoint presentation and the demos here.

In addition you can find more references on porting from WPF to Silverlight in the following posts:

Porting from WPF to Silverlight- The Missing Pieces, Part 1
Porting from WPF to Silverlight- The Missing Pieces, Part 2

I will post again when my lecture will be available to view on Sela College Channel.

That’s it for now,
Arik Poznanski.

Flashcards.Show – Planning a Cross-Platform Solution

arik — Sun, 13 Mar 2011 23:02:11 GMT

Following is another post by Yochay Kiriaty on a project I’ve done for Microsoft involving WPF, Silverlight, Windows Phone 7 and Windows Azure.

If you’re interested in more details, make sure you come to my presentation at the coming SDP 2011 conference (in two days!).

[Cross-posted from http://windowsteamblog.com/windows_phone/b/wpdev/archive/2011/03/03/flashcards-show-planning-a-cross-platform-solution.aspx]

I recently blogged about Flashcards.Show Version 2 for WPF, Silverlight, and Windows Phone, which features the Flashcards.Show application. I’m not going to (again) review the app, but I do want to talk about how we developed the application and the design the code base to support multiple clients.

The first version of Flashcards.Show was a Windows (WPF) application. This app was originally designed by IdentityMine, and used a few Windows 7 features such as multi-touch and taskbar integration. While the first version was great, we wanted to increase its value by enabling users to share the decks that they are creating. Therefore, when we set to work on version 2, we sought both functional and technological solutions to enable ease of use for the deck-sharing scenarios, as well as ease of development and maintenance of the code.

Ease of use for a deck-sharing scenario is achieved by enabling users to simply click one button to start the sharing process, and another to send the deck. Behind the scenes, the application communicates with Windows Azure Flashcards services and uploads the deck. To keep it simple, we chose to use the default email client application as the means for sending the email. The pre-populated email that is generated includes a link to a Silverlight player that lets the email recipients view and interact with the attached deck. If you want to experience it first hand, you can try by clicking this link. The email also includes information on how to download the deck to your Windows Phone application and how to install (using ClickOnce) the WPF application.

Sharing Code between WPF, Silverlight and Windows Phone

After we designed deck sharing, our next step was to build the Silverlight viewer. We knew that we were going to target Windows Phone as the next platform, and therefore our first decision was to make sure the runtimes are compatible. This drove the decision to build the viewer as a Silverlight 3 rather than Silverlight 4 application. While this decision costs us a few days of hard work to implement SL4 features in SL3 code, it paid off during the Windows Phone development phase.

The second decision was to share as much code base as possible, which we did. The Flashcards.Show source code includes a solution file that includes all the “client” (WPF, Silverlight, and Windows Phone) projects. If you’re interested, you can find another solution file that includes all Flashcards.Show projects, including Windows Azure in the WindowsAzureService folder (once you extract the zip file). . For now, we’ll focus on the client projects:

FlashCards.ViewModel.WPF – Contains the View-Model piece of the MVVM architecture that is used in the Windows application
FlashCards.ViewModel.SL – Contains the View-Model piece of the MVVM architecture that is used in the Silverlight application
FlashCards.ViewModel.Phone – Contains the View-Model piece of the MVVM architecture that is used in the Windows Phone application
FlashCards.UI.WPF – Contains the main Windows application, including both modes, Admin and Game
FlashCards.UI.SL – Contains the Silverlight application, including the different pages and resources
FlashCards.UI.Phone – Contains the Windows Phone application, including the different pages and resources

Looking at the above list, you might be asking yourself if there are duplications between the different ViewModel projects and the UI projects. To start with, we have to compile for the target framework. The assembly that is used for WPF ViewModel .NET 3.5 is not supported by Silverlight or Windows Phone. In addition to the Silverlight assembly, Silverlight 3 also is not fully supported by Windows Phone. Therefore you have no other option but to compile to the required target CLR.

But there is more to it than this, especially in regard to the ViewModel project. Since all clients basically share the same data model, they all have the same application logic, display the same games, and follow the same game rules. Therefore both the Silverlight and Windows Phone view-model projects include links to most of the FlashCards.ViewModel.WPF view-model project. The WPF view-model contains the data model for the deck of cards (cardDeck.cs), which is comprised of individual cards (cardPair.cs), which again are comprised of two sides of a card (card.cs). The model includes metadata (MetaData) information about the types of items (text, image, sound, video, URL) placed on each card. The games logic is also part of the view-model as you can see in the LearningGameViewModel.cs and the MatchingGameViewModel.cs. Feel free to further explore the code.

If you review the Flashcards.ViewModel.SL and Flashcards.ViewModel.Phone projects, you’ll see that they are virtually identical, and the code files in each of these projects simply contain links to the original WPF view-model files.

However, a more careful review of the Flashcards.ViewModel.SL reveals some differences. For example, the Silverlight view-model doesn’t have the Taskbar.cs file, since it doesn’t integrate with the Windows 7 taskbar as the WPF application does. The Silverlight version also doesn’t include the DeckPackaging.cs file, since we don’t allow the Silverlight viewer to edit and upload decks to the Windows Azure service.

We omit files and classes of features that are not functional in the Silverlight and Windows Phone solutions. You might want to note that the Flashcards.ViewModel.Phone is identical to the Silverlight view-model.

But there are additional changes that reflect the differences between the different platforms. In the view-model projects, you can find them in the MainViewModel.cs file. The WPF and Silverlight versions of this file are quite different from each other. The Windows Phone code is embedded into the Silverlight project and we use WINDOWS_PHONE and SILVERLIGHT conditional compile time symbols to distinguish between the two. Reviewing the MainViewModel.cs file, you’ll notice compile time conditional statements such as: #if WINDOWS_PHONE

The reason we decided to use compile time symbols instead of creating a complete new copy of the MainViewModel.cs file in the phone project is due to the simple fact that while there are differences between the two, they are small and relatively easily encapsulated.

For example, the Windows Phone application can save decks in local store, a feature we are not using in Silverlight (although possible). This introduces a completely new set of features, like getting a deck from isolated storage over the network, which can be encapsulated for the Windows Phone implementation, and abstracted from the main view-model logic. We simply make sure the main view-model receives the required information for its internal data model, and when the code compiles and runs on Windows Phone, we make sure we wrap the additional functionality in such a way that it is transparent to the main view-model logic.

For example, the StartLoading function is implemented for Silverlight and Windows Phone. While the code is similar in nature, In the Windows Phone implementation you’ll notice that we need to jump through extra hoops. For example, in the webClient_OpenReadCompleted method (called…), we don’t just return a stream back to the view-model, we also write the deck to the isolated storage. During the write time, we show a progress report, because such operations on a Windows Phone can take some time.

Another example is the private _instance_PropertyChanged method that is used in Windows Phone to control the navigation between the application pages, where in the Silverlight version we simply swap in and out user controls instead of complete pages.

Lesson Learned

Make your data model technology-agnostic as possible
In your view-model, separate the way you handle data (the model) and the flow (screen, pages, etc.) of the application (the view) within your application logic. This will make it easier to introduce different behaviors and code for different platforms, just as we did for Windows Phone and SL

Sharing UI (XAML) Is Difficult

This brings us to the next topic of sharing UI and XAML. While sharing the View-Model is relatively straightforward, sharing the UI, is a completely different story.

To start with, there is no #if def support for XAML. Therefore, you can’t use compile time symbols to control which XAML code end up in which project. Next, the namespaces are different. WPF uses a System.Windows.Window, whereas Silverlight uses System.Windows.Controls.UserControl. But even if you successfully overcome the namespace problem, there is a bunch of functionality in WPF4 that is not in Silverlight 3 (remember we chose SL3 for ease of migration to Windows Phone). Therefore, we end up rewriting most of the Silverlight application. With that said, you can still leverage all of your .NET and WPF skills as you write the Silverlight XAML, using data binding, date templates, and such. However, I really hope Shawn’s work on 3-Screen Coding Is Here: Portable Library Tools allow you to target multiple .NET platforms with one binary will help reduce such friction in the near future.

While converting the WPF solutions to support Silverlight 3 was a pain, we deliberately targeted Silverlight 3 and not Silverlight 4 because Windows Phone Silverlight runtime is version 3. The reason is simple; we wanted the easiest possible port from Silverlight to Windows Phone. And the outcome was just that, a super easy port from Silverlight to Windows Phone. It took about 3 days to make the Silverlight application run on Windows Phone.

If you look at the FlashCards.UI.Phone project, you’ll find that most of the files are links to the Silverlight UI project. The differences are visible when we check the displaying screens. In Windows Phone Silverlight application there is only one way to display data – inside a Windows Phone Page. Therefore the Windows Phone and Silverlight solutions differ in that way. But even here, the Silverlight and Windows Phone versions are very similar.

For example, the Windows Phone LearningPage.xaml includes a LearningGame user control (LearningGame.xaml). If you look at the Silverlight LearningGame.XAML, you’ll find the same user control. While we had to copy the XAML file and make some changes to fit the smaller screen, the core of the control, its behavior, and the code behind are very (very) similar. Therefore, even if we did end up copying XAML files, the core functionality remains the same.

Lessons Learned

Unfortunately, we can’t really share XAML code
Some controls can be reused

Bottom Line

Obviously, there is no single silver bullet solution to sharing code across multiple platforms. With that said, while working on this project, we learned that there is a lot of room to navigate the platform’s limitations.

Using MVVM in your WPF/SL solution makes it easier to share the model. Your application data models, logic and any request to the server side backend can and should be shared.
As for your UI, well, that really depends on the complexity of your design, and how closely you want your implementation to be dependent upon the platform form factor, like the phone’s small screen. However, even here there is some flexibility.

You are more than welcome to download the project source code, which includes some documentation. And please watch a short video on C9 demoing the 3 client applications. As usual, your feedback is most welcome.

I want to thank Arik Poznanski, from Sela group, who helped drive the second phase of Flashcards.show.

Follow Windows Phone announcements on Twitter at WP7DEV

Follow Yochay on Twitter

Get started with free tools, free training, and free Jump Start video course

(Post edited by Barbara Alban)

[end of cross-post]

That’s it for now,
Arik Poznanski

Flashcards.Show Version 2 for the Desktop, Browser, and Windows Phone

arik — Fri, 04 Mar 2011 21:15:38 GMT

Following is a great post by Yochay Kiriaty on a project I’ve done involving WPF, Silverlight, Windows Phone 7 and Windows Azure.

If you’re interested in more details, make sure you come to my presentation at the coming SDP 2011 conference.

[Cross-posted from http://windowsteamblog.com/windows/b/developers/archive/2011/02/17/flashcards-show-version-2-for-the-desktop-browser-and-windows-phone.aspx]

The Flashcards.show application has been around for few months now. It is mostly used as a developer’s reference and demo for showing specific and cool Windows 7 features. While the first version of the Flashcards let you create all kinds of decks and then consume these cards in the form of games, you could not share any of the great cards you created with anyone else except by sending the deck file itself via email..

Figure 1: Flashcards.Show in “Game” mode

With that in mind, we started working on Flashcards.Show version 2. Our goal was to enable seamless and easy sharing of decks among users across different computers. The idea was simple, upload the deck to the cloud, and let the user send a message to whomever the user wants to share the deck with. That message will include a link for the receiving party to click on to launch a web browser and run a Silverlight application that can “play” the shared deck. The Silverlight application dynamically downloads the shared deck and displays that single deck just as it would be displayed on the WPF application. At this point the user can launch any of the 3 games: Learning, Matching, or Memory, with the same user experience as the WPF application.

Figure 2: Flashcards.Show memory game running in IE as Silverlight application

Note: The shared decks have a few limitations. The deck size can’t exceed 5MB and we don’t allow video or audio. All restrictions are functional and not technical. We didn’t want to get into too deep of a development cycle.

So far so good, we have a WPF application that can share decks through the cloud and a Silverlight application that can play these decks. The next logical step was to try and run the Silverlight application on Windows Phone. Since one of Windows Phone development models is Silverlight, there is a good chance the app will run. So we tried. As you can see it works!

Figure 3: Flashcards.Show running on the Windows Phone emulator

The Flashcards.Show application runs on Windows Phone as a Silverlight application and can display the same deck that the WPF application shared with the web Silverlight. The same content and the same games can be played on Windows, on the web running Silverlight, and on Windows Phone.

If you want to download the application, feel free to use the Flashcards.Show ClickOnce install. If you want access to the code, please visit Flashcards on MSDN Code Gallery.

So there you have it – a single application that run on three different platforms backed by Windows Azure as the supporting cloud service. The nice thing about the entire Flashcards.Show implementation is our ability (by design) to share a lot of code and resources between WPF, Silverlight, and Windows Phone.

Figure 4: Flashcards.Show high level architecture

How does it work?

The Flashcards.Show application is built from two main components:

The suite of client applications – WPF for Windows, Silverlight for web, and Windows Phone
The cloud piece, a series of web services running on Windows Azure backed by Azure storage.

In this series of posts, we will NOT explain the cloud part, but will focus on the Silverlight and Windows Phone implementations.

When you download the Flashcard.Show version 2 source code, you will find a single Visual Studio solution file (FlashCardsSolution) that contains 10 different projects:

FlashCards.UI.Phone – Contains the Windows Phone application, including the different pages and resources
FlashCards.UI.SL – Contains the Silverlight application, including the different pages and resources
FlashCards.UI.WPF – Contains the main Windows application, including both modes, Admin and Game
FlashCards.ViewModel.Phone – Contains the View-Model piece of the MVVM architecture that is used in the Windows Phone application
FlashCards.ViewModel.SL – Contains the View-Model piece of the MVVM architecture that is used in the Silverlight application
FlashCards.ViewModel.WPF – Contains the View-Model piece of the MVVM architecture that is used in the Windows application
FlashCardsServices – Contains the Windows Azure project that references the services that are deployed with it
FlashCardsServices.Contracts – Contains the definition of the services use by the various Flashcards.Show applications
FlashCardsServices.Entities – Contains the model of the supporting web services
FlashWCFWebRole – Contains the web services that the different Flashcards.Show applications use

Looking at the above list, you might be asking yourself, what are the duplications between the different ViewModel projects and the UI projects?

To start with, we have to compile for the target platform (Windows, Silverlight, and Windows Phone), you have no other option but to compile to the required target CLR. For a little bit of background, please watch Shawn Burke’s “3-Screen Coding: Sharing code between Windows Phone, Silverlight, and .NET”. This sample, doesnt use the library Shawn is referring to in his talk, but it would sure make our life easier.

However, that doesn’t mean we just have to duplicate code. This is especially true in regards to the ViewModel (part of MVVM) piece of the application. Since all clients basically share the same model, they all have the same logic and display the same games and screen flow. Therefore, as you can see from the figure on the left, the WPF view-model (FlashSards.ViewModel.WPF) is the main view model we are using, and the phone’s view-model (FlashSards.ViewModel.Phone) and Silverlight view-model (FlashSards.ViewModel.SL) simply link to the relevant view model files. As you can see from the image, little arrows indicate that the relevant files are linked (click on the image to the left to see a larger version of it). This shows that we are maintaining a single view-model for all clients.

The UI is a little bit trickier. The difference between Silverlight 3 and WPF 4 runtimes are such that in our case, it is easier to simply rewrite the Silverlight application (remember, we choose to target SL3 to make the porting to Windows Phone easier). The FlashCards.UI.SL is a Silverlight project that mimics a lot of the WPF functionality, but with Silverlight capabilities.

You can still leverage all of your .NET and WPF skills as you write the Silverlight XAML and use data binding. We deliberately targeted Silverlight 3 and not Silverlight 4 because Windows Phone Silverlight runtime is version 3. The reason is simple; we wanted the easiest possible port from Silverlight to Windows Phone. And the outcome was just that, a super easy port from Silverlight to Windows Phone. It took about 3 days to make the Silverlight application run on Windows Phone.

As you can see from the figure to the left, most of the Windows Phone UI project- FlashCards.UI.Phone files are links (including the folders that are collapsed in image #6.). The links point to the Silverlight web application implementation FlashCards.UI.SL.

The files that could not be linked are those under Views. These files include XAML that is directly related to the way we display the specific pages on the phone. The phone’s form-factor is much smaller, and therefore we can fit fewer objects into it. With that in mind the implementation of the XAML was similar but not identical.

Unlike regular C# code, XAML doesn’t support of #ifdef, therefore we had to write new XAML for all the views in the game. But even then we could copy large parts of the already existing XAML.

At this stage I am not going to jump into the details of the implementation, mainly because there are a lot of them. You are more than welcome to download the source code, which includes documentation. You can also watch a short video on C9.

I want to thank Arik Poznanski who helped drive the second phase of Flashcards.show.

Follow Windows Phone announcements on Twitter at WP7DEV

Follow Yochay on Twitter

Get started with free tools, free training, and free Jump Start video course

(Post edited by Barbara Alban)

[end of cross-post]

That’s it for now,
Arik Poznanski