I was wrong. I do get "browserFinishedLoading" in about 26 seconds, but
it's lying. When I start to scroll down, it acts just like the widget.
It isn't really all there.
I guess that makes sense, assuming the widget is just a wrapper around
the mobileControlCreate code.
On 6/30/19 4:37 PM, J. Landman Gay via use-livecode wrote:
I did some timing tests comparing mobileControlCreate vs. a browser
widget. Both loaded a 10-meg file from the documents folder on an
Android Pixel running Android OS 9 (Pie.)
mobileControlCreate: 26352 ms, 26610 ms (2 tries)
browser widget: 785426 ms (13 minutes).
While 26+ seconds is too long, it's better than 13 minutes. I don't see
a good way around this. Pre-loading the widget in its entirety isn't
feasible, and of course I'd need to delete the dynamic mobile control
when leaving the card to avoid interference with other native controls.
Breaking up this particular document is going to be difficult. All the
links are hashtags that refer to the current document, and there are
thousands of them.
However, I've learned that if the widget browser needs to load quicker,
use mobileControlCreate instead of the widget.
On 6/29/19 6:26 PM, Brian Milby via use-livecode wrote:
Placing the browser widget in a background group and display/hide as
needed is a possible solution to have it retain content.
Thanks,
Brian
On Jun 29, 2019, 6:40 PM -0400, J. Landman Gay via use-livecode
<use-livecode@lists.runrev.com>, wrote:
I have a 10-meg file on disk that I display in a browser widget. It is
heavily tagged and styled. It takes a few seconds to load fully on
desktop in the IDE, but on Android it can take up to 30 seconds or more
to display an internal link, and even then the whole file isn't loaded,
only a portion containing the linked text. If you scroll up or down,
there are blank sections above and below the visible portion which only
show the background color.
Every time the card closes, the widget dumps the content and the next
time you go to the card the whole process starts over again. I need a
way to force the widget to retain its content, or a faster way to load
the file.
If that's not possible then we'll have to break up the file into pieces,
but that is going to be difficult to script for a number of reasons. Any
suggestions? Would the older native browser be any faster?
--
Jacqueline Landman Gay | jac...@hyperactivesw.com
HyperActive Software | http://www.hyperactivesw.com
_______________________________________________
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
--
Jacqueline Landman Gay | jac...@hyperactivesw.com
HyperActive Software | http://www.hyperactivesw.com
_______________________________________________
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
