paul at researchware.com
Wed May 10 15:48:57 CEST 2017
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.
>> On 10 May 2017, at 14:05, Paul Dupuis via use-livecode <use-livecode at lists.runrev.com> wrote:
>> There are a number of ways to potentially do this, but you have the gist
>> 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.
>>> use-livecode mailing list
>>> use-livecode at lists.runrev.com
>>> Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
>> use-livecode mailing list
>> use-livecode at lists.runrev.com
>> Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
> use-livecode mailing list
> use-livecode at lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
More information about the use-livecode