Share via


Power to the Developers part 1

In my recent Power to the People entry I talked about how bad it is for an application to burn CPU cycles when it's not actively being used.  If you're writing an application that does a very simple animation that uses the CPU just 1% of the time, and you leave that animation going all night, every night, you'll cut the standby time on the phone to one tenth of what it should be.  Users will have a 200 hour standby phone that will get only 20 hours with your app running.  Don't do this.

In this entry I'm going to talk about easy things you can do to solve this problem.  These methods are good for stand alone apps, but are probably not sufficient for home screen plugins.  The task is a lot harder there.  Later on, I'll do a part 2 that talks about what you can do in that case. 

There are two main strategies for not beating up the user's battery. 

Don't use the CPU unless you really need to
Say you're writing a falling blocks game.  Obviously you need animations while the user is playing the game.  And that's fine.  While the game is being played, the backlight is on anyway, and it's burning more power than the CPU is anyway.  But what about when the game is paused?  You might be tempted to have a cute animation of a character tapping on the screen and telling the user to play more.  But, is it really necessary?  Consider carefully.

Maybe you think you should wake up every second, check something, and then go back to sleep.  Think long and hard about this.  Can you accomplish the same thing in a different way? 

Say, you've got a text entry field.  Do you really need a blinking cursor?  (Yes, Some Microsoft Apps have one.  Here's an opportunity for you to do better than us....)

Stop using the CPU as soon as you can
Okay, the reality is, there are a number of places where you do need to use the CPU.  Maybe that animation is really important.  You need to show more text than fits on the screen, so you scroll it.  Or the pause animation is actually very important to the gameplay.  Or the text entry just looks wrong without a blinking cursor.  These things can be fine, if used in moderation.  The problem isn't that you did a little animation for a minute.  The problem arrives when you do it overnight while the user is asleep.

There are two very easy things you can do here. 
1) Stop using the CPU when your app isn't in the foreground.
2) Stop using the CPU if the user hasn't interacted with your app for a little while

I've put together some sample code here to demonstrate these mechanisms.  There are two functionally identical samples there, one native and one managed.  The apps run on both PocketPC and Smartphone, and run on WM 2003, WM 2003SE, and WM 5.   The solutions are built with Whidbey Beta 2, so if you've got an older version of our development tools, you probably won't be able to open the solutions.  But you shouldn't have any trouble opening the code files themselves.  Hopefully you'll find that the samples are simple and straightforward. 

In part 2 I'll talk about a third thing you can do.  You can be notified by Power Manager when the screen goes off and halt your animations and CPU burners then.  But I wanted to separate that discussion from this one.   Using Power Manager notifications is challenging and the above methods are really easy.  I want to make sure that everyone does at least the easy stuff, so I'm calling it out first and separately.

Mike Calligaro