System.Nerd.John.Blog

The impact of performance is much more readily apparent in .NET Compact Framework applications.  The mobile devices commonly have a CPU that is 10 times slower than your desktop CPU, and possibly up to 100 times less RAM than a desktop or server.  In Agile or XP development, the mantra is often to ignore performance considerations until necessary – I don’t think you can apply that to .NET CF development or it will really bite you in the end.  You don’t have to go nuts and optimize everything up front, but there are some very important things to keep in mind when developing a Windows Mobile application…

Standard .NET Framework Performance Considerations

Many of the standard .NET Framework performance best practices can become apparent very quickly including…

• Object Boxing and Unboxing.  Use generics wherever possible and avoid ArrayLists and type conversions.
• String and StringBuilder.  Need to perform lots of string concatenations? Use a StringBuilder instead of the ‘+’ operator.  When you use the ‘+’ operator, a new string object is created each time you concatenate, increasing memory usage.  The ‘+’ operator is much slower if you’re concatenating a large number of strings.
• Memory leaks.
  • When doing .NET CF development, if an object implements the Dispose() method – call it when you are finished with the object.
  • One of the most common causes of memory leaks is unhandling events when they’re no longer needed.  If you manually hook up an event with the ‘+=’ operator, ensure you’re unhandling it when finished with the ‘-=’ operator.
  • Pre-allocate collections if possible.  Standard .NET behavior is to automatically double the size of a collection when the upper limit is reached while adding items.  If you know the number of elements that are are going to be in a collection, pre-allocate the size of the collection when instantiating it.
• Don’t use Exceptions for flow control in an application.  Exceptions are an expensive operation, performance wise.  I’m not saying don’t use exceptions, but don’t use them in areas where you can perform simple checks to prevent them from being thrown.  For example, if you might divide by zero – perform a simple check before the operation occurs rather than handling a DivideByZeroException.  The check is much less expensive than the exception.

.NET Compact Framework-Specific Performance Considerations

However, the .NET Compact Framework is different than the full framework in many ways, leading to a slew of .NET CF specific performance considerations…

• Avoid making virtual function calls.  They are up to 40% slower than instance and static function calls.  I don’t completely understand the reason for this, but you can read more about it here if you’re interested.
• There are a few things in .NET CF that are slow because of virtual calls and object boxing/unboxing.  These include:
  • Reflection.  Very slow in .NET CF.
  • XML Deserialization and DataSets.  Extremely slow  because reflection is slow.
• Avoid creating many copies of Form objects.  Creating a Form is an expensive operation, and unused Form objects are a common cause of memory leak issues. You may want to create your Forms once and cache them in the background for reuse.
• You can increase the speed of binding data to controls by using the BeginUpdate and EndUpdate methods on a control before and after your data binding occurs.  This will cause the control to not repaint until the binding is finished.
• Cache expensive resources.  For example, don’t create many different copies of a web service client.  Create a single, cached instance of it that can be used throughout your application.
• Always test your application on a wide range of physical devices.  If the target device is known, at least test on that device.  Some things seem to perform much betterwhen running on the emulator or when executing unit tests on your desktop environment.
• This is a more general performance testing best practice, but always test with real data and real quantities of data. This can really bite you on deployment of your application.  I know this from experience – a great example is that deserializing a few hundred objects is MUCH much faster than deserializing 10,000 objects.  In my experience, deserializing 7,000 very simple DTO objects from an ASMX web service was taking up to 20 minutes in some cases.  To alleviate the issue, we ended up switching to a JSON web service, which was much faster to deserialize.

I’m starting up a short Windows Mobile project again, so I thought it would be a good time to collect some of my best practices for .NET Compact Framework development and post them.  I’m going to break them down into two sections -  usability, and performance best practices (in another post).

Windows Mobile Usability Best Practices

Microsoft has put together a very specific set of guidelines for Windows Mobile usability – the point of this is to get a consistent set of look and feel and application experiences on their platform.  Apple has the same sort of guidelines for iPhone development and it really pays off – most applications have the same consistent look and feel and excellent usability.  Of course, many of these usability guidelines are relevant across many development platforms, but there are some special considerations for mobile development.

Usability is a challenge in mobile development.  Some of the main concerns include…

• Limited screen real estate.  In Windows Mobile, the most common size is around 480 x 640 pixels.
• Limited input options.  Touch screen.  Potentially no hardware keyboard.  No mouse, and no scroll wheel.
• Lighting – Indoor / Outdoor usage.
• Gloves (i.e. warehouse users)
• Finger vs. Stylus

Here are some of the most important usability guidelines that Microsoft has set forth…

• Only display the most relevant information and options on the screen, i.e. don’t clutter up the screen with 100 different rarely used options.  If a feature is rarely used, place it in a menu or submenu.  If a feature or action is used very often, think about assigning it to one of the standard left or right soft keys.
• Use high contrast, sufficiently bright colors.   Lighting conditions are an important factor in mobile development.  For example, think about if your application could be used in low light or outdoor sunlight conditions.
• Avoid very small font sizes.  The screen on a mobile device is very small as-is, and actions on a mobile device are often performed at arms length away from the user (in a warehouse, for example).  If a user has to interrupt their workflow to bring the device in front of their face to read the text, then your font is too small.
• Make the user interface predictable and consistent in your application, keep ‘OK’ and ‘Cancel’ actions in the same location throughout your interface.  The same buttons should perform the same actions throughout your application.  To stay consistent with other Windows Mobile interfaces, one recommendation is to always assign the left soft key to ‘Back’ or ‘Cancel’ actions, and to assign the right soft key to ‘Next’ or ‘OK’ actions.  Another Microsoft recommendation is to avoid overriding the hardware buttons (i.e. the Home button).
• Ensure your UI elements are appropriately sized.  Buttons sized for a stylus should be at least 21 pixels squared, buttons sized for fingerse should be at least 38 pixels squared.
• Keep screen rotation in mind – developing to account for rotation is a pain, but very important for consumer applications.  Your options though are limited to either dynamically resizing the content, or to just design for a square screen.
• Scrolling is discouraged in Windows Mobile applications, because it is kind of a pain for the end user.  Try to keep your content on one screen length/width if possible.
• If your target devices may feature a keyboard, assign common actions to key shortcuts.  This can greatly increase efficiency for power users.
• For displaying information, make use of Summary, Detail, and Edit views.  A ‘Summary’ view displays only the most necessary and relevant information about an item.  To access less commonly used information about an item, the user can drill down to a more complete ‘Detail’ view.  If a user needs to edit the information, they can access an ‘Edit’ view.
• Ensure you’re setting focus on the appropriate text entry fields in bar code scanning scenarios, etc.  If a user is wearing gloves and has to take them off to set focus on a field before they scan a pallet, they’re going to hate your application.