iPhoneSafeAreaInsets

[Klaus]

I finally found a way to resize my stack when already as a runtime ON THE DEVICE!
See some screenshots of my proportionally (to current device) resized stack here:
https://www.dropbox.com/sh/r34raykbqe2i ... YVzka?dl=0

FYI, the screen sizes of these three devices:
iPhone 12 Pro Max -> 428*926 px
iPhone 12 mini -> 375*812 px
iPad Pro 12.9 inch -> 1024*1366 px
My Stack in IDE -> 480*867 (size of iPhone 6 Plus)

I will post a little demo stack next week here and in the Android forum if someone is interested.

[SparkOut]

I can't think of anyone who wouldn't be interested in what Klausimausi has to say about anything.

[Klaus]

LOL
Thank you, Sir!

[marksmithhfx]

I finally found a way to resize my stack when already as a runtime ON THE DEVICE!

I will post a little demo stack next week here and in the Android forum if someone is interested.

Thanks Klaus. That looks very promising. I look forward to seeing your demo stack. We are always in need of an easier way to do this.

Mark

[SWEdeAndy]

I finally found a way to resize my stack when already as a runtime ON THE DEVICE!

Oh dear - well, learning while coding means constantly reinventing the wheel, an that's a curse and a blessing for us all, but perhaps I should be sorry I didn't chime in on this thread earlier...

I've been using a method for an app I have in App Store where I design the app for a 4:3 aspect ratio, which was the common one for all iPads until iPad Air 4th gen (2020). Then:

Code: Select all

on preOpenStack
   if the environment is "mobile" then      
      if machine() begins with "iPad" then ## Scale up instead of rearranging
         set the fullscreenmode of this stack to "letterbox"
      else
         set the rect of this stack to the screenRect
      end if
   end if
end preOpenStack

Since I didn't want/need the app layout to take advantage of the iPad's larger screen area, it was convenient to just scale it up if the device is an iPad, and change the stack rect and rearrange the layout only if it is an iPhone (by cascading resizeControl handler triggers in groups).

From iPad Air 4th gen on, there are several iPad aspect ratios (4:3, 23:16, 10:7, 6.1:4), so this strategy is unfortunately obsolete, and I need to rework it.

In any case, before the iPhoneSafeAreaInsets() function was introduced, I made and shared an LC library that takes the iphoneDeviceModel() function (LC9.6.3) and looks up the safe area margins AND the device name/model (if needed) from a source that I've created.

Although this too is perhaps half obsolete, now that iPhoneSafeAreaInsets() exists, it may still be a useful example of responsive design. I updated it today (29 Oct 2022) with the latest Apple devices.

You can freely access the library and demo stack here:
https://github.com/wheninspace/WISmobDeviceLib

The best resource that I've found on the net for getting useful insights about Apple device parameters is this one:
https://www.screensizes.app/ (click Charts and then Compare models to get full lists)

And this one has a more comprehensive list of screen sizes, if that is of interest:
https://www.ios-resolution.com/

These kind of lists are already very long for Apple devices - I suppose there exists similar projects for mapping Android devices, but such lists are likely to be 10 or 100 times as long, so developing for mobile is always going to be a nightmare...

[Klaus]

I created a new thread for my demo stack:
https://forums.livecode.com/viewtopic.php?f=49&t=37425

[FourthWorld]

These kind of lists are already very long for Apple devices - I suppose there exists similar projects for mapping Android devices, but such lists are likely to be 10 or 100 times as long, so developing for mobile is always going to be a nightmare...

Only if "nightmare" means "how most folks in the software and web dev worlds have been making UIs for many years".

Look at the apps on your phone. Look at web sites. Most of them use the same layout logic, adjusting controls based on screen width.

The easiest way to see how they respond to differences in screen ratio doesn't even require a second device. Just tilt your phone 90 degrees. See what they do. Do that.

Responding to the resizeStack message to put things where we want them is sometimes tedious, but rarely difficult. And using groups well can cut a lot of that tedium.

Resizable windows have been around since Xerox Star. The ability to script layouts to respond to changes in window size in an xTalk has been around since at least 1989, with SuperCard's resizeWindow message. The LC engine was born in '92 as MetaCard, and I believe even very early versions had the resizeStack message.

What sorts of projects have xTalkers been making an these years that never needed to support resizable windows?

[SWEdeAndy]

I agree with all this, Richard, and I make extensive use of the 'cascading resizeControl handler triggers in groups' method that I've learnt from you and others in the LC community. I will also explore the new responsive design library that came recently, as that might facilitate things even more, at least in some cases.

My nightmare comment was maybe not well explained, sorry about that. What I was actually referring to is the nightmare that started with the introduction of "notch" devices, and those without a physical button at the bottom. Because since then, it is no longer enough to use the screenRect for adapting your layout. You have to cater for safe area insets if you want your layout to look good and function well.

LC has now made this easy for us with the iPhoneSafeAreaInsets function, so my lookup library is mostly obsolete, which is good. But we have no similar function for Android devices, and building a lookup lib for that would entail managing vast lists of Android device varieties. So, making perfect adaptive design for Android seems a bit of a nightmare to me. I hope someone soon proves me wrong in saying it will always be so, though...

[FourthWorld]

What I was actually referring to is the nightmare that started with the introduction of "notch" devices, and those without a physical button at the bottom. Because since then, it is no longer enough to use the screenRect for adapting your layout. You have to cater for safe area insets if you want your layout to look good and function well.

The best thing for Apple about the notch is that it's one more thing that makes life harder for cross-platform developers.

But hey, at least they're finally adopting USB-C.

[jacque]

Does "the working screenrect" help?

[SWEdeAndy]

Does "the working screenrect" help?

If only it were that simple - but unless something has changed since last year when I battled with this issue, I'm afraid it does not, and nor does the effective screenRect. Perhaps LC could merge the iPhoneSafeAreaInsets function into the working screenRect one to make it useful at least on iPhones.

If it could then also be made to cater for Android notch devices then at least this particular nightmare would go away...

[stam]

The best thing for Apple about the notch is that it's one more thing that makes life harder for cross-platform developers.

I’m sure there are Android phones with a notch as well? Or am I mistaken?

[FourthWorld]

The best thing for Apple about the notch is that it's one more thing that makes life harder for cross-platform developers.

I’m sure there are Android phones with a notch as well? Or am I mistaken?

At this point that's probably true. The Android world offers such a vast selection of models it's hard to say these days.

[bwmilby]

One big difference that I notice is that on iOS you can draw behind the furniture (outside safe area, beside notch, under status bar) but those areas are outside the drawable rect on Android. I’ve not pulled up any Android sims with a notch though, so not as sure about them.

[jacque]

I’m sure there are Android phones with a notch as well? Or am I mistaken?

There were a few back when iPhones first got the notch and Android manufacturers copied it. It was almost universally hated so it disappeared fairly quickly.