Re: Best Update Standalone Scenario
Chipp:
"up to you" right.. we have the same thing going on now on the Mac with
/HD/LIbrary/Application Support/
# better, I think, for the "mainstack.rev" than preferences, though I
could be wrong...but on the Mac the "big boys" seem to have some
criteria (which not everyone follows by any means) for what goes
into /Application Support/ and what goes into /Preferences/
Typically, in the past, the latter-prefs can be 100% volatile
without breaking your app.."Trash your prefs" being a typical first
line of attack on a problem... while /Application Support/ carries
critical components, with which the entire app or some funcationality
of it, will fail completely without re-installation...
and
/HD/Users/Chipp/LIbrary/Application Support/
then, finally, just to be absolutely clear and in case newbies are
lurking..
and we haven't addressed this as yet...All of this assumes that the
user can put the SplashScreen-Engine-Player.exe file anywhere they
want to...
Right?
Typically you have no control over this anyway... one person
("Whatever!") has his desktop set as the downloads folder, other
"Virgo Types" ("I Need Perfect order!") meticulously set up
downloads folders, then move their downloaded files out to other
logically named (for them, their projects) folders...
Which would also mean that for a dual file distribution--where you
ship both the
SplashScreen-Engine-Player.exe
MainMyAppStack.rev
together... they will land on the HD in some unknown location: you
would need an additional procedure (not so far mentioned) to move/
copy MainMyAppStack.rev to the specialFolder on start up...
I'm finding that though developers tend to live all day long with a
pipe open to the net, "out there in the real world" that's not always
the case. so one has to consider a single download for installation
with the possibility that the next time the person boots, they will
not be online -- their teenage daughter is having a 2 hour session
with her friend on the phone. Or, people are using portables and are
sitting in the dentist's office and they don't have a
connectionand you don't want your splash screen to say "Sorry, I
know you already downloaded this application but you have to be
online to continue in order to *really* download it [to now get the
MainMyAppStack.rev]
e.g. we just set up an agreement with eGranary for distribution of
large portions of our web content to remote servers (e.g. big box in
a high-school in Nairobi, Kenya) where the model is: download
terrabytes of resources to a local server, then let 500 users on the
LAN have access to the files with no outside connection to the the
"real" internet required... of course this model breaks everything in
terms of updates, which is an issue for eGranary that they are
working on... but, you get the point.. lots of users will not be
online after initial installation.
i.e. so, isn't the dual file "package" the normal initial distribution?
Sorry for dragging this out but it seems a "mission critical" area to
have totally "smooth" and we are looking to launch some very
"professional" apps in the not too distant future to a very broad
audience for which support could be an incredible issue.. .we don't
want to be drowning in a sea of bug reports.
Sivakatirswami
On Oct 22, 2005, at 9:06 PM, Chipp Walters wrote:
Sivakatirswami wrote:
Aloha, Chipp and Mark:
Excellent, thanks... I have copied Chipps scenario to my own
knowledge base.
Two questions:
1) How do you handle the Splash Screen-Engine-Player after the
MainStack is opened... set it to invisible? Just let it sit in
the background behind everything? I would guess the former, which
is more normal UI behavior (I mean there is no Splash screen
present in the visible GUI once the user opens an MS word
document, or any Adobe document either...)
2) Marie Signe recently said the special folder path to /
Application Data/ on Windows was (26)... this email say (35)
Sivakatirswami,
I do the same as Mark, I close the startup stack *after* opening
the regular one.
(35) is for all users, not just a single user. I chose (35) so I
don't have to deal with multiple users (logins) on XP, some having
problems launching the stack(s). Though I do have a few apps which
use the (26) one as well. It's really up to you.
Sometimes I store the downloaded main stack in (35) and user prefs
in (26) so that multiple users can each have their own preference
setting.
You might want to take a look at:
http://www.altuit.com/webs/altuit2/MagicCarpetAAA/default.htm
There's a sample splashStack there as well.
___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your
subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution
_
Re: Best Update Standalone Scenario
On 22 Oct 2005, at 20:44, Sivakatirswami wrote: Aside query about Windows systems... why are two different ones for C:\Documents and Settings\username\Application Data and C:\Documents and Settings\username\Local Settings\Application Data\) The first one, specialFolderPath(26), may be stored on a server where roaming profiles are used. The second one, specialFolderPath(28), is only ever kept on the local machine. You should use the first one for data the user should have access to, no matter which machine the user logs on from (application prefs for example). The second one is typically used for cached data (the Internet Explorer cache is kept here), which isn't really needed in every location. Cheers Dave ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Best Update Standalone Scenario
Sivakatirswami wrote: Aloha, Chipp and Mark: Excellent, thanks... I have copied Chipps scenario to my own knowledge base. Two questions: 1) How do you handle the Splash Screen-Engine-Player after the MainStack is opened... set it to invisible? Just let it sit in the background behind everything? I would guess the former, which is more normal UI behavior (I mean there is no Splash screen present in the visible GUI once the user opens an MS word document, or any Adobe document either...) 2) Marie Signe recently said the special folder path to /Application Data/ on Windows was (26)... this email say (35) Sivakatirswami, I do the same as Mark, I close the startup stack *after* opening the regular one. (35) is for all users, not just a single user. I chose (35) so I don't have to deal with multiple users (logins) on XP, some having problems launching the stack(s). Though I do have a few apps which use the (26) one as well. It's really up to you. Sometimes I store the downloaded main stack in (35) and user prefs in (26) so that multiple users can each have their own preference setting. You might want to take a look at: http://www.altuit.com/webs/altuit2/MagicCarpetAAA/default.htm There's a sample splashStack there as well. ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Best Update Standalone Scenario
Sivakatirswami- Saturday, October 22, 2005, 12:44:33 PM, you wrote: > 1) How do you handle the Splash Screen-Engine-Player after the > MainStack is opened... set it to invisible? Just let it sit in the > background behind everything? I would guess the former, which is more > normal UI behavior (I mean there is no Splash screen present in the > visible GUI once the user opens an MS word document, or any Adobe > document either...) Can't (or won't) answer for Chipp here, but here's the entire Splash Screen script from one of my apps. I put this into the openStack handler because I *want* the splash screen to be visible if there's a problem opening the main stack. Then the user is presented with the splash screen, which has a field that says that an error has occurred and they should contact me. on openStack set the visible of me to false open stack "LPMain" -- the mainStack for this app close me end openStack > 2) Marie Signe recently said the special folder path to /Application > Data/ on Windows was (26)... this email say (35) The difference here is whether you want a single file installed for all users on the computer to share or just for the current user (in which case different users on the computer would have separate copies of the file). Use (35) for the first case and (26) for the second case. -- -Mark Wieder [EMAIL PROTECTED] ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Best Update Standalone Scenario
Aloha, Chipp and Mark: Excellent, thanks... I have copied Chipps scenario to my own knowledge base. Two questions: 1) How do you handle the Splash Screen-Engine-Player after the MainStack is opened... set it to invisible? Just let it sit in the background behind everything? I would guess the former, which is more normal UI behavior (I mean there is no Splash screen present in the visible GUI once the user opens an MS word document, or any Adobe document either...) 2) Marie Signe recently said the special folder path to /Application Data/ on Windows was (26)... this email say (35) Looking at the MSDN site we see: CSIDL_APPDATA (0x001a) Version 4.71. The file system directory that serves as a common repository for application-specific data. A typical path is C: \Documents and Settings\username\Application Data. This CSIDL is supported by the redistributable Shfolder.dll for systems that do not have the Microsoft Internet Explorer 4.0 integrated Shell installed. = specialFolderPath(26) CSIDL_CDBURN_AREA (0x003b) Version 6.0. The file system directory acting as a staging area for files waiting to be written to CD. A typical path is C:\Documents and Settings\username\Local Settings\Application Data\Microsoft\CD Burning. = specialFolderPath(59) CSIDL_COMMON_APPDATA (0x0023) Version 5.0. The file system directory containing application data for all users. A typical path is C:\Documents and Settings\All Users\Application Data. = specialFolderPath(35) Aside query about Windows systems... why are two different ones for C:\Documents and Settings\username\Application Data and C:\Documents and Settings\username\Local Settings\Application Data\) ?? What should we use and why? Sivakatirswami theOn Oct 22, 2005, at 7:32 AM, Mark Wieder wrote: Chipp- Friday, October 21, 2005, 10:56:24 PM, you wrote: Check out http://lists.runrev.com/pipermail/use-revolution/2003-August/ 021590.html The only things I would add to Chipp's excellent writeup are: I have an aversion to apps that "phone home" on their own at startup, so I leave this as an option for the users to check for updated versions on their own. There are obviously cases, though, where you do want the automatic checks to occur at startup. And the "splash screen" approach to segmenting your program also has a couple of advantages that Chipp didn't metion: a) since the process of creating a standalone binds the engine to the mainstack, this then gets attached to the splash screen, making updates much smaller and faster downloads; and b) the user perception of the smaller download is that you're not really giving them a whole new application (you may be), but that it's a minor update, making them feel better about updating the app. -- -Mark Wieder [EMAIL PROTECTED] ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Best Update Standalone Scenario
Chipp- Friday, October 21, 2005, 10:56:24 PM, you wrote: > Check out > http://lists.runrev.com/pipermail/use-revolution/2003-August/021590.html The only things I would add to Chipp's excellent writeup are: I have an aversion to apps that "phone home" on their own at startup, so I leave this as an option for the users to check for updated versions on their own. There are obviously cases, though, where you do want the automatic checks to occur at startup. And the "splash screen" approach to segmenting your program also has a couple of advantages that Chipp didn't metion: a) since the process of creating a standalone binds the engine to the mainstack, this then gets attached to the splash screen, making updates much smaller and faster downloads; and b) the user perception of the smaller download is that you're not really giving them a whole new application (you may be), but that it's a minor update, making them feel better about updating the app. -- -Mark Wieder [EMAIL PROTECTED] ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
RE: Best Update Standalone Scenario
Hi Sivakatirswami That's an excellent topic... I like the simplicity and safety of many programs I use - auto-watch web updates - with an option to turn it off - downloadable improvements, selectable in a list. keep old versions available - for old client (filter out the inaplicable or installed objects). The other simple system, not as practical, was the simple help menu check with a website visit... download the update. quit the program, run the update and done... The good thing about this last one is that I allows lots of safeties like backups in between... Not that the other types of updates show less but it may be less apparent and you may not have control over what is done... Then like Chipp mentioned, there's the stack component. Which is like the first method I mentioned... But with added "functionality" not just data... I don't know if updating scripts on the fly works - certainly not for the compiled stack but for the "library" stacks, it's certainly or probably doable. But it's just as easy to replace these libraries. The point being that you have to think in advance how you want your updates to work... Data, GUIs and Code all have options... Don't forget backups can be important too... cheers Xavier http://monsieurx.com/taoo > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of > Sivakatirswami > Sent: Saturday, October 22, 2005 6:48 AM > To: use-revolution@lists.runrev.com > Subject: Best Update Standalone Scenario > > I've searched through the email lists but it's huge and so > I'll ask an old question (good candidate for an entry in the > RevWiki Cookbooks > section): > > What is the best strategy to auto update standalones. > > I'm finding some users are happier if every app we deploy is > a standalone and then there are no issues about where the > player is, opening the stack etc. especially where these apps > have completely different job descriptions. > > But then, if you want a standalone to update itself what do you do? > Let me run this by you all for comment. > > 1) Keep a version number in a custom prop, in the stand alone. > 2) have the app ping your server for a small file with the > latest version number, > 3) if they two don't match, then prompt the user to update. > 4) on update, the standalone downloads a compressed version > of itself to the folder that it is in and decompresses that file... > Question: what is the best way to do this: > a) overwrite the previous standalone with the same name? Will > all systems allow this if the file is open? I think not > b) or give the standalone a new name the latter is pretty > standard... > "BBEdit 8.6, BBEdit 8.7" > > > 5) then have the standalone save any open external stacks and > quit itself. > > 6) now we leave it up to the user to > a) reboot the standalone if it has the same name... > (but, if replacing an open app is not an option, then this is > also not an > option.) > b) trash the old version and boot the new one. > > I would be interested in the overview, the options, the > caveats etc... and of course cross platform issues (mainly > OSX and Windows) for "best of show update strategies." > > TIA > Sivakatirswami > > > > > ___ > use-revolution mailing list > use-revolution@lists.runrev.com > Please visit this url to subscribe, unsubscribe and manage > your subscription preferences: > http://lists.runrev.com/mailman/listinfo/use-revolution ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
RE: Best Update Standalone Scenario
> What is the best strategy to auto update standalones. I've never done this in Rev, but have in other languages on Windows. What I did was to execute a shell command to run a utility program (the updater) followed by an application close command (exit, quit). Then the updater ran, updates the executable (stand alone) and then executes a shell command to run the real program (now updated) before automatically closing itself (exit, quit). Scott Kane ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Best Update Standalone Scenario
Sivakatir, Check out http://lists.runrev.com/pipermail/use-revolution/2003-August/021590.html best, Chipp Sivakatirswami wrote: I've searched through the email lists but it's huge and so I'll ask an old question (good candidate for an entry in the RevWiki Cookbooks section): What is the best strategy to auto update standalones. ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
