On 2020-03-25 21:07, Mark Waddingham via use-livecode wrote:
I will make a note to double-check the macOS AppStore rules in the
next day or so (this is assuming you are thinking about macOS AppStore
submission), but from memory they are very much aligned with the iOS
AppStore ones in this regard
Sean:
Sorry, I guess the discussion got going onto issues of how to keep an app
updated, which was a major feature of web deployment.
Thanks for all your input, Sean. Very helpful.
Best,
Bill
William A. Prothero
https://earthlearningsolutions.org
> On Mar 25, 2020, at 5:37 PM, Pi Digital via us
My apologies for the misunderstanding. I thought we were all still talking
about HTML5 deployment with a small digression question regarding iOS. Somehow
I missed the part where it got steered off into every other platform :)
Sean Cole
Pi Digital
> On 25 Mar 2020, at 23:34, William Prothero vi
What I was thinking of was distributing a fairly basic educational application,
then adding features and lessons as life goes on. Sounds like it would depend
on how extensive the features were. Perhaps lessons would only trigger a
problem if they required the addition of significant new features
On 3/25/20 1:58 PM, Mark Waddingham via use-livecode wrote:
However there are two rules which must be followed:
1) Downloaded code must not allow the app to access any more system
provided APIs that it could before.
2) Downloaded code must not allow the app to 'morph' (as Richard put
On 2020-03-25 20:52, William Prothero via use-livecode wrote:
But, what I really would need to verify before I go that way, is
whether Catalina allows livecode script to be downloaded and executed
by the engine. Richard, it looks like you say it will, but Sean says
no.
Catalina in general does
On 2020-03-25 19:31, Pi Digital via use-livecode wrote:
In an app on the AppStore this is definitely a security risk from
Apple’s point of view. Devs could insert any nefarious code into their
app. This has been true from iOS2. Only content like video and
images, maybe some animation data and so
Richard and Sean:
My app is desktop. One of the actions is clicking on a map to specify a data
(of various kinds) profile across a great circle path. You really need a mouse
to accurately select a point (although there are ways of magnifying small area
to get precise location).
Anyway, it does
In an app on the AppStore this is definitely a security risk from Apple’s point
of view. Devs could insert any nefarious code into their app. This has been
true from iOS2. Only content like video and images, maybe some animation data
and so on is deemed ok and encouraged.
I was mainly reverin
Bill Prothero wrote:
> Richard and Sean,
> Good ideas. I had considered deploying it as a standalone that has
> sections that udate from a server, but worried that the new security
> requirements from Apple, in particular, discouraged (prohibited?)
> downloading code. Is that not true?
Is this de
Richard and Sean,
Good ideas. I had considered deploying it as a standalone that has sections
that udate from a server, but worried that the new security requirements from
Apple, in particular, discouraged (prohibited?) downloading code. Is that not
true?
Bill
William Prothero
http://es.earthe
Break it up into smaller substacks and have these loaded into the main
stack as needed. HH had an example of this. It would mean that you only
update the parts that need doing. I'm looking to add this into my webapp as
we speak as eventually there will be many sections the main stack will
access.
William Prothero wrote:
> I’m back working on an educational app teaching plate tectonics.
> When I think of pitfalls of distributing an actual app, I fondly
> look at web distribution, like I used to be able to do with Director
> in shockwave.
Shockwave made many things about deployment simpler
Sean:
You are performing a noble task. After a hiatus, I’m back working on an
educational app teaching plate tectonics. When I think of pitfalls of
distributing an actual app, I fondly look at web distribution, like I used to
be able to do with Director in shockwave. Anyway, I’d gladly pay well
Bill
I get what you mean by both quirky and the need for other skills. I’m gradually
going through the code to remove the quirkiness but I’m doing this while also
trying to develop the solution for our clients. In the process I will also
either eliminate the need for learning the ‘other skills’
Sean:
It looks really nice If HTML5 deployment didn’t look so quirky and require such
a variety of other than livecode skills, I’d give it a try. I hope it will
mature before I get too old to care.
Bill
William A. Prothero
https://earthlearningsolutions.org
___
Thanks Colin. That’s definitely helpful. From that I discern that it is
something in your code from the point where the first ‘on openCard’ happens to
the next openCard. An excellent method I use in these cases are to create
messages to the JS console in Chrome by using something like this:
on
The simple test worked, but the missing file errors still showed up.
I will try some old fashioned answer “hello” lines in the stack scripts, to see
how far the real stack is getting.
> On Mar 23, 2020, at 9:53 AM, Pi Digital via use-livecode
> wrote:
>
> You shouldn’t need the stdio.html fi
I deselect everything in standalone application settings except for HTML5. I
choose Save as Standalone Application, and when it is done I copy the files
into a folder inside my home / Sites folder. I do rename the html to index.html
because another approach I was trying required there to be an i
You shouldn’t need the stdio.html file at all. It is a placeholder effectively
for some other command you are referencing.
Again, both using community and Indy and html5deployment versions I have no
issue with 404 errors like this. So it’s likely something in your setup. So a
step-by-step guid
stdio.h is file I/O, and I have copies of that in Unity. The missing file is
stdio.html, not sure what that is, but maybe a JavaScript variation of the C
header file.
I have Indy installed now, and am trying to retrieve my license to give that a
go.
> On Mar 22, 2020, at 5:59 PM, Pi Digital v
Mac, only building for HTML5, tried different browsers, but mainly Safari,
local server set up with:
php -S localhost:8080
The graphics of the stack appear, but is covered by a gray box, that may or may
not be something in the stack. I can tell from a field that shows the current
date that eve
Hi Colin
I’ve done a bit of digging and stdio is an api for file IO used in emscripten.
It’s also used for accessing external site pages. Additionally, LC uses it to
write to the log message box on your main page.
So, I’m curious about the method you go through to get to this point of error.
I have only used the standalone publishing, I’m not doing anything custom. Line
48 of standalone-community-9.5.1.js is what is talking to the stdio.html file.
That part of the code says this:
http.open("POST",”stdio.html"
___
use-livecode mailing li
Hi Colin
What is it that is requesting stdio.html. In your HTML is there any reference
to it? I’m using HTML5 deployment daily but have not come across this.
Sean Cole
Pi Digital
> On 21 Mar 2020, at 21:31, Colin Holgate via use-livecode
> wrote:
>
> I’m trying to get a stack going in HTM
I’m trying to get a stack going in HTML5, and there is a 404 error about a file
named stdio.html. Is that a file I’m supposed to get from somewhere else?
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, un
26 matches
Mail list logo
