Installing new software

[Peter M. Brigham, MD]

On Apr 29, 2012, at 3:49 PM, Peter Haworth wrote:

On Sun, Apr 29, 2012 at 12:07 PM, Alex Tweedly <alex at tweedly.net> wrote:

>> Hmmmm ... I could be wrong (Haven't done it myself), but I thought the
>> usual way to do this was to have a "splash screen" approach
>> 
>> - the splash screen stack starts up and quickly displays a splash screen
>> - then it checks for a new version.
>>       and if there is one the splash stack downloads the new "real" stack
>> - then the splash stack replaces the old "real" stack with the new "real"
>> stack
>> - then the splash stack transfers control to the "real": stack
>> 
>> (with many variations about when / where / what you ask the user ....)
>> 
>> but the essence is that the downloading / replacing is done by the splash
>> stack, not by the real stack, so there is never any need to replace the
>> stack file which is running.
> 
> Hi Alex,
> Thanks for the suggestion. That would work but I'm just not a big fan of
> the "splash stack" approach in general unless there's a genuine (at least
> in my opinion!) reason for having one, like an extended amount of time to
> initialise the program.  In this case, I'd rather delay the user every time
> they run the program with a splash stack if the only reason for it is to
> deal with a situation that happens infrequently.
> 
> But that's just me :-)

The delay in using a splash stack should be minimal, unless you are doing something really time-intensive, and the user will expect a little delay, since almost every app uses the startup to initialize various things. I think building this into your startup routine is the way to go. If no update is needed, the user won't notice a thing, and if one is available you can offer the choice of updating now or postponing it. All that is pretty much industry standard. Unless I'm misunderstanding your objection.

-- Peter

Peter M. Brigham
pmbrig at gmail.com
http://home.comcast.net/~pmbrig