WP7 Development Tips Part 1

Performance is the area that we probably spend the most time on in all our apps.  Building apps on the phone is just way different than building desktop apps.   Things that might be really minor optimizations on a desktop Silverlight can really make a difference on desktop Silverlight apps.

Developing on the phone is an issue of economics where processing power is a scarce resource.  You have to be conscious of the tradeoffs of using things like binding, layout controls, dependency injection, etc with their impact on performance.  When I first started building phone apps I was excited to use nRoute and it’s nice features around MVVM/Resource Location/Messaging/Navigation.  I wanted to have this really perfect loosely coupled architecture that used biding for everything/minimal code behind, had great designer support and dynamically resolved the proper services and models. In practice, that is not generally high performance code on the phone.  If you are using some extra frameworks, really be conscious of the impact on performance and decide if you really need that architecture.  What might work wonderfully on a more complicated desktop line of business app might not work as well on the phone.  You just have to expect to write more optimization in a mobile app regardless if it’s the iphone, wp7 or android.

Silverlight was billed as “same Silverlight, just on the phone”. That is mostly true in terms of the api, but not necessarily true in terms of the actual runtime. It’s really a brand new runtime based on Silverlight 3 with some extra features added, so certain pieces of code might not have the same performance characteristics.

I’ve seen a lot of articles from various other people that talk about “buttery smooth scrolling” and other performance tips.  At times the tips are a little too generalized.  When you try to optimize something for performance on the phone, you really need to take into account your specific circumstances and find the right combination that works for your app.  Always test and benchmark.  Some things are more difficult to measure without real profiling tools, but do the best you can.  Also be aware that scrolling in 3rd party apps on the phone is just not great at the moment.  The native OS apps use a different UI framework that is going to make all but the simplest 3rd party apps feel sluggish so don’t feel too bad if your app scrolling seems slower.   It’s probably not entirely your fault.  Although this guy (around 8:50) seems to disagree. Sure 3rd party apps will get better with more experience and time, but the runtime needs to also get better.  It’s the v1 of a new platform for everyone.

Finally, most of my thought are based around apps like twitter or facebook or other apps that require lots of live network data and have more complicated/longer list based screens.  A 2 screen unit converter app is just going to be faster because it’s a simpler app and you don’t really need to optimize much.

So here are some things that you can try think about for your application:

• Data binding is always going to be slower than just directly setting a value.  If you don’t have to databind, try to avoid it. I see lots of people going out of their way to MVVM everything and create bindable app bars.  Feel free to just wire up a handler once in awhile or just directly set some text.  There are other ways of centralizing code for reuse instead of trying to adhere to a strict pattern.  If you are trying to animate in a screen and data bind simultaneously, most of the animations will get chopped.  Just directly set enough pieces of data to have something to animate in and then you can do more intensive data binding after the animation is complete.
• As mentioned above – consider the tradeoff of always following the same pattern just for the sake of maintaining the pattern.  Sure it might be easier to maintain, but high performance code doesn’t always look pretty. Be flexible, take shortcuts and do what makes sense for a specific part of the application.  That’s not to say you should ever write bad code, just don’t focus on creating an architectural masterpiece in lieu of something that is performs well.  The end user only sees what you put on screen, not the code behind it.  They don’t really care that you used MEF and have an awesome messaging framework. When i see people over-engineer what should be a simple app just to adhere to some theoretical best practices I get sad.

Read more: Clarity Consulting

Posted via email from .NET Info