Browser Widget on Android

J. Landman Gay jacque at hyperactivesw.com
Mon Jul 16 18:15:28 EDT 2018


> As long as the app is build with a splash image that matches
> the device resolution (on iOS), then it should work for all.

Android doesn't use this. The stack is always sized to the screenRect 
and resolution is calculated automatically. (I thought the same was true 
for iOS, but it's been a while since I built for that.)

> The buttons on the right set the resolution of the stack.  If the stack
> does not fill the screen, then artifacts of the full screen will remain for
> "blank" areas except for showAll which on my devices does show gray.

This issue was fixed when changing cards in showAll mode but I don't 
think it resets anything when the stack size changes on the same card. 
You can force a redraw with "set the backcolor of this stack to the 
backcolor of this stack".

On Android, just changing the fullscreenMode is enough to see what gets 
cropped, since the stack will always fill the screen.

> By using different combinations of the 2 settings, you can examine how much
> of the stack will be cut off or how the zooming will look.

I'm not sure this is doable as-is, at least on Android, but a new 
"mobileSetFullScreenRectForOrientations" command was introduced to allow 
you to set the default sizes of a stack when the device is rotated. This 
is to allow for changes in layout between portrait and landscape, which 
is what you're doing.

> I did notice that while in the orientationChanged handler, the
> rect is still reported as the previous size.  I use a send in time 0 to be
> sure it is updated properly.  On iOS, the only resize events triggered are
> during startup when the profiles are updated (revSetStackProfile takes care
> of the changes after that).

OrientationChanged is sent before the redraw, so the dimensions aren't 
yet changed (as you noted.) A resizeStack message is sent after the 
rotation which is where layouts can be changed. But resizeStack isn't 
sent when fullScreenMode is in effect, so the "send in time" method is 
better there.

I have the feeling that fullScreenMode and manual layouts aren't 
entirely compatible. Manual layout is the old method and uses 
resizeStack to reset the layout. You could use geometry and profiles for 
that if you like. FullScreenMode was implemented to help us avoid that 
and pretty much works automatically without any extra effort. The one 
exception is if you need different card rects for portrait and 
landscape; in that case you specify 
mobileSetFullScreenRectForOrientations. Unfortunately the dictionary 
entry has missing words and is not very explanatory.


On 7/15/18 5:43 PM, Brian Milby via use-livecode wrote:
> Thanks for doing a test.  I'll need to get some videos together to really
> show what it does.  I'll need to wait until after LCG though... I'm such a
> procrastinator :)
> 
> The stack was built as a proof of concept that the GM and PM could work
> effectively on mobile.  The stack works fully on iOS.  From the above,
> there are obviously some issues on the Android side.
> 
> The buttons on the left set the FullScreenMode of the stack.  It defaults
> to noScale.  As long as the app is build with a splash image that matches
> the device resolution (on iOS), then it should work for all.
> 
> The buttons on the right set the resolution of the stack.  If the stack
> does not fill the screen, then artifacts of the full screen will remain for
> "blank" areas except for showAll which on my devices does show gray.
> 
> By using different combinations of the 2 settings, you can examine how much
> of the stack will be cut off or how the zooming will look.
> 
> Tapping the top circle will replace the bottom portion of the screen with a
> web browser widget (currently set to my web site).  It hides when the
> device is rotated.
> 
> The bottom of the card displays a log of orientation changes and resize
> events.  I did notice that while in the orientationChanged handler, the
> rect is still reported as the previous size.  I use a send in time 0 to be
> sure it is updated properly.  On iOS, the only resize events triggered are
> during startup when the profiles are updated (revSetStackProfile takes care
> of the changes after that).
> 
> Oh, the color changes to the shapes is intentional.  That was mainly to
> show that by using profiles you can do things other that just reposition
> controls.
> 
> Thanks,
> Brian
> 
> On Sun, Jul 15, 2018 at 4:20 PM, J. Landman Gay via use-livecode <
> use-livecode at lists.runrev.com> wrote:
> 
>> I tried your test stack but I don't think I know how to use it. The
>> existing URL in the browser widget (your site) returns an error: Webpage
>> not available, net::ERR_CACHE_MISS. I changed it to google.com and got
>> the same thing.
>>
>> At any rate, changing the fullscreenMode re-wrapped the text in the widget
>> content as needed.
>>
>> When I rotated the device everything went screwy. The previously black and
>> (sort of) white center graphics controls fill colors. Once rotated to
>> landscape it would never go back to portrait. When changing the
>> fullescreenMode (in portrait,) remnants of the previous layout were visible
>> underneath the new layout.
>>
>> More instruction would be good, feel free to write me privately. I didn't
>> examine the scripts.
>>
>>
>> On 7/15/18 10:04 AM, Brian Milby via use-livecode wrote:
>>
>>> I have a question/small favor to ask someone that develops on Android.
>>>
>>> When you place a browser widget on a stack and deploy to iOS, the content
>>> inside the widget is always at native resolution.  If you use a resize
>>> handler or the GM to position the rect and a FullScreenMode of noScale,
>>> everything works as expected.  If you select any other FullScreenMode,
>>> then
>>> the rect of the widget is adjust proportionally based on the mode, but the
>>> content stays the native size (it doesn't get stretched/squished like
>>> other
>>> native LiveCode controls).
>>>
>>> To see this in action, you can use the MobileProfile stack I created (you
>>> will need a splash image set for the actual size of the device for it to
>>> work properly on iOS, not sure about Android).  The top grey circle will
>>> show the browser widget.  The widget hides when an orientation change is
>>> detected.
>>>
>>> Here's a link to the stack.  I can post it elsewhere if needed.
>>> https://www.dropbox.com/s/tt81fn3jw8utmc6/MobileProfile.livecode?dl=0
>>>
>>> My question is how does this work on Android?  My guess is that it would
>>> be
>>> similar in that the content inside the browser widget would remain native
>>> and just the LiveCode controls outside of it would get scaled.
>>>
>>> Thanks,
>>> Brian
>>> _______________________________________________
>>> 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
>>
>> _______________________________________________
>> 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