Apparently my theory of why we can't do it in the standalone builder was
wrong, and encrypted scripts don't matter in the app stores. So I'm
still wondering what the reason is for disabling it in the SB.
I knew how to set a password on a stack, but if you do that then you
have to enter the password every time you open the stack during
development. The nice thing about using the SB to set a password is that
it only applies to the built app and you don't need to mess with it
during development.
I can just set a password before I build I guess. A
savingMobileStandalone handler would work for that, followed by a
mobileStandaloneSaved to remove the password.
On 4/18/19 11:30 AM, JJS via use-livecode wrote:
If you use this sentence in the message box (which i got from another
fine member here) the stack is encrypted, and when turned into an APK is
well accepted by Google Play Store:
*set*thepasswordofstack"beststackever"to"mostdifficultpasswordofalltimes"
Op 18-4-2019 om 02:33 schreef Richard Gaskin via use-livecode:
J. Landman Gay wrote:
> Finally got to this. The password is saved in the standalone custom
> property set, but when testing on a trial standalone it isn't actually
> being used. So the answer is "no, you can't set a password on a mobile
> app via the standalone builder."
>
> After thinking about this, I realized that since none of the three
> major app stores will accept an encrypted app, that's why it's
> disabled.
That seems a strangely LiveCode-specific policy. It would be cool if
Apple, Google, and Amazon were so impressed with LC that they felt the
need to write policies just for it, but I suspect I merely don't
understand.
If the policy prohibits encrypting compiled machine code, I can
understand it. All three use automated processes to review code for
inappropriate symbols, and encryption would thwart those good efforts.
But LC standalones don't encrypt the engine, only the scripts. The
compiled machine code remains available for automated review, while
the it's just scripts that operate within the constraints imposed on
that engine sandbox that are protected. In that sense they're not much
different from tokenized bytecode used in many game engines.
Unless this policy is oddly LiveCode-specific, I suspect you've
discovered a regression, one worth reporting.
_______________________________________________
use-livecode mailing list
[email protected]
Please visit this url to subscribe, unsubscribe and manage your
subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
--
Jacqueline Landman Gay | [email protected]
HyperActive Software | http://www.hyperactivesw.com
_______________________________________________
use-livecode mailing list
[email protected]
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
