Loading large files into browser widget

J. Landman Gay jacque at hyperactivesw.com
Sun Jun 30 17:37:34 EDT 2019


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 at 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 | jacque at hyperactivesw.com
>> HyperActive Software | http://www.hyperactivesw.com
>>
>> _______________________________________________
>> use-livecode mailing list
>> use-livecode at 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 at 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         |     jacque at hyperactivesw.com
HyperActive Software           |     http://www.hyperactivesw.com




More information about the Use-livecode mailing list