Loading large files into browser widget

[J. Landman Gay]

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 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