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. Warmest Regards, Mark. Sent from my iPhone > On 11 Aug 2017, at 20:21, Sannyasin Brahmanathaswami via use-livecode > <use-livecode@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 > > > BR > > On 8/10/17, 9:56 PM, "use-livecode on behalf of Mark Waddingham via > use-livecode" <use-livecode-boun...@lists.runrev.com on behalf of > use-livecode@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@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
