Applet Best Practices

  • Article

The first and most important thing that a person considering writing applet needs to do is to stop and consider if they really do need to write that applet.

The answer may very well be "yes", but far more often, the real answer is "no".

Once you've decided that you have no choice but to write the applet, you can still make sure that your applet doesn't interfere with the experience of your customer by following some relatively straightforward "best practices" (there may be others beyond these, but this list functions as a good start).

 

  1. Make sure that your customer has the ability to disable your functionality.  If your applet is a service or a scheduled task, the operating system provides a mechanism to let the disable your applet, otherwise you should provide that functionality.  And make sure that you really do disable your task when the user disables your notification handler - don't just ask the user to hide your notification area icon.
  2. Reduce the number of processes you run.  Combine functionality as often as possible.  Reduce the stack size for the threads in your processes to the absolute minimum.
  3. Windows is a multi-user system.  That means that it's entirely likely that your applet is going to be run from multiple accounts at the same time - on the machine in our kitchen, there are regularly 4 users logged on at once.
  4. Windows is a multi-user system.  That means that you never ever want to launch UI from a service - it only works for the first user logged on (and it doesn't work at all on Vista).  Instead, use COM to launch your application as the foreground user, or use the task scheduler to launch your application as the foreground user (or have an applet which communicates with your service).
  5. If your application has the ability to auto-update (which is a good thing, IMHO), try to avoid running the updater all the time.  Instead bundle the updater with your application, or if that's not possible, use the task scheduler to run your updater once a month (or once a week, or whatever - pick your frequency).  On the same note, let your customer pick the time of day your updater wakes up, and give the customer the choice of whether your updater pre-downloads the update or if you only dowload after the user requests it.
  6. When retrieving data from the internet, use BITS to retrieve the data - that way your traffic doesn't interfere with the user's traffic.  This is true for all applets, not just updaters.
  7. If you're running on Vista, use Vista's priority scheduling mechanism to reduce the priority of your threads - that way your processing doesn't interfere with the user.  This is especially true for search helper applications - they have the ability to seriously impact the user when they run.
  8. Notification area handlers should disappear unless they have something to tell the user.  So it's ok for taskmgr to show a CPU graph, or for the clock to show the time, but if your notification area icon is static, why show it (of course, the caveat is that sometimes people want you to show your icon)?
  9. If your applet is a service, use a delayed auto-start service so you don't slow down the boot process by running your code.

Anyway, that's a start to the list, there may be more that I've missed, so I may update this list as I (or you) come up with others.

Tomorrow: How do I personally feel about craplets?