Mobile Rotation Redux

Brian Milby brian at milby7.com
Thu Sep 6 00:41:05 EDT 2018 

With an astute observation from Jaque, I was able to figure out why the
messages didn't seem to be flowing properly.  Since I only read the
openBackground entry, I missed the note about needing to pass the message
for other backgrounds to handle.  I've updated the file that I posted.
Eventually I will put it on GitHub with a proper license file, but the code
is going to be GPL compatible for use in the Community Edition.

https://milby.us/lc/MobileDemo2.livecode

Would something like this be useful as a test for device/OS combinations?
I could add a button to email the log and a standard protocol could be
developed and the output validated.

Thanks,
Brian

On Wed, Sep 5, 2018 at 10:20 AM Brian Milby <brian at milby7.com> wrote:

> 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