Udostępnij za pośrednictwem

Applet Best Practices

  • Artykuł

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?

Comments

  • Anonymous
    August 23, 2007
    > you never ever want to launch UI from a service [...] > Instead, use COM to launch your application as the foreground Hmmmmm.  I've read a lot about using CreateProcessAsUser to do it, but I could only get it working in Vista.  On XP, the exact same sequence of calls leading up to CreateProcessAsUser all succeeded and only CPAS itself failed.  Added some calls which others had suggested in various web sites and fora and newsgroup postings, and they all worked, only CPAS itself still failed.  But CPAS itself still succeeds in Vista.  Weird.  So now I should learn how to use COM to try it? > or use the task scheduler to launch your application as the > foreground user (Or use task scheduler to let the foreground user run as Local System, oops.) > or have an applet Or have a WHAT?  In this series of postings, an applet hater is recommending WHAT?

  • Anonymous
    August 23, 2007
    PingBack from http://msdnrss.thecoderblogs.com/2007/08/23/applet-best-practices/

  • Anonymous
    August 23, 2007
    I'd also add:

  • Support proxies.  Either use the IE proxy settings or allow the user to set their own.  If you create your own, you must support authenticated proxies, including NTLM based ones. This constantly bites us my job. Your suggestion on BITS is great, but you should not rely on it.  BITS doesn't work w/in our NTLM authenciated proxy.  BITS runs under local system, and I don't think ProxyCFG can accept a username password.

  • Anonymous
    August 23, 2007
    Great series of articles! On my ThinkPad running Windows XP the default installation with all Lenovo tools consumes ~450MB RAM right after booting (incredible, isn't it?). By carefully weeding out unnecessary stuff I was able to drop that number to ~230MB.

  • Anonymous
    August 24, 2007
    The worst craplet of all time is the Automatic Updates "restart your computer" popup.  I guess maybe it's not that bad; you can disable it by killing the Automatic Updates service.  But it pops up every 2 minutes AND steals focus.  It's just a matter of time before you're typing a document and hit [Enter] at a most inoportune time.

  • Anonymous
    August 24, 2007
    The comment has been removed

  • Anonymous
    August 24, 2007
    The comment has been removed

  • Anonymous
    September 07, 2007
    The comment has been removed