Select a language to translate this page!
Powered by Microsoft® Translator
[This is the fourth in a five-part series on ways to help make your apps run better on lower-cost phones.--Ed.]
With the Windows Phone 7.5 Refresh, we refactored the OS in several areas to reduce memory usage and free up more RAM for apps. Part of this exercise included assessing the memory usage of features in the developer platform and assessing which, if any, we could afford to live without.
To free up the most RAM while also being as minimally disruptive as possible, we disabled generic background agents (PeriodicTasks/ResourceIntensiveTasks).
On today’s devices, users can disable background agents for an app manually via the Settings control panel, and the system can disable background agents for an app if the maximum number of supported background agents is exceeded. These conditions are surfaced to the app via an InvalidOperationException which the app must handle. On 256MB devices, the app receives the same InvalidOperationException received in the maximum exceeded case above when trying to schedule a background agent (since the maximum number of supported background agents is 0). This means if an app is written today to handle the maximum exceeded case, it will continue to work on 256MB devices unchanged. Make sure your apps handle this exception path and degrade gracefully when these features are unavailable. This will benefit your app experience both on today’s generation of devices as well as on new lower cost devices. The 256MB emulator introduced in the WPSDK 7.1.1 enables you to easily test this code path.
If you're using PeriodicTasks today to power your live tiles, there are a few options available to you. The first option is to switch to push notifications. A second option is to create ShellTileSchedules to update your tiles with remote images. A third option is to leverage the ShellTile API's from your foreground app to update your tiles whenever the app is launched. While technically the tiles wouldn't be live in this last case, the content would be refreshed, which can give the impression of live tiles. If you allow users to flag content, for instance, you could turn your tiles into a permanent reminder space and update them to reflect the most recently flagged content (or toggle through flagged content with every app launch). If these options aren't feasible for you, then you can still always take advantage of secondary tiles to provide convenient access to deeper experiences in your apps.
In addition to PeriodicTasks and ResourceIntensiveTasks being disabled, the lower cost 7x27a chipset itself has reduced media playback capabilities that may impact playback of some of your content. Attempting to playback unsupported content on the device will result in either (1) a "Sorry, we can't play this file on your phone" error, if played via the MediaPlayerLauncher, (2) a MediaFailed event if played via MediaElement, or (3) suboptimal video playback in some cases. While most apps in our testing during the Windows Phone 7.5 Refresh were not impacted by these reduced capabilities, you may be impacted if you do exceed them. Be sure to understand the new baseline and encode your content to work well across all Windows Phone devices. To conditionally offer higher quality vs. lower quality content depending on the device, leverage the MediaCapabilities.IsMultiResolutionVideoSupported flag. This flag will be false on devices with reduced media capabilities, so be sure to fall back to the baseline specs in this case.
While feature reductions are never ideal, these reductions bring with them an opportunity to reach a large new audience with your apps. Be sure to account for these reductions when targeting lower cost devices to provide the best possible experience to your users.
Make sure to check out the other stories in this series:
As a Windows Phone developer -- I'm wondering what in the world you guys are thinking at Microsoft with this reduced functionality release.
Yes -- I'm sure it'll open up cheaper phones and a wider audience -- but at the same time it is opening you guys up to a huge attack on multiple fronts:
1) iPhone/Android camps are going to eat this up. I can see the comments now: "Reduced functionality Windows Phones? I didn't know there was any functionality to reduce?", etc etc...
2) It introduces fragmentation in a nascent OS -- give it more time to mature, and if you are going to introduce something new, it should be a STEP FORWARD, NOT BACK.
3) It is a pain in the butt for devs to even have to worry about this stuff -- is there a way to mark our apps as not supported on the reduced functionality devices?
4) I can see a lot of apps that couldn't even be done before the Mango release, all those apps aren't going to work on these new devices. (Would an app like Audible even work? I get the feeling it won't)
5) Reducing the number of apps that work on this new reduced platform is going to hurt adoption big time.
6) Learn your lessons from the Kin -- people DON'T WANT a "smart phone lite"
Please please. I beg of you -- rethink this and stop it before it gets any further.
Appreciate your interest here.
Regarding point 1, seeking lower price points in the market is something that competitors are doing as well. Not everyone who wants a smartphone can afford a premium device with a premium data plan.
Regarding point 2, this is not fragmentation. As I've mentioned before, we've leveraged the existing optional hardware model with this release, and the components that are optional (> 90MB RAM and background agents) have always been optional per certification requirements and existing system behavior as I've mentioned in the post above.
Regarding point 3, most of these concerns already exist today as I've mentioned above, so developers should mostly be familiar already with these principles. But yes, if you'd like to opt out, we do allow you to declare metadata in your manifest file to opt out from these lower cost devices.
Regarding point 4, 95% of the catalog works already. Some apps currently have performance problems and some apps currently use more memory than is supported on the device, but by following our guidance here, these problems can be solved. The performance gains achieved via this exercise will also result in better performance on today's premium devices, so look for performance gains in your favorite apps in the near future.
Regarding point 5, any app can work well on any Windows Phone device (including lower cost devices) if best practices are followed. Larger addressable market is important to many developers and this release aims to address that.
Regarding point 6, please refer to the points above.
" is there a way to mark our apps as not supported on the reduced functionality devices?"
Good point, you can mark your apps to be allowed only for the not-limited devices, but as far as I know, you'll still be able to download it on your "limited" device after closing warning window.
I got same problem with my app "Mirror" which uses the front facing camera. I can't prohibit installing my app on phones without front camera even though I got "ID_HW_FRONTCAMERA" in the manifest. And yes, I got tons of bad reviews, because "my app is not working on phones without front camera".
But anyway, thanks for the article :)
For lower cost devices, opted out apps will actually be blocked from installation. This was part of the work that went into the Windows Phone 7.5 Refresh. Sounds like this meets your expectations.
Thanks for replying Mike. Your answers to my points are well thought out. (And nicely moderate as opposed to my doom and gloom following my initial gut reaction -- although I'm sure this isn't the first time you've addressed these concerns :))
I'm hoping that you guys are right and this pans out. Having a larger customer base is definitely an attractive proposition.
what about the very much needed Bluetooth APIs? Seems quite odd to me that Microsoft still hasn't filled this gap against Android.