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).
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?
> 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?
PingBack from http://msdnrss.thecoderblogs.com/2007/08/23/applet-best-practices/
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.
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.
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.
John: As far as I know, the automatic updates popup is intentionally designed to be as annoying as possible. It's letting you know that your machine is vulnerable to known security threats and that you need to reboot it to install the fixes.
One of the major problems we had before XP SP2 was that people would get security updates downloaded to their machines and they wouldn't reboot the machines to accept the fixes. They then got pissed off because they were 0wned as a result of the vulnerabilities.
Larry, since many people will actually take your advice, could you please rewrite #4 so that the COM is the last suggestion?
Applications that use COM are on my list of serious offenders when it comes to bloat (both code and registry). Furthermore they are more prone to breaking down than the regular ones.
Finally, COM is so hard to code properly that majority of people who take your advice on using it will most likely start producing poor code and the problem will only magnify itself.
I agree on all other points. Funny though how I first read the title as "Apple best practices" ;-)
I just booted up my computer and found myself looking at a printer driver update applet, from HP. My demands of a printer are minimal. If this was a security issue, I'd rather it came through Windows Update. Here's what I was thinking this morning. Although I realize that this is more a marketing issue than a technical one, could the use of applets for updating an application be mitigated by a better task scheduling system?
I regularly bit-flip between the Windows and Unix world. I find value in both systems. One thing that the Unix world has on Windows is the cron scheduling system. It allows for some pretty complex schedules and is a great tool for last minute hacks (I wrote a daily email alert system from text logs using nothing more than grep, mailx, and cron.
Perhaps a better scheduling system (or advocation of its use) could lead to less applet bloat.