AW: Update strategy?

[Tiemo Hollmann TB via use-livecode]

I have codesigned my installers for Mac and Win, so that there are no 
additional security alerts and user request. If the installer is launched as an 
Admin (what I can require for with my innosetup installer for Win, on Mac I 
can't require, but most Mac users have admin rights), it replaces everything 
existing (except of my registration file at another location)  without 
additional requests.

Tiemo

-Ursprüngliche Nachricht-
Von: use-livecode [mailto:use-livecode-boun...@lists.runrev.com] Im Auftrag von 
Graham Samuel via use-livecode
Gesendet: Freitag, 12. Mai 2017 11:21
An: How to use LiveCode 
Cc: Graham Samuel 
Betreff: Re: Update strategy?

Thanks again Jacque

Yes, I see the wisdom of that - your method also avoids the issue of launching 
a completely automatic update without giving the user an opportunity to refuse. 
So you just get the user to run the installer, the same way as Tiemo does - is 
that right? 

Obviously one wants the update to be as user-friendly as possible. Can the 
installer (on Mac and Windows) simply clear out the old version without asking 
for permission? This is desirable from an ease-of-use standpoint. Presumably 
also if registration has already taken place, the record of that will still be 
stored in the local prefs file or wherever, so the user won’t have to re-insert 
the registration key.

Still trying to get it exactly right.

Graham

> On 10 May 2017, at 22:11, J. Landman Gay via use-livecode 
>  wrote:
> 
> On 5/10/17 1:00 PM, Graham Samuel via use-livecode wrote:
>> Yes, but what if you want to update the launcher itself? Maybe I have 
>> made my ‘splash’ stack too rich in function, but I can easily see it 
>> needing revision. Because of this, I’m thinking of altering the 
>> structure of the app so that the update code is more or less all that 
>> is in the standalone recognised by the operating system, and all 
>> other stacks (including 90 percent of the original splash stack) are 
>> simply downloaded after the decision whether to update is made. Or is 
>> this stupid?
> 
> No, it's smart. The launcher should be the barest minimum required to get the 
> rest of the data/stacks/whatever to load. That way there is rarely a need to 
> update.
> 
> I've generally taken the easy way out. If I do need to update the launcher 
> itself, it asks the user if they want to update and then launches a URL to a 
> web page that has the download. I figure if the user could get it installed 
> the first time, they can install the update. That's lazy on my part, but so 
> far there haven't been many issues with it.
> 
> That's for desktop only. On mobile it's easy to let the OS do the updating.
> 
> -- 
> Jacqueline Landman Gay | jac...@hyperactivesw.com
> HyperActive Software   | http://www.hyperactivesw.com
> 
> 
> ___
> 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

AW: Update strategy?

[Tiemo Hollmann TB via use-livecode]

Even if you try to keep the code in the "update launcher" as small as possible, 
there can still keep the whish to update the "update launcher" itself, as you 
say. E.g. I once had to revise the options on how to check for a new update in 
the "update launcher". Starting a download, launching the downloaded update 
installer and exiting itself can update anything you want including the 
launcher itself.
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 20:00
An: How to use LiveCode 
Cc: Graham Samuel 
Betreff: Re: Update strategy?

Yes, but what if you want to update the launcher itself? Maybe I have made my 
‘splash’ stack too rich in function, but I can easily see it needing revision. 
Because of this, I’m thinking of altering the structure of the app so that the 
update code is more or less all that is in the standalone recognised by the 
operating system, and all other stacks (including 90 percent of the original 
splash stack) are simply downloaded after the decision whether to update is 
made. Or is this stupid?

Thanks as ever for your reply.

Graham

> On 10 May 2017, at 19:08, J. Landman Gay via use-livecode 
>  wrote:
> 
> On 5/10/17 8:10 AM, Graham Samuel via use-livecode wrote:
>> 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).
> 
> I put the update code into the standalone launcher, and run it before it 
> opens the data stack. That way you don't have two data stacks at the same 
> time.
> 
> -- 
> Jacqueline Landman Gay | jac...@hyperactivesw.com
> HyperActive Software   | http://www.hyperactivesw.com
> 
> 
> ___
> 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

AW: Update strategy?

[Tiemo Hollmann TB via use-livecode]

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 
Cc: Graham Samuel 
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