iPhoneSafeAreaInsets

[marksmithhfx]

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 iPhoneSafeAreaInsets() and "the effective working screenRect" (no fullscreenmode). 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 to different screen sizes, 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.
Many thanks again for the helpful comments on the list for helping me sort this out. Questions, comments always welcome.

Mark

[marksmithhfx]

I was going to extend my previous example beyond just "portrait" mode but some of the results I am getting for landscape and upside-down are looking a little odd to me, so before I post a bug report I am hoping someone can verify that these results are in fact buggy.

Testing was done both on the sim and real iPhones for both the 6S and the 12.

This is a very simple stack. There is a single card script that sets up the allowable orientations (all of them).

There is a button on the card which, when pressed, reports the screen orientation and the iphoneSafeAreaInsets. In the documentation, insets are defined as "the space between the devices screen edges (left, top, right, bottom) and where the safe area begins". In other words, the offset you need to take into consideration in order to avoid putting controls on top of the screens "furniture" or system information.

On the 6S the iphoneSafeAreaInsets() function works perfectly for all screen orientations, and the screen, when rotated to the upside-down position, displays the text right-side up on the inverted screen. The insets reported are portrait (0,20,0,0), same for upside-down and for landscape (0,0,0,0) because there is no system information (time, battery, wifi/cell reception) displayed in these orientation. This works perfectly on the sim and on the real device.

On the 12 there are a few anomalies (perhaps not bugs, but oddities). The reported insets are portrait (0,47,0,34) which seems perfectly reasonable. There is the large cutout at the top of the screen for the camera, speaker and face ID tech and at the bottom, the control for swiping up. But for landscape they are (47, 0, 47, 21) for both left and right. This seems a little odd because in landscape mode there is nothing on either the left or right side depending on how you rotate. So it would seem that (47,0,0,21 -left) or (0,0,47,21-right) would be more appropriate? Also on both the sim and the actual device the upside-down orientation is not supported (perhaps by design).

The final issue relates to the orientation reported by the LC mobileDeviceOrientation() function. In the sim, when you set the device to landscape left, mobileDeviceOrientation() reports right and vice versa. This happens on both real devices and in the sim. Of course, on the real hardware you are not "setting" the hardware but if you turn it in the same direction that the sim does (ie. turning the large notch at the top of the screen to the left for landscape left, and right for landscape right) you get the "opposite" direction reported.

First, I'm not sure if I am misunderstanding the device orientation function or if it really is backwards, and second, I'm not sure why the device inset for landscape left and right is not 0 for the side opposite the large screen cutout.

Thanks for any feedback before I send this to the mothership!
Mark

[seaniepie]

Hi Mark
For both of these functions, LiveCode makes a call to the iOS frameworks. The orientation and dimensions are each returned from these frameworks. So, if these were a bug it would be with iOS and not LiveCode.

However, these are not a bug but simply the way Apple has determined to provide what it calls ‘safe’ areas. The reason they give for having 47 left and right in landsacpe are for symmetry and to make it easier for developers to add or subtract from screen left and right to maintain symmetry.

If, for example, you are laying out several buttons across the lower area of the screen in landscape, you would ensure that they begin 47 from the left, end 47 from the right and have their bottoms above 21 from the bottom of the screen. This makes it both aesthetically pleasing and not in the way of other system controls. Look at any of Apples own iOS apps and they all follow these design aesthetics.

All the best
Sean

[marksmithhfx]

However, these are not a bug but simply the way Apple has determined to provide what it calls ‘safe’ areas. The reason they give for having 47 left and right in landsacpe are for symmetry and to make it easier for developers to add or subtract from screen left and right to maintain symmetry.

Thanks Sean, I was thinking much the same… “Maybe it is for aesthetic reasons?" But I wasn't sure. What do you make of selecting the "landscape left" option in sim and having the mobileDeviceOrientation() return "right"? I guess not a big issue since it's simply information (not functionality) and if you figure it out you can just interpret as you see fit. Anyway, I won't worry about it further as I am primarily interested in portrait and, big win yesterday, I had my first “adaptive” screen appear laid out on the basis of iphoneSafeAreaInsets(). Very pleased with that. I've attached an image. The layout was originally designed on a 6S but here it is being adapted to fit the 12. Pretty slick. I have an SE, 11 and 13 to test on tomorrow. No more "fullscreen mode" and now with full use of the screen (fullscreen mode, at its best, does not reach into the corners). I've attached a screenshot showing the new layout. Also, a shout out to Andreas Bergendahl for inspiration and advice on doing this.

Thanks again for the many clarifications on iPhoneSafeAreaInsets()
Mark

[Klaus]

Hi Mark,

just discovered this older thread.

I downloaded our "Test safeAreaInsets.livecode.zip", works great, however I do not
see the part where the STACK is resized. Only the background graphic.
What am I overlooking?

Just beginning to make first steps in "mobile" development.


Best

Klaus

[marksmithhfx]

I downloaded our "Test safeAreaInsets.livecode.zip", works great, however I do not
see the part where the STACK is resized. Only the background graphic.
What am I overlooking?

Hi Klaus,

When iOS launches your app it automatically sends a resize message so you can layout your app to fit the current device correctly (these coordinates are provided in safeAreaInsets(). All iOs apps launch full screen and are not resizable after that. An added benefit of this approach is that if Apple releases new devices with different screen sizes your code will automatically adapt to the new size... well, theoretically anyway. If you go from an iPhone to an iPad you might need to make additional considerations for the extra screen real estate.

Hope this helps,
Mark

[Klaus]

Hi Mark,

thank you!

But what I really don't get is that youi only set the size of your background graphic but not the stacks size?
I tried the same here, no success...


Best

Klaus

[marksmithhfx]

see the part where the STACK is resized. Only the background graphic.

So the bit about the background graphic. Unfortunately safeAreaInsets() (by definition) does not stretch to the 4 corners of the screen but leaves some unused spaces around some edges. In order to fill this in I install a background graphic (layer 1) and extend it outwards just beyond each of the edges. This masks the difference between safe areas (where your controls go) and the actual screen boundaries. I hope this makes sense. Anyway, here's some code you can try (if you have a background graphic installed) that will demonstrate the difference...

Code: Select all

on resizeStack
   set the backgroundcolor of graphic "background" to "#F4F4F4"
   set the rect of graphic "Background" to item 1 of the screenrect -2, item 2 of the screenrect, item 3 of the screenrect +2, item 4 of the screenrect
end resizeStack

You don't have to set the stack size since iOS automatically does that and then sends your app a resizeStack message so you can adjust according to the size of the actual device you are now running on. This avoids the whole issue of having to create separate versions for each size iPhone or iPad.

[Klaus]

Hi Mark,

sorry, still don't get it, see screenshots.
I did what you did, added a background grc and used used the same "resizestack" handler.

But maybe I misunderstood this or was exspecting way more that this would deliver.
I tend to think the latter...

Thank you very much for your patience!


Best

Klaus

[marksmithhfx]

Hi Klaus,

It looks like your background graphic is being positioned properly to fill the screen. Now try adding this code to your resizeStack handler... and test on the same size iPhone and then test on a really big iPhone like an iPhone 12 Pro Max. Then try changing the background graphic color to the same color as your header and footer. Magic happens

Code: Select all

   put safeAreaRect() into lSafeAreaRect -- the rect where it is safe to position all of the controls
    
   -- position the header bar
   set the width of widget "Header Bar" to item 3 of lSafeAreaRect -- right
   set the top of widget "Header Bar" to item 2 of lSafeAreaRect
   set the left of widget "Header Bar" to 0
   
    -- position the nav bar group  
   set the width of widget "Navigation Bar" to item 3 of lSafeAreaRect -- right
   set the bottom of widget "Navigation Bar"  to item 4 of lSafeAreaRect
   set the left of widget "Navigation Bar" to 0
   

[Klaus]

Hi Mark,

thank you for your patience!

I have been off from my Mac for a couple of hours and it struck me (sound of slap on the forehead )!
A complete misunderstanding on my side, your example stack made me think that also the stack would have
been resízed, but that is not the case. Took a while...

OK, all clear, case closed, thanks a bunch!


Best

Klaus

[marksmithhfx]

OK, all clear, case closed, thanks a bunch!

Hi Klaus, if you decide to pursue it let me know as I'd be happy to help out. There are 1 or 2 more issues we never advanced to, so a few wrinkles before it sorts itself out. But I do understand, the manual calculation of where all of the screen elements go can be frustrating and tedious at times. But overall I do think it's worth the investment as you end up with a very adaptive design that just adjusts itself to whatever screen size you throw at it. That being said, one possible option to investigate is the Summer Mega Bundle (if those widgets are still available). I believe there is a tool in there specifically designed to help with responsive design. You can read more about it here https://livecode.com/i-built-a-responsi ... libraries/ and perhaps if it meets your needs you might wrangle a copy from the mother ship (though it might cost a few farthing). BTW, reading through the description it was not clear to me if it was just for web apps, or possibly for standalones as well. So much to keep up with .

Mark

[Klaus]

Hi Mark,

thank you for you kind offer, but I know all this and use it myself in my projects.

However the content of my current project cannot easily be scaled like the header and navibar widgets,
so I was hoping to find another way to scale the complete stack, and misunderstood your example.

Have a nice weekend!


Best

Klaus

[jacque]

BTW, LC will fill the areas outside the stack with the background color of the stack or card, so if you set the backcolor of the stack, you won't need the graphic.

[marksmithhfx]

BTW, LC will fill the areas outside the stack with the background color of the stack or card, so if you set the backcolor of the stack, you won't need the graphic.

Great tip, thanks Jacque.