sideloading updates to mobile

Mike Kerner MikeKerner at roadrunner.com
Thu Feb 29 08:28:38 EST 2024


i haven't tried deploying to a device, yet, so bear with me:
when you load the updated stack/behavior/etc., are you saving it into the
app bundle, or elsewhere? on locked/single-app devices, persistence is the
thing (but i would imagine that it works the same on single-app devices as
it does for normal ones).

On Wed, Feb 28, 2024 at 10:12 PM J. Landman Gay via use-livecode <
use-livecode at lists.runrev.com> wrote:

> "Revert this stack". That just means "reload from disk". Or you can
> specify
> a different stack.
> --
> Jacqueline Landman Gay | jacque at hyperactivesw.com
> HyperActive Software | http://www.hyperactivesw.com
> On February 28, 2024 8:12:57 PM Mike Kerner via use-livecode
> <use-livecode at lists.runrev.com> wrote:
>
> > 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."
> > _______________________________________________
> > 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."


More information about the use-livecode mailing list