(area used by) Keyboard in iOS 15.x
Mark Smith
marksmithhfx at gmail.com
Sun Mar 20 14:17:53 EDT 2022
Hi Sean, I finally got around to doing some further testing on this. Initial results were confusing so I used the “Mobile Orientations” LC lesson to do some testing with iPhoneSafeAreaInsets()
This is a very simple stack with one button. The idea is it demonstrates how if you “allow” certain orientations the screen will redraw and the button will be repositioned (not appropriately, but it is suggested you can refine this further).
So using this very simple stack I added a handler to my previous demo to get the iPhoneSafeAreaInset() values if the device orientationChanged and then displayed these with the button.
I tested on both the sim and real device (iPhone12) and the results are not encouraging.
on a 6S in the sim:
portrait (0,20,0,0)
L right (0,0,0,0)
L left (0,0,0,0)
P UD (0,0,0,0)
iPhone 12 sim
portrait (0,47,0,34)
L right (0,47,0,34)
L left (47,0,47,21)
P UD (didn’t allow though it was included as allowable)
iPhone 12 real
portrait (0,47,0,34)
L right (0,47,0,34)
L left (0,47,0,47) (??)
P UD (47,0,47,21) (again didn’t rotate screen but I copied the reported values anyway)
I did lots more testing of course, which I won’t bore you with. Conclusion: even the initial results reported for the 12 are not ideal. The “34” you see for “bottom" on the 12 should really be 21. I tested this by manually inserting 21 and it looks much better than 34.
Honestly, I don’t think iPhoneSafeAreaInset() returns realistic values for all coordinates, and therefore can’t really be depended on. Since I am only interested in portrait (at the moment), I will do some further testing to see if I can get reasonable results for most devices using this orientation (including inserting hard coded values where necessary).
All the best,
Mark
> On Feb 11, 2022, at 12:31 PM, Pi Digital via use-livecode <use-livecode at lists.runrev.com> wrote:
>
> Hi Mark
>
> This is really useful to know. Thanks for all your testing and research.
>
> Just a note about what iPhoneSafeAreaInsets is for. It returns the number of pixels from the top (the second item, 47 in your case) to allow for the top notch and from the bottom (4th item, 34) to allow for the onscreen app switcher bar at the bottom of the screen. This is in portrait mode. This changes to be the 1st and 4th items (47,0,0,34) or 3rd and 4th (0,0,47,34) in landscape mode because the notch will be on the left or right but the app switcher remains at the bottom. If the phone is upside down and your app allows for this the you could have the notch at the bottom which will make it something like 0,0,0,81.
>
> Thanks and all the best
>
> Sean Cole
> Pi Digital
>
>
>> On 10 Feb 2022, at 22:13, Mark Smith <marksmithhfx at gmail.com> wrote:
>>
>> Sorry, it appears I attached the wrong link. Hopefully this one works better!!
>>
>> https://www.dropbox.com/s/2igqdbroxy5onf7/Test%20Layout%2013.livecode.zip?dl=0
>>
>>
>>
>>> On Feb 10, 2022, at 10:08 PM, Mark Smith <marksmithhfx at gmail.com> wrote:
>>>
>>> Hello everyone,
>>>
>>> Once again thanks to the many of you who provided advice and suggestions. They were really very helpful in coding up this full working example. In the interests of sharing I have posted an example into a dropbox account, and will upload a copy to the forums at some point. This example takes a “dummy” layout of my Organize app (nothing is being saved, most features are not included) and redraws the main screen to fit the target device using just iPhoneSafeAreaInsets() and "the effective working screenRect" and nothing else (no fullscreenmode for example). It works remarkably well. I have tested it on a physical SE, 6S, 11, 12 and 13 mini and it adapts to each screen as you would expect. It is remarkably satisfying to see it adapt to changes in the keyboard size (predictive, not predictive) on the fly. No special code was required to do this.
>>>
>>> You’ll need to compile the example for iPhone and use a developer profile to install it on an iPhone device. The simulator does not really provide a useful simulation primarily because it does not simulate the behaviour of the keyboard very well (however, if you just want to see how the layout adapts, it is perfectly fine for that). Its possible I have not developed the most efficient method of coding the layout. If you have any suggestions, I’d be most grateful to receive them.
>>>
>>> UI tips:
>>> 1. tapping once on white space below the dg entries dismisses the keyboard (so does the “down arrow” when it appears in the header bar).
>>> 2. tapping twice adds a new blank line (or inserts the cursor into an existing one) (so does the “+” sign in the header bar).
>>>
>>> The rest should be obvious, I hope. All of the layout is in the card script. All of the dg code is in the dg handler and behavior script.
>>> Finally, if you have any questions, please feel free to send them on.
>>>
>>> All the best,
>>> Mark
>>>
>>> https://www.dropbox.com/s/nmri0dy5j5qtc8c/test.livecode.zip?dl=0
>>>
>>>
>>>
>>>> On Dec 27, 2021, at 12:05 PM, Mark Smith <marksmithhfx at gmail.com> wrote:
>>>>
>>>> Thank you Sean and Jacque,
>>>>
>>>> I’ve not had a chance to work on a complete solution but thought I would make a test run to see what “the effective working screenrect” was returning and as the following indicates, it does in fact take into consideration the keyboard. I just coded up one line to run whenever the status of the keyboard changed and tried it both with and without the “predictive” option turned on. As you can see, it was very sensitive to this change…
>>>>
>>>> without predictive:
>>>>
>>>> 9:37:14 PM keyboardActivated 0,0,375,451
>>>> 9:37:15 PM keyboardDeactivated 0,0,375,667
>>>> 9:37:18 PM keyboardActivated 0,0,375,451
>>>> 9:37:19 PM keyboardDeactivated 0,0,375,667
>>>> 9:37:19 PM keyboardActivated 0,0,375,451
>>>> 9:37:23 PM keyboardDeactivated 0,0,375,667
>>>>
>>>>
>>>> with predictive:
>>>>
>>>> 9:56:54 PM keyboardActivated 0,0,375,407
>>>> 9:56:55 PM keyboardDeactivated 0,0,375,667
>>>> 9:56:55 PM keyboardActivated 0,0,375,407
>>>> 9:56:57 PM keyboardDeactivated 0,0,375,667
>>>>
>>>> In my particular case not all 4 value are immediately useful. For example, I have a fixed header and footer that need to be accommodated so the correct “useable” rect for me is:
>>>>
>>>> 0,69, 377, 618 (for no predictive)
>>>> 0,69,377,456 ( for predictive)
>>>>
>>>> but this can easily be accommodated since the header/footer values don’t change. The beauty is I now have a rect lower bound (ie. keyboard height) that actually reflects where the keyboard is.
>>>>
>>>> Brilliant!! Thank you both,
>>>>
>>>> Mark
>>>>
>>>> Sean, I tried iPhoneSafeAreaInsets() but it appears it returns a constant set of values regardless of keyboard position on my iPhone 12
>>>>
>>>> 11:51:22 AM keyboardActivated 0,47,0,34
>>>> 11:51:22 AM keyboardDeactivated 0,47,0,34
>>>> 11:51:26 AM keyboardActivated 0,47,0,34
>>>> 11:51:26 AM keyboardDeactivated 0,47,0,34
>>>>
>>>> And didn’t change when I added / subtracted “predictive”. So, just the available usable space at the top and bottom of the screen. I haven’t adjusted my app yet to fully take advantage of the larger screen on a 12 (it was developed on a 6S) but when I get to more response design this will be useful to know where the usable top and bottom are.
>>>>
>>>> Cheers!!
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>> On Dec 25, 2021, at 5:25 PM, Sean Cole via use-livecode <use-livecode at lists.runrev.com> wrote:
>>>>>
>>>>> Another addendum to this I just noticed is in the latest RC, LC9.6.6RC1,
>>>>> which has iphoneSafeAreaInsets for discerning the safe area from furniture
>>>>> like the notch and so on. I haven't tested this but that may also include
>>>>> things like the keyboard and predictive areas. I just thought it was worth
>>>>> a mention here.
>>>>>
>>>>> Regards
>>>>> Sean
>>>>>
>>>>> On Fri, 24 Dec 2021 at 20:44, J. Landman Gay via use-livecode <
>>>>> use-livecode at lists.runrev.com> wrote:
>>>>>
>>>>>> On 12/24/21 2:16 PM, Sean Cole via use-livecode wrote:
>>>>>>> Just adding to what Jacquie wrote, there is also the effective working
>>>>>>> screenrect.
>>>>>>
>>>>>> You're right, "effective" was added to account for the keyboard on mobile.
>>>>>> I'd start with that.
>>>>>>
>>>>>> --
>>>>>> 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
>>>>
>>>
>>
> _______________________________________________
> 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