Your conflicting name problems is an example of why it is often best to have an "updater" or "installer" stack or executable.
What gets downloaded and run is a stack whose function is to shut down the old stack and clear it out of memory and download the new version and set it up and then exit itself On 5/10/2017 9:10 AM, Graham Samuel via use-livecode wrote: > Thanks for the quick reply, Paul! > > I have already got the idea of the text file and the test you mention. I now > have to experiment with the “open invisible” approach. I have had so many > problems with the IDE when trying to open two stacks with the same name (it’s > impossible AFAIKR - because LC doesn’t have any hierarchical concept of stack > names). So maybe I have to give my updated stack a fake name, download it, > activate it, get it to delete the old stack (since that one isn’t running any > more) and then change its name to the ‘normal’ name formerly given to the now > deleted stack… seems convoluted. Time to experiment, I guess. > > Graham > >> On 10 May 2017, at 14:05, Paul Dupuis via use-livecode >> <use-livecode@lists.runrev.com> wrote: >> >> There are a number of ways to potentially do this, but you have the gist >> already. >> >> I'd recommend a check for updates that just fetches a text file with the >> latest version number from your sever with a : Put URL <locationOf >> VersionFile> into tSomeVar >> check the result for any error, such as the internet not being available >> >> Then compare the current version to the new version in tSomeVar. If >> there is no new version, exit your update handler. If there is a new >> version, you can then download the new stack from a fixed URL OR the >> version text file could contain the version number and URL ofthe new >> stack as 2 items or 2 lines. >> >> You can open invisible URL <urlOfNewStack> >> >> To download and open the new stack in memory. That stack may not be you >> "new" stack of your application, but an updater stack that fetched you >> new application stack, and updates your old stack. >> >> >> >> On 5/10/2017 7:35 AM, Graham Samuel via use-livecode wrote: >>> Apologies if this has come up relatively recently, but I have not been very >>> attentive to the list for a bit… >>> >>> I have a desktop app (though in principle it could be on mobile) which uses >>> a variant of the ‘splashscreen’ structure. What happens is that the app as >>> seen by the operating system is actually an initialisation stack, which >>> then calls in a stack containing the bulk of the script and graphics for >>> the app and executes that. (I call this a ‘data stack’ although this is a >>> bit of misnomer, as it does contain the script libraries that do most of >>> the work.) The clean (template) copy if this data stack is stored in the >>> app’s resources folder, and is loaded the first time the app is started; >>> thereafter the user can alter the data stack, and the altered version is >>> saved in the application data folder. There is a reset facility for going >>> back to the clean template. >>> >>> When a new version of the app is installed, the splash stack detects that >>> the data stack is in old format (actually, that it has an old version >>> number) and forces a reset, thus ensuring that the latest data stack comes >>> into use. >>> >>> All this works quite nicely, but I notice so many apps that automatically >>> check for updates, providing a dialog to the user offering to do the >>> update: if the user agrees, then the update takes place without further >>> intervention. >>> >>> I can kind of see how to do this (the splash stack checks with the server >>> where the app originated to see if there is a more up to date version, then >>> somehow replaces itself), but are there any gotchas in this approach? One I >>> can think of so far is when the user runs the app offline, so that any >>> approach to the server will fail - not sure how to detect that. Also, so >>> far I am vague about how a running standalone can replace itself - >>> something do do with file names, perhaps? >>> >>> I’d be grateful for any advice or experience. >>> >>> Graham >>> >>> >>> _______________________________________________ >>> use-livecode mailing list >>> use-livecode@lists.runrev.com >>> Please visit this url to subscribe, unsubscribe and manage your >>> subscription preferences: >>> http://lists.runrev.com/mailman/listinfo/use-livecode >> >> >> _______________________________________________ >> use-livecode mailing list >> use-livecode@lists.runrev.com >> Please visit this url to subscribe, unsubscribe and manage your subscription >> preferences: >> http://lists.runrev.com/mailman/listinfo/use-livecode > > _______________________________________________ > use-livecode mailing list > use-livecode@lists.runrev.com > Please visit this url to subscribe, unsubscribe and manage your subscription > preferences: > http://lists.runrev.com/mailman/listinfo/use-livecode _______________________________________________ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
