Mobile LC Apps Downloading Stacks After installation
mark at livecode.com
Sat Aug 12 08:51:52 EDT 2017
That sounds like the best approach.
Whilst it might seem 'annoying' to not use code in download files, I think LiveCode still makes it easier to not have to.
It is just that you have to work a little bit harder to separate content from code - and parameterise the parts (using data) which you might have written directly in code if there wasn't such a restriction.
Of course, as Richard points out, there are still areas where 'executable code' has to be allowed (expressions in spreadsheets are code after all - although admittedly side-effect free in some sense which *might* be the start of a line to draw) - however I think it wise to restrict those to things which are created by the user in their documents - and make sure they are heavily sandboxed / only allow very specific actions in line with the purpose the app.
Sent from my iPhone
> On 11 Aug 2017, at 20:21, Sannyasin Brahmanathaswami via use-livecode <use-livecode at lists.runrev.com> wrote:
> Mark, thanks for the thorough explanation.
> I would go on record to say that "vision" for our use of such post/sideloading option would fall well within th UI/UX of the existing app, since, from a design point of view our goals would want it to be virtually transparent.
> That said, the CMS can get a bit snakey over time, and possibly a better way to go, at least in our context of wanting to add on new modules, would be to bundle the LC binary/views/script into updates that would be reviewed and then post download only image-sounds-words-jsons-assets.gz bundles. unpack these and then binary uses them…
> This then allow us to add more to the app without adding more MB to the package size (since these LC binaries as pure view can be as small as 50 K) and then we just use side loading for what really *is* only *data*
> this would be playing it very safe, and in someways, guard against ad hoc dev CMS which is too easy to do with LC
> On 8/10/17, 9:56 PM, "use-livecode on behalf of Mark Waddingham via use-livecode" <use-livecode-bounces at lists.runrev.com on behalf of use-livecode at lists.runrev.com> wrote:
> Taken from this point of view, and looking at very successful Apps
> (typically games) in the stores then you are probably fine if your
> stackfiles have data/code in them which parameterize the *existing*
> actions of the main app in reasonably limited ways.
> So, for example, providing levels to a game where some parts require
> computations of expressions or triggering of particular events - as long
> as those levels are consistent with 'what the game is meant to do' (i.e.
> you don't make it do anything different from what it did with the levels
> bundled with the original submitted app). This model applies to any sort
> of 'content player' - language learning flash cards or lessons would be
> similar - you just have to be careful to make sure you don't end up
> expanding the ability of the main app in a way which is not directly
> 'seeable' in the original submitted app.
> use-livecode mailing list
> use-livecode at lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
More information about the Use-livecode