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@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@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 | jac...@hyperactivesw.com
HyperActive Software | http://www.hyperactivesw.com
_______________________________________________
use-livecode mailing list
use-livecode@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@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 | jac...@hyperactivesw.com
HyperActive Software | http://www.hyperactivesw.com
_______________________________________________
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
