Update strategy?

classic Classic list List threaded Threaded
14 messages Options
Reply | Threaded
Open this post in threaded view
|

Update strategy?

Bob Sneidar via use-livecode
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
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Update strategy?

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



_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Update strategy?

Bob Sneidar via use-livecode
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 <[hidden email]> 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
>> [hidden email]
>> Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
>> http://lists.runrev.com/mailman/listinfo/use-livecode
>
>
>
> _______________________________________________
> use-livecode mailing list
> [hidden email]
> Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode


_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

AW: Update strategy?

Bob Sneidar via use-livecode
In reply to this post by Bob Sneidar 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:[hidden email]] Im Auftrag von Graham Samuel via use-livecode
Gesendet: Mittwoch, 10. Mai 2017 13:35
An: How to use LiveCode <[hidden email]>
Cc: Graham Samuel <[hidden email]>
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
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode


_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Update strategy?

Bob Sneidar via use-livecode
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 <[hidden email]> 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:[hidden email]] Im Auftrag von Graham Samuel via use-livecode
> Gesendet: Mittwoch, 10. Mai 2017 13:35
> An: How to use LiveCode <[hidden email]>
> Cc: Graham Samuel <[hidden email]>
> 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
> [hidden email]
> Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
>
>
> _______________________________________________
> use-livecode mailing list
> [hidden email]
> Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode


_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Update strategy?

Bob Sneidar via use-livecode
In reply to this post by Bob Sneidar via use-livecode
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 <[hidden email]> 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
>>> [hidden email]
>>> Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
>>> http://lists.runrev.com/mailman/listinfo/use-livecode
>>
>>
>> _______________________________________________
>> use-livecode mailing list
>> [hidden email]
>> Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
>> http://lists.runrev.com/mailman/listinfo/use-livecode
>
> _______________________________________________
> use-livecode mailing list
> [hidden email]
> Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode



_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Update strategy?

Bob Sneidar via use-livecode
In reply to this post by Bob Sneidar via use-livecode
I think what they do is launch an updater app just before quiting themselves. The updater stack replaces the app stack, launches the app stack then quits itself. Only way I would know how to do it.

Bob S


> On May 10, 2017, at 04:35 , Graham Samuel via use-livecode <[hidden email]> wrote:
>
> 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
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Update strategy?

Bob Sneidar via use-livecode
In reply to this post by Bob Sneidar via use-livecode
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         |     [hidden email]
HyperActive Software           |     http://www.hyperactivesw.com


_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Update strategy?

Bob Sneidar via use-livecode
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 <[hidden email]> 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         |     [hidden email]
> HyperActive Software           |     http://www.hyperactivesw.com
>
>
> _______________________________________________
> use-livecode mailing list
> [hidden email]
> Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode


_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Update strategy?

Bob Sneidar via use-livecode
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         |     [hidden email]
HyperActive Software           |     http://www.hyperactivesw.com


_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

AW: Update strategy?

Bob Sneidar via use-livecode
In reply to this post by Bob Sneidar 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:[hidden email]] Im Auftrag von Graham Samuel via use-livecode
Gesendet: Mittwoch, 10. Mai 2017 20:00
An: How to use LiveCode <[hidden email]>
Cc: Graham Samuel <[hidden email]>
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 <[hidden email]> 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         |     [hidden email]
> HyperActive Software           |     http://www.hyperactivesw.com
>
>
> _______________________________________________
> use-livecode mailing list
> [hidden email]
> Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode


_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode


_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Update strategy?

Bob Sneidar via use-livecode
In reply to this post by Bob Sneidar via use-livecode
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 <[hidden email]> 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         |     [hidden email]
> HyperActive Software           |     http://www.hyperactivesw.com
>
>
> _______________________________________________
> use-livecode mailing list
> [hidden email]
> Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode


_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

AW: Update strategy?

Bob Sneidar 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:[hidden email]] Im Auftrag von Graham Samuel via use-livecode
Gesendet: Freitag, 12. Mai 2017 11:21
An: How to use LiveCode <[hidden email]>
Cc: Graham Samuel <[hidden email]>
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 <[hidden email]> 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         |     [hidden email]
> HyperActive Software           |     http://www.hyperactivesw.com
>
>
> _______________________________________________
> use-livecode mailing list
> [hidden email]
> Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode


_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode


_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Update strategy?

Bob Sneidar via use-livecode
In reply to this post by Bob Sneidar via use-livecode
On 5/12/17 4:20 AM, Graham Samuel via use-livecode wrote:
> 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?

It would be if I still used installers. My long-term client said she'd
never use one again, it caused more problems than it solved. So we use a
plain .zip file now for Windows and a .dmg for Mac. That isn't without
issues as well, mostly for Windows users, who don't always understand
that Windows inexplicably opens the zip file with the contents
displayed, but it isn't really unzipped. When they try to double-click
the .exe file, it fails and usually results in a support call. The
instructions clearly state that they need to move the enclosed folder to
the desktop, but users don't read, especially if it is in giant red text
with underscores and stars and italics and repeated several times.
(Okay, I exaggerate.)

But for the most part she tells me that support is less with this method
than it was for the installer they used to use. It probably depends on
what installer you have. I took over the project post-installer so I
don't have any experience with their previous product.

--
Jacqueline Landman Gay         |     [hidden email]
HyperActive Software           |     http://www.hyperactivesw.com

_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode