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

What is Lust ?

From http://deadlysins.com:

Lust is an inordinate craving for the pleasures of the body.

Why: Oh, please.

How does Lust relate to Windows Phone development ?

— excessive desires ..

Upfront, we’re not going try to map Lust in the true sexual sense, since that would be difficult & a slippery slope :). Let’s see how we Windows Phone developers can be wary against being over-zealous. Zest is good; craving without taking any appropriate action – not so much:

• Bandwidth: Coming from a strong web background, we developers might end up blatantly using the user’s bandwidth. While rich content is good, we need to be aware that the phone is a mobile wireless device & not everyone is on an unlimited data plan. So, think twice when making data requests from the phone & have a solid caching strategy when possible. Use the DeviceNetworkInformation API to figure out state of network connections; may be we can do some heavy-lifting when appropriate (like data sync through ResourceIntensiveTasks while on WiFi).
• Start-Up: While a dynamic flashy panorama/pivot home screen on your App may be a lucrative proposition, be aware of the cost. You only have a few seconds on the Splash page (if using one) before loading up the Home screen/MainPage. And while you can dummy up a Splash-screen-like pop-up on Home screen (like here), users usually do not want to wait too long. Consider using cached data from prior run of the App & indicate visually that you are fetching fresh data. And any time you are working with pop-up or login pages that you do not want to leave in page Backstack, make sure to clear them up.
• Live Tiles: You desire your App to be like ones built by the cool kids. Don’t worry, we all do. One of the best favors you can do for your App is to support Live Tiles. This is one of the unique selling points of the platform, epitomizes Glance & Go and keeps inviting the user back into your App. Application Live Tiles or Secondary Live Tiles with backend support would be great; at the very least, you should consider presenting a slice of your App data as a local Secondary Live Tile.
• Emulator Skins: We grew up knowing it’s not polite to stare, right? Yet when it comes to fancy new gadgets like smartphones, we openly drool .. and you know what, it’s ok :). Sadly, we live in a society of perpetual buyer’s remorse where newer electronics tickle our wallets every day. Now, fancy new Windows Phones will come up every now & then, which you may not be able to jump to given your contract cage. However, instead of drooling, you can go one step closer while you develop Apps for Windows Phone. Check out the cool Windows Phone Emulator Skin Switcher — choose between any one of 25 different Windows Phone skins. Or make one yourself. If you’re doing Windows Phone Dev on spare time, might as well make it a little fun!
• Marketplace Woes: In the zest to get our dream App live in the Marketplace, we can all get trigger-happy in Marketplace submissions; but beware of these potential ingestion hiccups. Also, some newer Markets may have additional Certification obligations to meet local regulations .. check all details with the Application Certification Requirements. If you go with worldwide distribution, your certification time would be longer and your App will be subject to extra scrutiny. If you see failures, resubmit after fixing the issues or you could deselect the troubled Markets to get your App live in the Marketplace quicker.

Today is the last article in this series of “7 Deadly Sins for Windows Phone Developers!“. Apologies if the tone of anything I said sounded awkward .. by things “you” need to do, I really meant me. I simply wanted to document all the resources I want to keep in mind during my next Windows Phone app. Hope the articles were somewhat fun .. thank you very much for reading. Lot of good times ahead for us Windows Phone developers .. cheers to that.

Adios!

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!

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

What is Greed?

From http://deadlysins.com:

Greed is the desire for material wealth or gain, ignoring the realm of the spiritual. It is also called Avarice or Covetousness.

Why: You live in possibly the most pampered, consumerist society since the Roman Empire.

How does Greed relate to Windows Phone development ?

— sin of excess, desire for quick riches ..

Our greed as Windows Phone developers often surfaces when we jump the gun, before knowing consequences. Allow me to elaborate on how we can avoid some greedy pitfalls:

• Patterns: So, you have made up your mind on a dream Windows Phone app. What’s next .. File->New Project? Wait .. think it through a little. I’m not saying you dwell forever before getting started; but a little thinking ahead helps. May be you start with a subset of what you eventually want to achieve in your app. Having some vision about the future features of your killer app will help you better architect the solution. We all hate codebases which are a hot mess, right? Take a look at a few software patterns and see if any appeals to you. The goal should be to keep your application code clean & have separation of concerns, so it’s easy to test. Is your UI tied too closely to some business logic, making it difficult to push out updates/fixes? Turns out, patterns like MVVM work really well in Silverlight/Windows Phone type development. You can roll in your own or start with some awesome toolkits which help you along the way. Some prominent ones are MVVM Light, UltraLight MVVM & Caliburn Micro.
• Localization & Globalization: Did you think you could write once & reuse your app many times over to make money? While there is nothing stopping you from releasing your English app worldwide to all Markets, eventually the laziness will take a toll on your fame/money. Have you considered that the fact that non-native speakers may not have the best UX on your app unless it is localized/globalized? Yes, it’s difficult; but bite the bullet & you will see plentiful rewards. A great starting point is here. Pick your favorite translation service & see how far you can get. Seek localization help from friends or fellow Windows Phone developers across the world, so that your App language feels natural.
• Performance: Understand Data Virtualization, period. This helps in making sense of the price you pay for the choices you made, both in your Listbox DataTemplate & the actual data list it is bound to. Great articles here, here & here. Still in doubt about your App’s performance & rendering of XAML pages? Whip out the Windows Phone Profiler tool to identify performance problems in your app .. a great starting point is here.
• Background Agents: Using your single allowed Background agent? Good. But do not take your Periodic Task to its deathly limits. Remember, there are constraints on such Periodic Tasks, meant to be small amounts of code run for a small amount of time on a regular recurring interval. If you try doing too much, you enter the realm of unknown where the OS will simply shut down your background process. Result – bad UX since “Both periodic and resource-intensive agents are unscheduled if they exit two consecutive times due to exceeding the memory quota or any other unhandled exception. The agents must be rescheduled by the foreground application.”
• SQL CE: I know we all hankered for SQL CE support prior to Mango; and now we have it. Nice walkthrough here. But unless you have truly relational data & a very very good reason to use it, don’t. Because, it is a layer of orchestration on top of Isolated Storage and you are taking a little performance hit.
• Design: Remember Metro – simple, elegant & chromeless. There is a fair amount precision behind Metro though .. spacing & placement matters. The MetroGridHelper nuget should help. First rule of Metro – just because we can, doesn’t mean we should. I have mentioned this before, but again the 31 week article series by Arturo Toledo explaining the crux of Metro is a fantastic read.
• Icons: In your zeal to get started & do everything yourself, do not forget to look around to see if the Metro AppBar or other icons you need are already available or not. There are great collection of Metro icons available here & here.

See? Little restraint & our Windows Phone app codebase can flourish systematically, without having to reinvent the wheel. Happy You & Happier Users. Hopefully, you come back tomorrow for the Day #6 article in this series of “7 Deadly Sins for Windows Phone Developers!“.

Adios!