Analyzing the Windows Phone Upgrades

On March 26, via the Windows Phone Developer Blog, Microsoft announced the immediate availability of the Windows Phone SDK 7.1.1 Update. This follows the announcement at World Mobile Congress earlier this year of a new range of Windows Phone devices, such as the Nokia Lumia 610, that will be running a version of the Windows Phone operating system specifically tailored to low-end devices, Windows Phone 7.5 Refresh (previously referred to by the codename Tango, which follows the Windows Phone 7.5 update, Mango, and precedes the next major refresh, Apollo.)

Windows Phone Refresh
Before we take a look at the developer tools update, let's first take a look at the Windows Phone 7.5 Refresh. If you've been following the mobility space, you'll know that there was a substantial deal made between Microsoft and Nokia. This yielded its first devices towards the end of 2011, with the release of the Lumia 800 and 710. These were mid-range devices; they didn't have a massive screen, nor were they cheap enough to be in the same price bracket as your average feature phone. In fact, the Lumia 800 appeared to be a hardware port of the N9 device, running Windows Phone. It became evident that these were the first in a long line of Windows Phone devices Nokia planned to ship.

Nokia announced earlier this year the Lumia 900, more of a high-end device, and more recently the Lumia 610. The Lumia 610's significance is that it's been specifically designed to be a low-cost entry-level device. Although it adheres to the Windows Phone platform specification for screen resolution and hardware buttons, there was a need to identify areas where savings could be made. Two areas are of particular relevance to developers:

The amount of available RAM for applications. While most Windows Phone devices have 512MB of RAM, devices running Windows Phone 7.5 Refresh can utilize half that, or 256MB

Windows Phone SDK 7.1.1
With this in mind, let's discuss the Windows Phone SDK 7.1.1 Update. After installing the update, the first and probably most notable difference you'll see is that there are now two emulator images you can target from the device dropdown within Visual Studio (and the Application Deployment tool): one with 512MB RAM and the other with 256MB RAM, as shown in Figure 1.

The difference between the two emulator images extends beyond just the available RAM. If you connect to the emulators and checks Settings, you'll notice that on the 512MB emulator (left image, Figure 2) you can administer background tasks. The 256MB emulator (right image, Figure 2) doesn't have this option.

[Click on image for larger view.]

Figure 2.Background Task settings. The 512MB emulator, left, shows the availability to add background tasks, while the 256MB version removes this option.

The Beginning of Fragmentation?
A natural question is to wonder if these changes are leading down the inevitable path of device fragmentation. The answer, to a certain extent, is Yes. While Windows Phone has always maintained a strict hardware chassis, this is starting to be relaxed for manufacturers who want to differentiate and lead into new markets.

The flip side is that unlike other platforms, where it has been done in a relatively uncontrolled manner, this change has been done in a way that should make it fairly non-disruptive for developers.

For example, Windows Phone 7.5 added support for a background tasks (also known as background agents) that allowed applications to run either periodically, or when the device was connected to a power source. While this opened up a host of scenarios where background processing, for instance, could be used to update live tiles on the Start screen, there was always the possibility that the user might elect to prevent an application running in the background. For this reason, Microsoft has encouraged developers to take advantage of background tasks to reduce their application's footprint, rather than making it part of the core functionality. Thus, if your application doesn't rely on background tasks, you're well placed for your application to run, unchanged, on Windows Phone 7.5 Refresh.

Windows Phone marketplace apps were limited to 90MB. This was actually a soft limit; your application could exceed it on a real device with more than the minimum 256MB RAM so long as there was available memory. With Windows Phone 7.5 Refresh, it's much more critical that your application doesn't exceed this threshold, since going above this value may result in performance issues as the device attempts to page memory. MSDN has more detailed guidance on developing for 256MB devices. You can also elect to opt out of supporting the new low-end devices if your application is particularly resource intensive, or background tasks are fundamental to how your application operates.

Although this isn't a major update to the Windows Phone platform, the support for multiple emulator images and other minor feature updates make it an update worth getting immediately. Of note is the inclusion of the latest Microsoft Advertising SDK and the ability to run the developer tools and emulators on the Windows 8 Consumer Preview.

About the Author

Nick Randolph runs Built to Roam, a consulting company that specializes in training, mentoring and assisting other companies build mobile applications. With a heritage in rich client applications for both the desktop and a variety of mobile platforms, Nick currently presents, writes and educates on the Windows Phone platform.

Featured

This week saw two third-party vendors of dev tools -- UX and UI toolkits and controls -- release new offerings that include support for two of Microsoft's main open source frameworks, the cross-platform .NET Core 3.1 and Blazor, which allows for creating browser-based web applications with C# instead of JavaScript.

Clustering non-numeric -- or categorial -- data is surprisingly difficult, but it's explained here by resident data scientist Dr. James McCaffrey of Microsoft Research, who provides all the code you need for a complete system using an algorithm based on a metric called category utility (CU), a measure how much information you gain by clustering.