Select a language to translate this page!
Powered by Microsoft® Translator
How do you ensure that an app built for an earlier release of Windows Phone continues to work great on Windows Phone 8?
Whether you participate in the SDK preview program Todd Brix talked about today or not, here are some tips for future proofing your apps and readying them for the next release of Windows Phone. There are three aspects to this issue that I’ll touch on:
To get a feel for how APIs might change between versions of the platform, consider the changes from 7.0 to 7.1. These are documented here. Most changes were additive – that is, new APIs were added, so these wouldn’t have any breaking impact on existing apps. The few changes that weren’t additive generally fall into the category of ‘improved consistency with the API surface overall’. That is, anomalies were fixed – and these were almost all edge cases anyway.
You can expect more of the same in the future: the existing API surface will be brought forward into the Windows Phone 8 world, inconsistencies will be brought into alignment, and it will be massively expanded to support the many new features on the new platform.
How do you cope with version differences? How do you even discover version differences? One technique for dynamic API discovery is runtime reflection. This is a problematic technique: it can be used to increase version resilience, and it can be used to bypass the public API surface (thereby reducing version resilience).
In general, the use of reflection is discouraged in Windows Phone apps. The public surface of the app platform has been very carefully designed to provide your app with the maximum functionality in a cohesive manner. If you bypass this carefully-constructed surface via reflection, you can easily stray into areas which are not supported or which may change underneath you in later versions. For example, it is possible to use reflection to access non-public members, and this is usually a bad idea. One case where reflection might be useful is for the ‘light-up’ scenario, where you check to see you’re running on a version of the platform that has some feature that you’re interested in.
For example, in 7.0, the SystemTray class exposed only one property: IsVisible. 7.1 added four new properties. So, you might query for say the BackgroundColor, and if you’re running on a version of the platform that supports this, you can get (and/or set) its value. This is a reasonable use of reflection for positive version-resilience – because it is restricted to documented public members, eg:
To help protect IP, you might consider obfuscating your code, for example with the freely downloadable Dotfuscator Windows Phone Edition from PreEmptive. The only catch with this is that the Silverlight framework makes extensive use of reflection behind the scenes – and this makes it difficult for an obfuscator to analyze your assemblies correctly to figure out what level of obfuscation is safe.
Too much obfuscation may result in runtime errors. Just because your obfuscated code works on one version of the platform doesn’t mean the same obfuscated code will work the same way on another version. For version-resilience, therefore, you should choose obfuscation options conservatively. Specifically, you should generally avoid the code optimization features of obfuscators that eliminate unused code and data, coalesce strings, merge assemblies, and so on.
A common version resilience technique is to optimize the decoupling between components in your app. This doesn’t make an individual app version resilient – rather, it facilitates building multiple versions of your app for variant platforms, where you simply swap out different versions of particular components/assemblies per variation.
For different versions of Windows Phone, this is largely unnecessary – recall that the app platform itself acts as a version-resiliency wrapper over different underlying platform specifics. We’ve done the hard work for you! Where this approach will become more useful going forward is in the scenario where you want to target both Windows Phone 8 and Windows 8 with the same app. However, that’s getting a little ahead of myself – and I’ll talk more about this when the Windows Phone 8 SDK is released.
The first release of Windows Phone had a very tightly-restricted hardware specification. This meant that developers had the luxury of being able to target one single platform. As the market for Windows Phone has expanded, so has the range of hardware configurations that these new markets demand.
Increasingly, therefore, the set of hardware characteristics is more fluid – more capabilities are becoming optional. This applies already in 7.1 to features such as the compass, accelerometer, gyroscope and camera, as documented here. A smart developer already knows to build conditional code that tests for the existence or configuration of particular hardware features, via the IsSupported or IsXXXSupported properties, eg:
You can do the same thing with other capabilities that the user might enable conditionally, such as network connectivity or data roaming, eg:
Clause 5.2.5 of the technical certification requirements warns you that “An application must not exceed 90 MB of RAM usage, except on devices that have more than 256 MB of memory.” Note that this doesn’t say how much memory you can use on a device that has more than 256 MB of memory. Effectively, you’re guaranteed to have 90 MB of memory, and you might get more on some devices – and you might not.
The bottom line is that you should do all you can to constrain your app to run within 90 MB of memory. If you do, it will have the widest possible target market (that is, all Windows Phone devices in the known universe). If you don’t, then you’re choosing to exclude your application from some part of that market. Even if you don’t exclude your app explicitly, it may perform so badly on low-memory devices that the user will uninstall it and might give you a bad review.
So, while the 90 MB target is seen by some as merely a guideline, any such guidelines are likely to become more critical as the range of device hardware opens up. In the specific case of low memory, you can go to the extreme of explicitly opting out your application, so that it does not get installed on a low-memory device. This is documented here.
If you don’t want to restrict your market, you can instead tailor your functionality to allow for reduced memory. Here you can use the TryGetValue technique to see if the DeviceExtendedProperties.ApplicationWorkingSetLimit is available. TryGetValue is defined in the IDictionary interface, and you would normally use it in open-ended collection types such as IsolatedStorageSettings or NavigationContext.QueryString. However, this technique has been highjacked in the DeviceExtendedProperties class specifically to support additional version-dependent features. ApplicationWorkingSetLimit will tell you whether you’re running on 7.1 or 7.1.1. If the value returned is less than 90 MB, you know you’re running on a low-memory device, and can tailor your functionality accordingly.
If ApplicationWorkingSetLimit is not found, then you’re not running on 7.1.1, which means there is no system paging, which in turn means that the app’s working set limit is the same as its commit limit. You can get the commit limit from the DeviceStatus.ApplicationMemoryUsageLimit property.
More details on this technique are here. The ApplicationMemoryUsageLimit property on the DeviceStatus class tells you the maximum amount of memory that your application can allocate. Subtracting ApplicationCurrentMemoryUsage from ApplicationMemoryUsageLimit tells you how much more space you have to grow. So, to build resiliency in a world where some devices have more memory than others, you can make dynamic checks, and tailor your behavior accordingly – just as you do with optional hardware.
In summary: consider light-up scenarios, don’t use reflection recklessly, be conservative with obfuscation, test for optional hardware and user-enabled features, and pay close attention to memory guidelines.
The best way to future-proof your app is to stop using Microsoft platform.
Microsoft will kill it sooner or later and abandon you.
Microsoft has already killed WPF, Silverlight, XNA, Managed DirectX. What popular platform are you going to kill next?
How can you suggest future-proofing your apps when you've killed the only two platforms available for WP7 - Silverlight and XNA? There is no future.
Will WP8 Sdk support Virtual Machines (i see 7.1 doesn't and yet windows 8 tablet surface emulater works perfectly in VMWare Player hosted on windows 7 64bit)?
Also do you have dependency on SLAT only capable cpus even if windows 8 runs directly on metal when emulating WP8 devices? (I assume WP8 development is windows 8 only?).
Let's not forget about Windows Mobile. You know, the platform at the core of Microsoft's mobile strategy from year 1999 to approximately 2010. Very future proof that turned out to be. The utter lack of migration path for the C++ WinMobile code was a particularly nice touch on Microsoft's part.
Microsoft, if you are too blind to see this I will spell it out... >>>Look at the feedback from your developers, you are pissing them off.
Fix this as a matter of urgency.
@HTC Why would we be pissed? We only spend thousands of dollars to renew MSDN licenses and then can't even get an SDK early because of sharks with laser beams secret stuff. No reason to be pissed...
The author has great advice, but future proofing is a joke in reality. Especially when the trend goes from C++ to C# back to C++. No sense even bothering future proofing anything.
WP7 should have been C++, which is what most game devs and advanced programmers wanted anyhow.
So, they release WP7, force everyone to use .NET, then wonder why they get a bunch of crap apps from the kiddies. Now they come out with WP8, which will allow C++ I presume: INSTANT FRAGMENTATION in one generation.
If they're trying to clear the playing field so that EA has free reign, they're doing a great job.
I better quit typing or I'll get myself banned and greatly reduce any chances of future employment in Redmond should I need it.
I had a bad day the other day. Found out that 1) the new iPhone is nothing special... uses old tech. 2) can't get the WP8 SDK without signing my life away, even though I pay for MSDN subscriptions. 3) Can only see one W8 Metro app in multi-monitor mode at a time (whoever put this limitation in should get canned ASAP)...
What the hell do these companies do with all their money?
I should be able to buy a Tony Stark phone by now.
I just came from 2 years of Android dev. and I must say Windows phone restricts the developer so much that it suppresses our options and leaves no room for creativity.
Ark-kun you must be trolling. XNA apps are still usable on Windows Phone 8, they still run as backwards compatible with Windows Phone 7 (which is awesome!), granted you can't use the new WP8 features, but for most games this is not a big deal. WPF/Silverlight are all based on XAML, so there is a little bit of conversion work if you want to compile WP8-only apps from your old projects.
Managed Direct X... well there is still MonoGame which uses SharpDX I believe (could be wrong on this) - but who on earth was using Managed Direct X on WP7?!? Nobody - it wasn't possible (unless you were referring to XNA... again?)
>XNA apps are still usable on Windows Phone 8
XNA apps cannot run under Windows RT.
XNA apps cannot be submitted to the App Store.
>but who on earth was using Managed Direct X
It's an example of MS abandoning managed game development. MS killed MDX and then they've killed XNA and Silverlight 5.
They force us back to the C++ ages.
>WPF/Silverlight are all based on XAML, so there is a little bit of conversion work
A little bit?? Ha-ha-ha! WP8's XAML is so much worse than Silverlight 5, not to talk about WPF. And it's even not compatible with Windows 8's XAML =)
>well there is still MonoGame which uses SharpDX I believe (could be wrong on this)
MonoGame is not Microsoft's platform. And it lack support for many features.
But you've just proved my point: "The best way to future-proof your app is to stop using Microsoft platforms."
Just a little nit picking but why can't the code examples be in text rather than images?
I just cannot resist just a few comments to other entries I find amusing...
@ark-kun may be correct about XNA in Windows RT (and I'm not sure we quite know yet), but Windows RT is not Windows Phone. This article is about Windows Phone and "future proofing" those apps. There was not much use of Managed DirectX, so Microsoft killed it off so they could spend time on other things. Also the performance on the hardware and CPU's of the day was dismal. Using Managed DirectX as an example of something "good" or "popular" is a poor use of logic. While we're on bad logic, Microsoft killed off Immediate mode and fixed function pipeline in DirectX as well, because their performance was not amounting to anything.
@Redhot We don't yet know how much Windows Phone 8 will restrict developers, but I hope it is enough to keep the malware which attacks Androld down.
@bandit: you need to sign an NDA to get the WP8 SDK. There is nothing new in this, as Appl requires this for every early version of iOS. If you don't want to sign the NDA, wait for the public release, which will probably come only after some IP paperwork is filed.
@djaus: agree on the code examples. I think that the next article will use text, but MIke may have done that to make sure the formatting was exactly as intended. We'll see.
@Leigh ... The Apple NDA is quite different. Just pay the $99, sign, and you're good to go. Here we're talking about spending thousands of dollars on MSDN licenses, plus $99 for phone dev program, plus sign and NDA and then, after all of that _maybe_ get chosen. Not sure of the purpose of buying MSDN licenses anymore.
iPhone 5 is out now anyhow and looks to be selling like hotcakes. Better be sharks with lasers being kept secret.
I'm going to try and make a positive request here.
If you're killing off XNA please spin off the content importer and vector math libraries into their own project. It cuts a huge amount of the work out required to go from empty project to thing-on-the-screen.
@bandit: Why would you need an MSDN subscription to develop Windows Phone Apps? What you need is the Marketplace Account (99$) and a Windows-PC running Windows Vista or Windows 7. So far that is pretty much the same as with Apple.
I will buy the futuristic phone that will enable me to play games as well as to communicate and corporate use. http://bankinfoonline.com/
And this is the next JOKE from Microsoft for developers -->
For the Windows Store developer registration a pre-paid credit card cannot be used. You will need to use a different payment card that is not pre-paid and can complete online transactions in order to complete the Windows Store developer registration.
Btw: pre-paid credit cards works great for Office365 / Windows Phone app store / Xbox store / Zune
Next Joke: MSDN Subscription promo code (first year for free) + pre-paid credit card = complete registration isn't possible.
Thank you Microsoft!
Why are you trying to steer away from what I write? Forget about MDX. What about murdering Silverlight, XNA and managed game creation? Nothing good can be said about this.
> This article is about Windows Phone and "future proofing" those apps.
Yes, and it's dumb. It's cynical because not a single Microsoft tech is compatible between WP7 and WP8.
WP7 had Silverlight and XNA
WP8 will have YAIXAML (yet another incompatible XAML) and C++
See? Zero intersection. Zero compatibility. Future-proofing is impossible with MS's erratic behavior.
But all this means nothing actually. The most important thing is that MS doesn't want people to build apps for WP8. They clearly say that by denying access to SDK. Great move, don't you think?
Well, just a few minutes ago I received a mail from Microsoft saying me "Unfortunately, you were not selected for participation at this time".
It's very interesting to understand after a few lines of mail that after spending money to buy (not one, but three) phones with Windows Phone 7, after invested money for app subscription and spent a lot of days implementing apps to populate store, after talking and evangelizing my colleagues in office about this operating system (every day it happens!) compared with iOs and Android, after convincing my chief to bought MSDN subscription... after all this passion, I have to understand that I do not deserve to have an SDK that was leaked a few weeks ago and available on the net (and I wait to have official!)...
Apart that I cannot understand the choice to make developer to wait for an SDK while usually everything was released in beta, RC, RTM etc.
This is a punch in my stomach today.
I agree completely with you.
What about moving objects on the screen in XAML? If I move something 40 pixels on a 480x800 screen, what will happen on a different resolution screen?
If the App platform has a high degree (the June post here said "...without even changing a line ot code" or similar) - why the SDK "Beta" targeting Dev's to test their Apps (popular/large downloads) WP8 capability in the emulator?
I'll have to change all my underlying technology in order to get an XNA game + in-app purchases working. A month before the release I don't even know how to do that (will it be like XNA? will it be like Silverlight? Will it be like WinRT?) so I can't prepare for it.
Savegames surely won't be compatible, so I'll have lots of players pissed, or I'll have to do a lot of extra work to comply with it.
I'll give you a snippet I'm using to future proof my app:
if (phoneVersion>=8 && date>'20-oct-2012') ExitWithADisclaimer();
You want WP8 games? Give me the WP8 SDK.
in fact I just found MoVend, an in-app purchase manager for WP7 (I thought that in-app purchases were not allowed in WP7) so suddenly I don't need the WP8 SDK anymore :) Anyways that's a very bad move, microsoft.
Another useful future proofing method is testing whether FM radio is present on target device:
/// Flag is radio device is available in this phone.
public bool IsRadioAvailable
radioInitialized = true;
radio = FMRadio.Instance;
isRadioAvailable = true;
catch (RadioDisabledException e)
isRadioAvailable = false;
private bool radioInitialized;
private bool isRadioAvailable;