Ha! This is all very educational - thanks! So you make your user go through a classic installation process - more obvious to the user on a Mac. I notice that some of the apps I used in daily life do this (for example, the Microsoft ones do, I think) but others simply do the whole job invisibly (without a visible installer interface) once the user has agreed to the update - usually this is done via a button that is labelled something like “update and re-launch”. Some others simply do the whole update without explicitly involving the user - this was probably a preference set earlier on - I am not quite so comfortable with this, but I guess it’s just a matter of taste really.
The use of the real installer after the user has already gone through the licensing process (when they first obtained the product) seems to me to call for a different “update” mode for the installer. At least my current .dmg on the Mac, made with DropDMG, asks the user to accept the licensing terms etc. Another reason to experiment, perhaps. Anyway, thanks very much for the insight. Graham > On 10 May 2017, at 15:10, Tiemo Hollmann TB via use-livecode > <use-livecode@lists.runrev.com> wrote: > > 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-boun...@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@lists.runrev.com> > Cc: Graham Samuel <livf...@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@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
