How to Build an Application That Works on All Windows Phone Devices

Introduction

To ensure that a Windows Phone application can work with the plethora of devices out there, there are certain considerations that need to be heeded when designing your application. In this article, I will show you how to design to ensure the expanded outreach of your Windows Phone applications.

Things to Care About in Windows Phone Apps

There are two things to care about to make a successful Windows Phone application:

    • Ensure that your application works on the widest range of Windows Phone devices possible.
    • Ensure that users have a great experience with the application all the time across all their devices.

To optimize the outreach of the application, you can approach in one or more of the following ways:

  • Breadth targeting
  • Selective targeting
  • Feature light-up and tuning

Breadth Targeting

This involves building an application that can run on all the Windows Phone devices out there. For this, you need to aim for the lowest common denominator. This means that your application will need to eliminate non-universal features and capabilities. It also needs to be low to memory usage to allow for running on low-end devices. Your application will have to take the simplest and most robust approach.

To ensure breadth targeting, you might have to sacrifice some features.

WP 7.1 required the minimum device specification at 256 MB memory and the working set limit for running applications at 90 MB, so you should strive to keep your app working by setting the footprint below 90 MB.

Selective Targeting

This approach involves building your application to target one or more of the following:

  • particular operating system version (WP 8.0, WP7.1)
  • manufacturer (like Nokia)
  • Device capabilities (like all devices that have specific capabilities or support specific requirements)

The application can specify the capabilities that are required in the manifest file (via ID_CAP_xxx) and requirements (via the ID_REQ_xxx) settings. Typically device capabilities to target include specific sensors such as a GPS sensor requirement for a navigation app.

Feature Light-up and Tuning

In feature light up and tuning, certain features are conditionally enabled. Features can be of two types: fixed and dynamic. Fixed features are device capabilities like sensors and media capabilities. Examples of dynamic features are data connectivity and power source connectivity.

Sensor availability can be checked by calling the IsSupported property on the specific sensor.

Here is a code snippet showing how you can selectively enable features.

public partial class MainPage : PhoneApplicationPage
    {
        bool gyroscopeSupported;
        bool accelerometerSupported;
        bool compassSupported;
        bool frontFacingCameraSupported;
        bool enableGyroscopeRelatedFeatures;
        bool enableAccelerometerRelatedFeatures;
        bool enableCompassRelatedFeatures;
        bool enableFrontFacingCameraRelatedFeatures;
 
        // Constructor
        public MainPage()
        {
            InitializeComponent();
            SupportedDeviceCapability();
            LightUpFeatures();
            // Sample code to localize the ApplicationBar
            //BuildLocalizedApplicationBar();
        }
 
        private void SupportedDeviceCapability()
        {
            gyroscopeSupported = Gyroscope.IsSupported;
            accelerometerSupported = Accelerometer.IsSupported;
            compassSupported = Compass.IsSupported;
            frontFacingCameraSupported = Camera.IsCameraTypeSupported(CameraType.FrontFacing);
        }
 
        private void LightUpFeatures()
        {
            enableGyroscopeRelatedFeatures = gyroscopeSupported;
            enableAccelerometerRelatedFeatures = accelerometerSupported;
            enableCompassRelatedFeatures = compassSupported;
            enableFrontFacingCameraRelatedFeatures = frontFacingCameraSupported;
        }
 

Using Reflection

You can also use reflection to bring certain features (like the new tiles support) available in Windows Phone 8.0 to previous versions of Windows Phone.

On Windows Phone older than 7.8, you can implement the new tiles (available in Windows Phone 7.8 and 8) using reflection.

Here is an example to create a flip tile using reflection.

Windows 7 does not have the FlipTypeDataType. Let us create this type using reflection.

Type flipTileDataType = Type.GetType("Microsoft.Phone.Shell.FlipTileData, Microsoft.Phone");
var fliptile = flipTileDataType.GetConstructor(new Type[] { }).Invoke(null);
ShellTile.ActiveTiles.First().Update((ShellTileData)fliptile);

You can now use FlipTile on Windows 7 even though it is not available directly.

Summary

In this article, I provided you with tips on how to build Windows Phone applications that can work on all Windows Phone devices. I hope you have found this information useful.

About the author

Vipul Patel is a Program Manager currently working at Amazon Corporation. He has formerly worked at Microsoft in the Lync team and in the .NET team (in the Base Class libraries and the Debugging and Profiling team). He can be reached at vipul.patel@hotmail.com



Related Articles

Comments

  • There are no comments yet. Be the first to comment!

Leave a Comment
  • Your email address will not be published. All fields are required.

Top White Papers and Webcasts

  • Instead of only managing projects organizations do need to manage value! "Doing the right things" and "doing things right" are the essential ingredients for successful software and systems delivery. Unfortunately, with distributed delivery spanning multiple disciplines, geographies and time zones, many organizations struggle with teams working in silos, broken lines of communication, lack of collaboration, inadequate traceability, and poor project visibility. This often results in organizations "doing the …

  • With JRebel, developers get to see their code changes immediately, fine-tune their code with incremental changes, debug, explore and deploy their code with ease (both locally and remotely), and ultimately spend more time coding instead of waiting for the dreaded application redeploy to finish. Every time a developer tests a code change it takes minutes to build and deploy the application. JRebel keeps the app server running at all times, so testing is instantaneous and interactive.

Most Popular Programming Stories

More for Developers

Latest Developer Headlines

RSS Feeds