Sudhindra Kovalam's Blog

My Geeky Blog

Windows Phone 7 Design Considerations

with 4 comments

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 )

If you are interested in drilling down more, there was a nice session at MIX’10 on Silverlight performance on Windows Phone. Seema Ramchandani’s session on Silverlight performance on Windows Phone.

2. Make sure you only upload necessary data:

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?)

We can do something on these lines:

    // Constructor
    public App()
    {
        UnhandledException += Application_UnhandledException;

        // Standard Silverlight initialization
        InitializeComponent();

        // Phone-specific initialization
        InitializePhoneApplication();

        // Add a Timer to save state Periodically
        DispatcherTimer dt = new DispatcherTimer();
        dt.Interval = new TimeSpan(0, 0, 0, 10); // 10 seconds
        dt.Tick += new EventHandler(dt_Tick);
    }

    void dt_Tick(object sender, EventArgs e)
    {
        //Dirty Flag is set, when something that has to saved 
        // in the application's state has changed.
        if (_dirtyFlag)
        {
            // Save state incrementally.
        }
    }

    // Code to execute when the application is deactivated (sent to background)
    // This code will not execute when the application is closing
    private void Application_Deactivated(object sender, 
        DeactivatedEventArgs e)
    {
        System.Diagnostics.
            Debug.WriteLine("Go to sleep...zzz");
        if (_dirtyFlag)
        {
            // Only save state if there is a change.
        }
    }


Well these are all the points i can think off as of now.

These may not be applicable to all apps that we will write on WP7 , But i believe it is “Good to Know / Things to ponder on, when designing my WP7 app” stuff.

Any suggestions/ comments/ thoughts/ abuses are welcome.

About these ads

Written by sudheerkovalam

July 26, 2010 at 5:14 am

4 Responses

Subscribe to comments with RSS.

  1. 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 ;-)

    peSHIr

    July 26, 2010 at 11:50 am

    • @peSHIr Thanks for the nice tip.

      I was just demonstrating my point.
      Would definately look into posting a more complete code sample.

      sudheerkovalam

      July 26, 2010 at 3:13 pm

  2. Also note that if the App takes to long to tombstone, it will simply be killed and you’ll have an inconsistent state.

    I’d love to see some info on the performance of the emulator (not that snappy on my Core i5) compared to the minimum phone.

    Heine

    July 26, 2010 at 2:39 pm

    • @heine, i think that is what will happen if your app takes too long to de activate.
      My point was, to deactivate fast so that the app switching experience is seemless.

      Performance of the emulator has improved a lot since april CTP.
      As far as your box is concerned, Check if you have WDDM 1.1 certified display drivers (upgrade, if possible)

      sudheerkovalam

      July 26, 2010 at 3:19 pm


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Follow

Get every new post delivered to your Inbox.

%d bloggers like this: