AW: Update strategy?

Tiemo Hollmann TB toolbook at kestner.de
Wed May 10 09:10:06 EDT 2017


I have an installer for the updates on both platforms Win and Mac, what makes it pretty easy.
My Splash stack checks for updates (if there is internet, e.g. if you can access URL google.com, if there is a newer version for this platform, etc.). If there is an update, it starts the download of the update (and unzips it on windows), starts the downloaded installer and exit itself.
Now the installer is launched (on Mac the user has to open the DMG) and the installer can replace everything including the start application. At the end of the update the installer calls the (updated) application and the user goes on with the new update. So the update circle is closed.

Tiemo

-----Ursprüngliche Nachricht-----
Von: use-livecode [mailto:use-livecode-bounces at lists.runrev.com] Im Auftrag von Graham Samuel via use-livecode
Gesendet: Mittwoch, 10. Mai 2017 13:35
An: How to use LiveCode <use-livecode at lists.runrev.com>
Cc: Graham Samuel <livfoss at mac.com>
Betreff: Update strategy?

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 at lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode





More information about the use-livecode mailing list