[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:
- Optimizing Apps for Lower Cost Devices (part 1)
- Optimize Start Up Time (part 2)
- Reduce Memory Usage (part 3)
- Handle Feature Reductions (part 4)
- Respond to User Input (part 5)