Auto Update

[dabrowBUSXWKD]

Hi
I need advice on creating auto update system for my app.
I have stack "Main" with custom properties and Splash stack that will be compiled to standalone, and will check for if new vers. of app. is available , and download new "Main" . This can I do.
What next ? any tutorial with examples.
Something else that is the problem when I try to download "new Main" stack from my web site is not useful if I use main.livecode , I just can't download it. When I change file to main.rev it is better, I can download but file is corrupted. Do I have to build standalone with new "main" ? then upload it to server ?

How do you guys do it ?
Practical code/ stack example ?

Regards

[Simon]

Hi dabrowBUSXWKD ,
First thing for the corruption I'd gzip the file and unpack it on download. gzip is a known binary download so no fussing with txt.

Do I have to build standalone with new "main" ?

Not sure about this... you said it was called main.rev or .livecode no standalone there. I'm thinking the only standalone you have to build is the splash stack.

I don't know of any complete tutorials on this, here is the start:
http://lessons.runrev.com/s/lessons/m/4 ... pplication
but you are past that I think.

Simon

[Simon]

Hi dabrowBUSXWKD ,
Any luck with this?

Simon

[Klaus]

Hi dabrowBUSXWKD,

do not add your "main" stack in the standalone, ONLY the "splash" stack with all the logics for checking for online updates!

Here is how I made this in one of my last projects:
1. Create the "splash" stack with all the scripts neccessary for checking the online update
You can "start using this stack" in the "openstack" script if the scripts need to be also used in other stacks!
2. Create another MAIN stack -> your stack "main.livecode", which is the "actual" app.
3. Import htat MAIN stack into a custom property of the SPLASH stack:
...
set the cMainStack of stack "splash" to url("binfile:/path/to/your/main.livecode")
...
4. Save the SPLASH stack and
5. create a standalone from the SPLASH

HInt: You do NOT need to add any REV or whatever to a valid stack file, you could even rename a LIVECODE file to "harry.jpg",
it will still be a valid stack file and can be accessed with: go stack "harry.jpg"!

So you should think of any fancy name for the actual "main" stack file!
I will use "data.dat" in my example, sounds pretty "programmer"ish

Now the logics for "pre-/openstack" of the SPLASH:
1. Check if there is a file "datra.dat" in the users prefs folder
-> specialfolderpath("preferences") or something
2. If the file is NOT present, then the user starts the app the very first time and you will need to
## "install" your "main" stack from the custom property:
...
put specialfolderpath("preferences") & "/data.dat" into tMainStackInPrefsFolder
if there is not a file tMainStackInPrefsFolder then
put the cMainStack of stack "splash" into url("binfile:" & tMainStackInPrefsFolder)
else
## 3. You can check NOW if there is new "main" stack online and download it to file: tMainStackInPrefsFolder!
end if
###...BEFORE you:
go stack tMainStackInPrefsFolder
...
Get the picture?

This is the only way to replace an existing Livecode file!
This is NOT possible if the "main" stack is a substack of the splash stack,
since Livecode might have two stacks with the SAME name (not filename!) in memory!


Best

Klaus

[dabrowBUSXWKD]

Thanks @ Klaus for your reply.
This makes a lot of sense and I soon get some more time for this and try to "just do it".
This solution should be "out of the box" in tutorials provided by Livecode in their Academy series.
Regards
Peter

[Klaus]

Hi Peter,

Okie Dokie

Drop a line if you get stuck or need more help!


Best

Klaus

[dabrowBUSXWKD]

Hi Klaus
Have problem.
I can't open "myMain" this one I got from tMainStackInPrefsFolder.
However if I update and download new "myMain" that was easy , It is in memory "tMainStackInPrefsFolder" and can open it from go stack tMainStackInPrefsFolder and open stack "my Main"
And silly ? how do I save from tMainStackInPrefsFolder to file

Peter

[Klaus]

Hi Peter,

Hi Klaus
Have problem.
I can't open "myMain" this one I got from tMainStackInPrefsFolder.

Where and when and whar error do you get?
What did you script?

However if I update and download new "myMain" that was easy , It is in memory "tMainStackInPrefsFolder" and can open it from go stack tMainStackInPrefsFolder and open stack "my Main"
And silly ? how do I save from tMainStackInPrefsFolder to file

How do you load that stack?
I thought of using "libURLDownloadToFile", but you can use this like in my example for storing the CP to disk:
...
## after loading the stack:
put specialfolderpath("preferences") & "/data.dat" into tMainStackInPrefsFolder

## Overwrite eventual older versions:
put tMainStackInPrefsFolder into url("binfile:" & tMainStackInPrefsFolder)

## Then GO to stack:
go stack tMainStackInPrefsFolder
...


Best

Klaus

[JGonz]

Hi,

Here is how I made this in one of my last projects:

That's great, already started implementing it!

Questions:

1. A (probably) old stack stored in an splash stack? Why not check your web space (or github or sourceforge or ...) for the newest version available, and load & install this then?
   .
2. "specialfolderpath("preferences")"? Mac only. Better use "specialfolderpath("Documents")" or "specialfolderpath("home")" in case of Unix, or am I wrong? (+ path ("answer folder "Where to drop?") in case of Mac OS)
   (sry, dropped any engagement in Apple OSses as soon as they dropped any engagement in HyperCard, Newton etc.)
   .
3. I'd try to get zipped packages at my web site, named with enumeration, i.e. MyApp_V0001, MyApp_V0002 etc. These could contain all necessary stuff to update my program, including all instructions to the splash stack.
   So this splash stack could even get the instruction to ask the user "Sorry, my old friend. I'm out of date meanwhile. Allow me to replace me with a new copy of myself?". And then closes & starts a download of a "super-splash" stack that renews the splash stack, starts it and then have it delete itself? Hmmm ...

Just ideas and questions ...

Have fun!

[Klaus]

Hi JGonz,

A (probably) old stack stored in an splash stack? Why not check your web space (or github or sourceforge or ...)
for the newest version available, and load & install this then?

This would require an ONLINE connection to start the app for the very first time!
Not good

...(+ path ("answer folder "Where to drop?")

I would NEVER EVER let the user decide where to store the most important part of my app!
The "MyMain" stack IS in fact the application, the SPLASH stack is only the runtime!

"specialfolderpath("preferences")"? Mac only.

That was just
a. a test of your attention!
b. a quick and dirty example to visualize my concept, I really didn't want to supply a "ready to copy/paste" solution!

I'd try to get zipped packages at my web site, named with enumeration, i.e. MyApp_V0001, MyApp_V0002 etc. These could contain all necessary stuff to update my program, including all instructions to the splash stack.
So this splash stack could even get the instruction to ask the user "Sorry, my old friend. I'm out of date meanwhile. Allow me to replace me with a new copy of myself?". And then closes & starts a download of a "super-splash" stack that renews the splash stack, starts it and then have it delete itself? Hmmm ...

The SPLASH stack IS the standalone and you cannot replace this one, you would need to replace the complete standalone!

Best

Klaus

[JGonz]

Hi Klaus,

A (probably) old stack stored in an splash stack? Why not check your web space (or github or sourceforge or ...)
for the newest version available, and load & install this then?

This would require an ONLINE connection to start the app for the very first time!
Not good

Agree. You're perfectly OK here, I fell to my assumption of an ever-present online connection. But, after all, we're talking of auto-update over the internez here, so - is this assumption this strange?

What I meant was that, in many cases, the main stack (and all sub-stacks) version stored in the splash stack will be outdated at arrival - why then carry this "rather useless pay-load"? We expect the program to auto-update itself, that's topic here, so we'll have a connection, right?

I agree that, for the first installation, a full set of stacks would be nice. In case we'd release on CD/ DVD. That's what I forgot.
But I haven't done such not once anymore during the recent years. Anything I released came to the customer via FTP or HTTP download. My trusty old Plextor burner is covered in spiders webs meanwhile.

And when it comes to downloading, I'd not want to have my customers downloading some MB of stuff they'd never need. Think we can agree this far?

...(+ path ("answer folder "Where to drop?")

I would NEVER EVER let the user decide where to store the most important part of my app!

MacOS (old) only. Where we don't have a suitable pre-defined specialfolderpath here. They can store it everywhere on the disk, and it will work
See below, too.

"specialfolderpath("preferences")"? Mac only.

That was just
a. a test of your attention!
b. a quick and dirty example to visualize my concept, I really didn't want to supply a "ready to copy/paste" solution!

Yup, got it. The problem we'll run in is that we need to get anything but our splash-stack (= runtime) stored in a place where we have write-access. Else we'd have to store all and anything the user could change in our stack system outside of it, and import again at any startup.
And due to the restrictions some OS' are featuring we'll usually need to have the splash stack in the "programs" location, and the connected "work stacks" in the "documents" location, where we have write access, right?

I'd try to get zipped packages at my web site, named with enumeration, i.e. MyApp_V0001, MyApp_V0002 etc. These could contain all necessary stuff to update my program, including all instructions to the splash stack.
So this splash stack could even get the instruction to ask the user "Sorry, my old friend. I'm out of date meanwhile. Allow me to replace me with a new copy of myself?". And then closes & starts a download of a "super-splash" stack that renews the splash stack, starts it and then have it delete itself? Hmmm ...

The SPLASH stack IS the standalone and you cannot replace this one, you would need to replace the complete standalone!

Here I might have been too euphoric ...

Basic idea was that we might have to replace the splash stack, too, sometimes.
How to do this?
My idea was to have the splash stack find out that it's outdated, download and install another standalone containing the updater stack, starting this one and closing itself.
Now the "updater standalone" would delete the old splash stack and replace it with a new version. Start this one and terminate itself.
Got it?

For sure, this might be impossible. I'll soon try it, as soon as I find some spare time. Even if I'll fail badly I'll learn something new


Don't get me wrong, I regarded your post most inspiring, and actually started to work on such a solution. In no way I'm criticizing, I'm just trying to push the envelope to find out what's OK and what will never work.

I have done a similar work years ago in MSAccess (self-updating .mdb's) and from there I know it's the least problem that's to be done in the code itself. The real problems come when there's access restrictions by the OS, and, even better, when these restrictions change from version to version. This is the tricky part, thus my emphasis on specialfolderpaths.

Thanks a lot for your ideas and your help, it's most appreciated.
Please excuse if I'm behaving a bit nOOb-like sometimes, I have started with HyperCard ages ago, went to MSAccess then, and am now trying to come back to the bright side of coding again. And am quite overwhelmed by all the new features and possibilities

Kind regards and thx a lot!

[Klaus]

Hi JGonz, (Jose or Jorge Gonzales? )

I wanted to quote everything for my answers, so you see the context, but I lost the overview in the end

1. I would never require an internet connection for the very first start of my app!
It should at lest "install" ansd start at that time.
After that, AUTO UPDATE starts to make sense for me

2. Mac OS <= 9:
a. specialfolderpath("preferences") is also available for Mac OS <= 9!
b. Mac OS <= 9 is dead, at least for me!

3. Installation of the RUNTIME (Splash stack) will of course demand super user permissions, but:
a. Mac users are used to this when dragging an APP bundle from a DMG to the Application folder
b. Windows users will need a "setup.exe" anyway, which will install into the win "Programme" folder.

4. There are enough "specialfolderpaths" to be able to put whatever into a place with write permission for your app!
For a quite elaborate list of specualfolder pathnames, check this:
http://www.sonsothunder.com/devres/live ... ile010.htm
The rest of the website isn't too bad, either

5. The Splash stack is in fact the runtime and cannot be replaced separately.
This will make a new APP bundle (Mac) and "setup.exe" (Win) neccessary.

In case a new runtime is available, much less frequently than a new (main application in CP) STACK,
I alerted the users to download the DMG/setup and never had any problem or complaints about that.

I actually never had the time to find out how to replace a runtime on the users hd.
This is surely possible, but will need some investigation (and fiddling)


Best

Klaus

[JGonz]

Hi Klaus,

Thank you a lot for this! You helped me finding out about some of my false assumptions, and showed me where my mistakes was.

This will save me a lot of time checking the users machine, to find out why the %!&@ my app/ program wouldn't install/ update properly
Maybe it's of use for our quiet readers, too ...

Thanks again, and have a good time!

PS: "J" stands for "Juan"
PPS: For sure "sonsothunder.com" is in my bookmarks

[Klaus]

Hola Juan,

glad I could help!
Take care!


Best

Klaus

[gpearson]

To take this discussion one step further, what would be some options to update the StandAlone Splash part of an application. Can this be done once the Main Application stack is running or would I need to figure a way to have the user download a new installed with the Splash Screen in a manual process.