Ensuring your Windows Phone Applications Work on Mango

Not only does Mango support Silverlight 4, there are also numerous updates and improvements to Silverlight for Windows Phone. A bunch of work has gone into compatibility between Mango and Windows Phone 7, however you should test your existing applications on Mango, to make sure they behave as expected.

There are a few known differences in the behavior of Silverlight API in comparison to the same API in Silverlight on Windows Phone 7. When the docs are published for Mango, you will be able to see these changes in the Version Notes section of the relevant API page. Following is an example of the Version Notes calling out a difference in Windows Phone OS 7.1.

One problem is of course is that you are probably testing your applications on Mango now, and may encounter unexpected behavior, and waiting until the docs publish isn’t the best solution. In the meantime, I’ll list the current known Silverlight for Windows Phone issues here.

Controls

Image and MediaElement controls in a list

In Windows Phone OS 7.1, scrolling performance was improved. However, if you display several Image or MediaElement controls in an ItemsControl (most importantly the ListBox), you might notice issues with scrolling. In some cases, the list may scroll faster than the images can load, causing flickering in the UI. If this occurs consider loading the images on a background thread.  For more information on how to do this, see Off-Thread Decoding of Images, on the Silverlight for Windows Phone Performance Team blog. Finally, make sure that you test the scrolling behavior on a Windows Phone device.

(As a side note, if you are Windows Phone developer, you should be reading the Performance Team blog on a regular basis. Great info there.)

ScrollViewer

In Windows Phone OS 7.1, when you set the content indirectly for the ScrollViewer, such as with a ContentPresenter, you should call UpdateLayout prior to calling ScrollToVerticalOffset or ScrollToHorizontalOffset; otherwise, an exception will occur.

To improve scrolling performance some events, properties and methods you had access to from the  ScrollViewer are now handled by the system. Check out this post on the Performance Team blog to get more details.

TextBox

In Windows Phone OS 7.1, when you set the FontFamily property to a font that is downloaded or contained in a file, the TextBox renders at the position (0,0). When the font has finished downloading the application renders again with the TextBox in the correct location.

VirtualizingStackPanel

In Windows Phone OS 7.1, when you set a RenderTransform as a child of the VirtualizingStackPanel, it is returned as a CompositeTransform, regardless of the actual transform that is applied.

 

Navigation

NavigationEventArgs

In Windows Phone OS 7.1, if you use the NavigationEventArgs constructor to create a NavigationEventArgs and pass null for the uri parameter, when accessed later the Uri value returned will be empty Uri.

Media

Image and MediaElement controls in a list

In Windows Phone OS 7.1, scrolling performance was improved. However, if you display several Image or MediaElement controls in an ItemsControl (most importantly the ListBox), you might notice issues with scrolling. In some cases, the list may scroll faster than the images can load, causing flickering in the UI. If this occurs consider loading the images on a background thread.  For more information on how to do this, see Off-Thread Decoding of Images, on the  Silverlight for Windows Phone Performance Team blog. Finally, make sure that you test the scrolling behavior on a Windows Phone device.

 

WriteableBitmap

In, Windows Phone OS 7.1, when you specify a BitmapImage as the parameter for the WriteableBitmap constructor, you must set the CreateOptions property of the BitmapImage before you use it to construct the WriteableBitmap; otherwise, an exception will occur.

 

Networking

HttpWebResponse

In Windows Phone OS 7.1, if you compare the value of the HttpWebResponse.ContentLength property to -1 to determine if the ContentLength header is set on an HttpWebResponse, you should compare the value as a 64-bit and 32-bit integers. To do this, you should cast the value to a 32-bit integer and compare with -1, as well as comparing with -1 as a 64-bit integer. The following code example shows how to do this.

if (response.ContentLength == -1L || (Int32)response.ContentLength == -1)

{

   // The ContentLength header is not set. Handle this appropriately.

}

 

I’ve also updated a few key conceptual topics with this information, and they will republish soon.

• For control changes, see the Controls in Silverlight for Windows Phone topic and pay particular attention to the Compatibility Notes column of the table that lists controls.
• For media changes, see the Media in Silverlight for Windows Phone topics
• For networking changes, see Networking in Silverlight for Windows Phone.
• For general behavior changes that don’t fit into a nice feature bucket, see the Differences between Silverlight and Silverlight for Windows Phone topic.

Finally, for changes to core Windows Phone features, see Windows Phone OS Application Compatibility topic.

--Cheryl