sideloading updates to mobile

[Mike Kerner]

so, how do we force LC to reload the stack?
i can force the script to reload, and replace it, but if i want to reload
the stack, do i have to close it, replace it, and then open it?

On Wed, Feb 21, 2024 at 8:28 PM Mike Kerner <MikeKerner at roadrunner.com>
wrote:

> thanks, jlg. that's kind-of what i was thinking.
>
>
> On Wed, Feb 21, 2024 at 4:58 PM J. Landman Gay via use-livecode <
> use-livecode at lists.runrev.com> wrote:
>
>> 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 | jacque at hyperactivesw.com
>> HyperActive Software | http://www.hyperactivesw.com
>> On February 21, 2024 12:53:25 PM Mike Kerner via use-livecode
>> <use-livecode at 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 at lists.runrev.com> wrote:
>> >
>> >> Hi Mike,
>> >>
>> >> > Am 21.02.2024 um 18:47 schrieb Mike Kerner via use-livecode <
>> >> use-livecode at 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
>> >> klaus at major-k.de
>> >>
>> >>
>> >> _______________________________________________
>> >> use-livecode mailing list
>> >> use-livecode at 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 at 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 at 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."
>


-- 
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."