Multiple Browser Widgets

[Sannyasin Brahmanathaswami]

Peter TB Brett wrote:

    Yes, you only "pay" for the browser widget once, no matter how many of them you use.  Of course, using lots of browser widgets might require a lot of CPU time and lots of RAM, but it won't make your app into a huge download." -- Peter

-------
BR:

OK thanks, that is clear on the "cost" in terms of app size… but your "CPU time and lots of RAM" point  is important. Let's recast the question where the "cost" is CPU/RAM…especially since I am able to successfully crash our new app in iOS on repeated returns to stacks/cards that invoke browser widgets:

So, to optimize performance on Mobile, 

does it make the best sense to create and delete the widget run time?

Each time it is invoked? 

Or in terms of (to use an old term) the heap space needed… will it suffice to close Stack I when we open Stack II ?  Mobile allows a single view/stack at a time; or does it "cost more" (CPU/RAM) to close and open stacks? i.e. leave the stacks open (in the background) but delete the browser widget and create and delete each browser widget each time it is invoked. Instead of simply showing and hiding it.

OR  if we just set the URL of the browser widget to empty, do we pick up all the heap space (CPU/RAM) it occupied? (this would be easiest)

I am fishing here for best practices to optimize performance and app stability in a scenario where we intend to have a very robust mix of "native" LC content inter-leaved, so to speak with calls to the web server AND local html content packages… the user will be moving back and forth between e.g. a native LC "game like" puzzle, clicking to call a page from the web server, leaving that stack, going to another whose entire UI/UX is built with html5 and then in the next moment clicking to invoke a stack whose content is 100% native LC code/content with images and sounds running from the package itself or stream as URL's (but not into the browser widget), then back again in the next moment to a "portal" that is dedicated to showing our website pages.

Especially on Android, we need to know best practices for make the above scenario performant/crash free.  to reiterate the architecture:

Stack I -- 
opens… there's a link on card 1 which passes a URL to a browser widget which opens (was hidden initially) on the card… another link then hides the Browser widget to bring the card controls/UI forward again.

Now, we have a link in Stack I  that opens

Stack II

Which also has some UI where at some point the user might invoke a browser widget.

and so on

Stack III

Also option to invoke browser widget an, e.g. card 3…

So, after traversing the app, the user may invoke the browser widget 3 to N number of times… in 10 minutes.

where (two scenarios)
    a)  the browser widget URL is fetching data from a remote server 
OR
    b) running an HTML5 app which is packaged in the local app package.