This is the Day #6 post in the article series “7 Deadly Sins for Windows Phone Developers!“.

What is Gluttony ?

From http://deadlysins.com:

Gluttony is an inordinate desire to consume more than that which one requires.

Why: Because you were weaned improperly as an infant.

How does Gluttony relate to Windows Phone development ?

— over-indulgence/over-consumption ..

Gadgets. They just keep coming .. new & improved, faster & better, smarter & more personal. Tablets & computers of today easily match the computing & storage capabilities of super machines from a few years back. All this, in my opinion, is making us developers a little lazy. We are having to pay less attention to performance as the available horsepower simply swallows potential issues.

Mobile development is a great leveler in that regard. Just the constraints of the smartphone form factor give it limited resources and this brings our code closer to the metal & demands restraint. We need to worry about performance optimization, since lack of it leads to crappy user experience. Let’s take a look at how we Windows Phone developers can avoid Gluttony while developing for the Windows Phone ecosystem:

• Resources: Overconsumption of phone’s resources is bad. The Windows Phone team has worked very hard to make the core OS very very lean .. our resource hungry app will stick out even more in this context. Make sure your memory footprint is small; this ensures that your app runs efficiently when loaded in device RAM and stays longer in memory as Mango does Multitasking/Fast Application Switching(FAS). Managed code helps; but make sure you do not have extra Using statements or referencing any library that you do not need. Beware of using multiple 3rd party toolkits, specially if there is overlapping functionality. Also, animations are nice & an integral part of Metro; but too much of it is not good. I have personally seen performance degrade when swapping out the default PhoneApplicationFrame (one that houses your XAML pages) with 3rd party tooling for custom animations; but that could be just me. Anyways, point is, know exactly what you need & don’t go over. This is an awesome checklist for performance tuning.
• Threading: Surely no one needs to be told that locking up the UI thread is just not an option on tablet/smartphone applications. You may be counting national population/debt; but your App UI needs to be responsive. Most Silverlight programming forces us to do heavy-lifting asynchronously, by intelligent use of Background threads for processing, Composite threads for animations & auto-merging with UI thread. You may use an explicit Background worker, if needed. Hang tight as life is gonna get better when the now-supported Async CTP is finalized .. no more gobblygowk Dispatcher.BeginInvoke() or DownloadCompleted() APM/EAP patterns (details here) .. you should just be able to do async-await to achieve asynchrony.
• Caching: Cache anything possible to prevent making the same web HTTP call twice. This specially applies to images/flat data. Check out the following resources to cache artifacts in Isolated Storage here, here & here.
• Execution Model: Now that you know Windows Phone Mango supports FAS through a in-memory application backstack, did you stop caring to handle Tombstoning? We cannot just write a resource-heavy App and expect it to be held in memory for long. Coming out clean from Tombstoning is a must .. this article on Execution Model could be a good place to start :).
• Alarms/Reminders: The new APIs to create Alarms/Reminders are great; but please do not over-indulge in reaching anywhere close to the limit of 50 or create them without user intervention.
• API Exploitation: The new Calendar & Contacts APIs are super handy, aren’t they? But again, with power comes responsibility. Do not exploit them to do things without user intervention. Uninstallation & bad reviews will follow.

That’s it for today. Crux of this post: Just because you can, doesn’t mean you should! Hopefully, you come back tomorrow for the Day #7 article in this series of “7 Deadly Sins for Windows Phone Developers!“.

Adios!