The Windows Phone ecosystem just got more mature. With the release of Windows Phone 7.5 (aka "Mango") in late September 2011, developers have a whole
lot of new features with which to build compelling applications. Many of these features are ones that Windows Phone developers directly clamored for.
So if you've been building apps for Windows Phone 7 and wanted more power, Mango is here to help you out. With apologies to David Letterman, here are
the top 10 developer features in Windows Phone 7.5, in descending order.
#10: Silverlight 4 Features
As a Silverlight developer, when I came to the Windows Phone I was elated that it was based on Silverlight. But as someone who spent most of his time
writing Silverlight 4, I had to adjust to the number of missing features I had become accustomed to using, including these:
• implicit styling
• data-binding features:
o StringFormat
o FallbackValue
o TargetNullValue
o IDataErrorInfo
o INotifyDataErrorInfo
• commanding support (i.e., ICommand)
• CompositeTransform
• OData support out of the box
I'm happy to report that Windows Phone 7.5 supports these Silverlight 4 features and now also supports Silverlight 4's Webcam APIs (I'll discuss this
last feature later).
#9: Mixed XNA/Silverlight Projects
Microsoft XNA projects are primarily used to build games for the Windows Phone. Although this will continue to be true, XNA has a weak spot: screen
building. Building the menu screens and other parts of the user interface (UI) in games is harder than it needs to be in XNA. That's where the hybrid
Windows Phone Silverlight and XNA Application project type comes in.
In this new project type, a Silverlight application is created but adds the necessary pieces to support a content pipeline and game loop. By default,
this new project creates separate Silverlight and Game pages to support a standard side-by-side approach of having Silverlight handle the page
navigation and supporting rendering of XNA in separate pages. For example, for an XNA page in one of these projects, a PhoneApplicationPage is created,
but no internal XAML is specified because the entire page is rendered using XNA. First you need to use a game loop on the XNA page. The template
accomplishes this by creating a game loop in the constructor, creating the GameTimer object, and handling the Update and Draw methods XNA developers
are used to, as shown in Figure 1.
Next, the template uses a SharedGraphicsDeviceManager class to allow sharing of Silverlight and XNA on a particular page, as in Figure 2. In this case,
it calls the SetSharingMode to tell the system to share XNA and Silverlight. The GraphicsDevice on the SharedGraphicsDeviceManager is the same one you
would be used to as a XNA developer, so all the same operations work. There are similar approaches that allow you to even overlay Silverlight on top of
an XNA game using the UIElementRenderer class.
#8: Background Transfer Service
Many applications need to download or upload content to and from their applications. Developers might opt to create background agents (discussed later
in this article) to perform this task, but typically the first choice for enabling file transfer should be the background transfer service.
This service is designed to allow you to queue up file transfer (download and upload) to be performed by the operating system. The key here is to use
the BackgroundTransferService class to make requests, as shown in Figure 3. The service can also be used for uploads, as in Figure 4.
The background transfer service imposes specific limits on how many requests can be made per application, whether such requests occur while the device
is on battery, and whether they download only while on a non-cellular connection. Even so, for many cases using BackgroundTransferService is the right
approach to performing transfers in Mango.
#7: Local Database
Although using serialized objects in Windows Phone's isolated storage is still a primary use case, there are times when storing data in a local
database simplifies development. To this end, Mango now supports a local database option. This option is built on top of LINQ to SQL. The local
database support is easily used as a code-first mechanism for creating a data store. For example, you can easily build a class and use attributes to
specify the fields in the database, as Figure 5 shows.
From that you can support a context class that exposes each of the tables as an endpoint for LINQ queries, as shown in Figure 6. The DataContext class
will take each field that is of type Table and allow that table in the local database. The DataContext class also supports creating the database and
some limited upgrading of the database schema. With this class, you can simply store and query data, as in Figure 7. In short, the local database story
in Mango represents a simple but powerful way to handle relational, queryable data on the device.
#6: Image-Loading Performance
Windows Phone 7 had several issues with UI performance that Microsoft wanted to tackle and improve in Mango without breaking old code. One of the
problems was that images were loaded on the UI thread, which meant (by default) that if you have a lot of images (e.g., in a ListBox's DataTemplate),
the UI could be less responsive than you need. To combat this problem, Mango supports four options:
- None: Images are loaded on the UI thread immediately.
-
DelayCreation: Images are loaded on a background thread (off the UI thread).
-
IgnoreImageCache: Images are always loaded via the universal resource identifier (URI) -- and not from cache for the URI.
-
BackgroundCreation: Images are decoded on a background thread (off the UI thread).