Launch vs Set in widget

[Mark Waddingham]

On 2019-09-01 01:16, J. Landman Gay via use-livecode wrote:
> Yes, I meant "launch url in widget" which says it opens a url in the
> widget, but that is what "set the URL of widget x" does too. I don't
> see any difference.

As Sean said the difference is the widget, rather than anything else.

The 'launch url in <widget>' syntax calls an OnLaunchUrl handler in
the widget - so the widget could be anything. Obviously for a browser
widget launching a url is the same as going to that url - which means
it is the same as set. It is plausible that you might have a widget
some day which can 'launch a url' but wouldn't have a url property.

> I'm having a terrible time with both acceleratedRendering and the
> browser widget in LC 9.5. I can't fix acceleratedRendering but I think
> I'll try going back to the original mobileCreate method and see if
> that works better. On my Pixel the widget freezes and Android puts up
> its "not responding" error dialog after the user navigates around a
> few pages. It doesn't behave correctly when changing stacks and
> remains visible after the new stack opens, obscuring the card. It also
> freezes when the back history is exhausted. I was curious if setting
> the URL with its launch command would be different.

Hmmm - you say 'on your Pixel' - have you observed the behavior on other
devices, or indeed other Pixels? (It might be worth creating a Pixel
emulator which will be in factory state and see if you get the same
behavior).

The mobileCreate and browser widget use the same system classes so I'd
be surprised if it made any difference switching - especially as the 
issue
sounds like it is to do with navigating between pages in the widget
which is the concern of the system webview class, rather than the 
engine.

One thing which might be instructive is to capture the logcat whilst you
run your app and then cause it to become 'not responding' - such 
situations
are usually accompanied by quite a lot of log lines, especially if some
sort of internal exception is occurring.

> I badly need to be able to respond to the backKey too, but apparently
> that's not possible. The widget eats it. As for acceleratedRendering,
> it's broken. I had to turn it off completely.

Looking at the engine code if you are using the browser widget then you
should be getting the 'backKey' message as normal - if you are using
mobileCreate browser, then *that* would eat it. Do you have a 
mobileCreate
"browser" instance lurking somewhere still by accident?

[ I might have read the engine code wrong though... ]

When you say 'acceleratedRendering' is broken, can you elaborate?

FWIW, we've been using acceleratedRendering alongside browser widgets
internally on Android extensively and haven't seen any issues...

Warmest Regards,

Mark.

-- 
Mark Waddingham ~ mark at livecode.com ~ http://www.livecode.com/
LiveCode: Everyone can create apps