[TIMOB-26814] iOS: safeAreaPadding is all zeros if "extendsSafeArea" is false
| GitHub Issue | n/a |
|---|---|
| Type | Bug |
| Priority | Medium |
| Status | Open |
| Resolution | Unresolved |
| Affected Version/s | Release 8.0.0 |
| Fix Version/s | n/a |
| Components | iOS |
| Labels | n/a |
| Reporter | Hans Knöchel |
| Assignee | Unknown |
| Created | 2019-02-09T08:23:14.000+0000 |
| Updated | 2019-02-19T20:15:43.000+0000 |
Description
We are currently trying to migrate our manually set safe area values to the SDK 8+ "safeAreaPadding" property. Unfortunately, it does not work if "extendSafeArea" is
false.
It should also work for normal views like a window inside a tabgroup or navigation-window, since the bottom-spacing is still of high interest to, e.g. for calculating the keyboard bottom height.
Regarding "safeAreaPadding", this is not a bug. This is the correct behavior. Padding is only applicable if "extendSafeArea" is set
true. If "extendSafeArea" is setfalse, then the window's root view will auto-size itself within the safe-area. This means no padding is needed. The "safeAreaPadding" returned is relative to the window's root view which is why it returns all zeros in this case. The idea here is a view can blindly apply safe-area padding without having to worry about the state of the "extendSafeArea" property. Now, if you set "extendSafeArea"falseand you see views being overlapped by insets, then that sounds like a layout bug. *Is this the issue you are seeing?* Regarding the virtual keyboard, I'm pretty sure iOS does not provide its height as an inset (there is a different native API for this). And this impossible to do on Android since there is no reliable way to fetch the virtual keyboard height on that platform (it's better to use the "adjustSize" or "adjustPan" window settings instead and let the Android OS handle it).For the virtual keyboard, you can use
Ti.Appevent "keyboardframechanged"... https://docs.appcelerator.com/platform/latest/#!/api/Titanium.App-event-keyboardframechanged[~hknoechel], I just noticed that setting "extendSafeArea" to
falseon iOS 10 and older versions the top status bar will wrongly overlap the window's content. On iOS 11 and higher, the top status bar does not overlap the window's content. This is definitely a bug, although it's probably not what you're running into.