Mobile Rotation Redux

Brian Milby brian at milby7.com
Wed Sep 5 11:20:25 EDT 2018


I've posted an updated version of the stack:
https://milby.us/lc/MobileDemo2.livecode

This version uses the new properties for orientation rects which causes the
engine to send resizestack messages on rotation.  I've also moved the
buttons into a background groups with a behavior that handles the layout
adjustment.  The card resize handler sets the width of the group and then
the group takes care of moving the buttons and adjusting the height (thanks
to Richard's hint in another thread).  Then the card sets the top and width
of the second group which does the same process for the buttons within.
Then the field object is sized based on those changes.

Except for "deviceMax", the button names for the size buttons can be
changed.  The label is what is used for the actual size, so if someone
wanted to test different stack rects they just need to make changes to the
labels.  If the device is in "landscape", then the numbers are swapped when
setting the rect.

The main part of the card is taken up by a field that contains a log of
messages that are received by the app.  It is fairly verbose and whenever
the stack is resized it includes the rects.

One interesting thing I found (possibly a bug) is that (pre)openBackground
messages seem to have an issue if there are multiple backgrounds (multiple
messages sent to a single background instead of one message to each
background).  This issue seems to go back as least as far as LC 6.7.11
(didn't test earlier) on my Mac.  It doesn't matter if the script is in a
behavior or not (tested separately).  If someone can confirm that this
should be reported as a bug, I'll take care of it.

Next thing to add is some navigation and additional cards.  One thought
that I had was a grid (100px major, 25px minor) and some objects to see how
the changes impact the way things look (particularly circles).

Thanks,
Brian

On Mon, Sep 3, 2018 at 4:59 PM Brian Milby <brian at milby7.com> wrote:

> Thanks for running the tests!
>
> I've been working on this stack for the past 2 days.  I've made quite a
> bit of progress and switched to using the new handler to set orientation
> rects.  That simplifies things a bit.  I had to write some code to figure
> out the rect to use for device native though (which wouldn't be an issue
> for a real app since your rect would be fixed at design time).
>
> The math is required because you need to translate the rect.  The
> screenrect is absolute for the device.  The graphic rect is relative to the
> card.  This is only needed for the "showAll" fullscreenmode.
>
> I'm planning on turning the button position action into a group behavior.
> Once I get that done, I'll post an update.
>
> Thanks,
> Brian
>
> On Mon, Sep 3, 2018 at 4:24 PM J. Landman Gay via use-livecode <
> use-livecode at lists.runrev.com> wrote:
>
>> I ran both stacks on my Pixel and they got exactly the same results you
>> reported; in other words, everything worked just fine.
>>
>> I decided to try my theory that we could combine fullscreenMode with
>> individual object placement and we can. This will prevent the tiny image
>> when the device is rotated to landscape. Basically, for a stack that is
>> taller than it is wide, you want showAll in portrait and noBorder in
>> landscape. All I had to do was revise your orientationChanged handler
>> and add some logic to determine the correct fullscreenMode. I suspect
>> mobileSetFullScreenRectForOrientations would do the same thing, but I
>> wasn't focused on that.
>>
>> So in the MobileDemo stack, revise orientationChanged and add the FSM
>> function and it should work. The rest of the handlers can remain as-is.
>> This particular revision only assumes we're using showAll and noBorder;
>> it doesn't address any others. Those are the two that almost all mobile
>> apps use.
>>
>> on orientationChanged
>>    if the fullscreenmode of this stack is not empty then
>>      send "setBackground" to me in 200 milliseconds
>>      send "setFSM" to me in 250 milliseconds
>>      -- updateStatus "Orientation:" && mobileDeviceOrientation()
>>    end if
>> end orientationChanged
>>
>> on setFSM
>>    if the fullscreenmode of this stack is not among the items of
>> "showAll,noBorder" then exit setFSM
>>    set the rect of this stack to the effective working screenRect
>>    if mobileDeviceOrientation() contains "landscape" then
>>      set the fullscreenmode of this stack to "noBorder"
>>    else if mobileDeviceOrientation() contains "portrait" then
>>      set the fullscreenmode of this stack to "showAll"
>>    end if
>>    updateStatus "setFSM:" && the fullscreenmode of this stack
>>    set the backcolor of this cd to the backcolor of this cd
>> end setFSM
>>
>> I had to use your "set the rect of this stack" method to force
>> fullscreenMode to resolve, that's a nice trick. Setting the backcolor of
>> the card to its existing color is a hack workaround that Panos
>> discovered which forces a card redraw. That eliminates the issue where
>> objects outside the card rect don't redraw properly, so now you don't
>> need to lay the device flat to do it.
>>
>> I did wonder why you need the math in the setBackground handler. Doesn't
>> the working screenrect give the right measurements?
>>
>>
>> On 9/1/18 1:35 AM, Brian Milby via use-livecode wrote:
>> > As I like to do, I decided to really over-do the demo test stacks.  The
>> one
>> > I mentioned initially is:
>> >
>> > https://milby.us/lc/RotationDemo.livecode
>> >
>> > The one I just finished working on does a bit more:
>> >
>> > https://milby.us/lc/MobileDemo.livecode
>> >
>> > I built both to test resizeStack and rotation on Android.  I only have
>> a 5"
>> > Fire, so I only was able to test on one device.
>>
>> --
>> 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
>>
>



More information about the use-livecode mailing list