Windows Phone 7 Design Considerations

Windows Phone 7 is an amazing platform. It delivers what it promised. But the experience is not 100% complete. Now it’s up to us to complete the experience by developing some cool apps.

Now We all are aware that a Silverlight developer can easily develop apps for Windows Phone. Yeah, we still have all the Drag and Drop goodness, but we need to keep into consideration , when we are designing the application, that the target device is a phone with 1 GHz single core processor , Most of us will develop apps on a Core 2 Duo machine.

Since, I have been playing around with Silverlight development experience, am not sure about whether these points are exactly applicable( as is) to XNA game development. But still, here it goes:

1. Keep the User Experience simple:

The Silverlight runtime on the phone does not exactly have a lot of raw processing power available, so it has been optimized accordingly. There are certain points that you need to take into consideration when designing UI for the phone.

– Keep it simple

Less Elaborate UI means Less Code means less activity which will lead to better performance

– Limit the activity on the UI thread

The UI thread must be limited to User interaction , accepting input etc.

– Leverage the Render thread

The render thread, is separate thread that will take care of simple animations etc. This will result in smoother User Experience ( Remember, customer experience comes first)

– Leverage the GPU of the phone

We have a dedicated GPU on the phone. Use it! And Since yours is the only program that runs in the foreground, you can design your app to leverage the GPU (and by that I meant justifiable usage , remember you are running on a small handheld device )

As you must be aware that on a small radio device, transmitting from the device can always prove to be more costly as compared to receiving transmission ( in terms of battery life). The Same principle applies here too.

Upload/ Send to server only the data you need to, Say for example, In your app, you receive an array if say tasks, in which say you update some of these tasks, instead of sending the entire updated array to the server ( or your backend service) send across only some information, such as only the ID of the Task, property changed and the updated value.

This will result in overall better application performance as well as better battery life on the phone ( Very crucial IMO)

3. Deactivate Quickly

In WM 6.x, apps never had an exit option, There never was an event that would let us know that the app is about to get killed. So in order to overcome this danger, what people did was to save state of the application periodically.

Well in Windows Phone 7, You do have an App Closing and App Deactivating event. ( Not sure about what that means? , read my post on WP7 app life cycle). When you receive this event, you save data to the phone’s isolated storage/ or some backend service and retrieve it back when the app activates again.

Now If your app is mammoth and needs to save a lot of data in the deactivating event, Your app will take time to tombstone. What this will lead to is a delay in the launched/chooser to show up making the phone run sluggish.

What we can do to overcome this is to save state periodically ( When people say OLD IS GOLD, they aren’t kidding, are they?)

4 Responses

Since if you receive an App Deactivating (or App Closing) event, you’re process could likely be toast soon this might be slightly less important, but be sure not to forget a “dt.Tick -= [reference to the dt_Tick EventHandler you created];” in there as well!

Only today I read a Dutch blog entry by Dennis Vroegop telling us all about the sleepless night he has had because of the fact that objects referenced by DispatcherTimers through Tick events are kept alive by the framework: http://twitter.com/dvroegop/status/19560049152

You could try reading this blog post in machine translated English if you go to: http://is.gd/dJDJT;-)