I've done this for several mobile apps. As long as the updates only reside
in the app's sandboxed container, even the App Store doesn't care.
Basically, I put a short text file on the server listing the update
version(s) of the file(s), one per line if they are all different. Every
stack in the app suite has a custom property named cVersion. If necessary
you can also add the download URL to the same line. On launch, the app
downloads and parses the text to see if the server version is different
from the installed one. If so, it uses "put URL <serverPath> into URL <docs
path>" to download and save the the updates to the mobile documents folder,
overwriting the old ones.
It's pretty simple, if I understand what you need correctly. I also store
other info in the the text file occasionally, such as a text string
describing the updates so I can show an answer dialog if I want the user to
agree or decline the update (which will reappear on the next launch if they
decline.)
Sample text file is usually something like this:
Stack 1 <tab> https://www.domain.com/updates/stack1.livecode
Stack 2 <tab> https://www.domain.com/updates/stack2.livecode
..
This update provides new functionality and bug fixes.
If you don't want to scan each stack for its cVersion, you can keep a text
file in the mobile documents folder that lists the current versions so you
can easily compare that to the one on the server. After updating the
stacks, update the stored text file as well.
If updates are mandatory, just skip the comparisons entirely and
force-download the updates. If only some of the stacks should be updated,
omit the ones that don't need to be updated from the server file.
--
Jacqueline Landman Gay | jac...@hyperactivesw.com
HyperActive Software | http://www.hyperactivesw.com
On February 21, 2024 12:53:25 PM Mike Kerner via use-livecode
<use-livecode@lists.runrev.com> wrote:
right - no updating the engine + runtime in this scenario, just the
stacks + scripts, and perhaps plugins.
we are going to continue to only privately distribute to our corporate
clients, so the app store won't be part of the equation. that does not mean
that apple won't object, though (but, i believe the rules for privately
distributed apps are much more lenient than for app store apps - at least,
they have been for us, up until now)
On Wed, Feb 21, 2024 at 12:53 PM Klaus major-k via use-livecode <
use-livecode@lists.runrev.com> wrote:
Hi Mike,
> Am 21.02.2024 um 18:47 schrieb Mike Kerner via use-livecode <
use-livecode@lists.runrev.com>:
>
> sorry that i was not clear. we've been using private deploys since around
> 2010, using airlaunch to generate the bundle, and then uploading to a
> private url. that's not what i meant.
> i'm talking about updating/patching an existing app, in place. the
devices
> are in single-app mode, so we would either have to pay for mdm and then
use
> that service to push app updates, OR, if we didn't use mdm, we could have
> the app pull the update and apply it.
> i can kind-of guess how to make it work, but i'm sure there are a couple
of
> tricks that i don't want to have to figure out, if someone else has
already
> figured it out.
you could use the "splashscreen" approach to update one or more stacks,
but that will
of course only work if you do not want to update the actual engine/runtime.
However I'm not sure if Apple will allow this, no problem on Android
however.
Best
Klaus
--
Klaus Major
https://www.major-k.de
https://www.major-k.de/bass
kl...@major-k.de
_______________________________________________
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
--
On the first day, God created the heavens and the Earth
On the second day, God created the oceans.
On the third day, God put the animals on hold for a few hours,
and did a little diving.
And God said, "This is good."
_______________________________________________
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
