Skip to content

Commit cc63d3d

Browse files
committed
Implement workaround for potential visual glitch
Using CGRectGetMaxY resolves a layout issue where otherwise the inset ends below the navbar (e.g. Phone 14 Pro iOS18), but at the same time it causes an issue with the inset not taking into account the status bar (e.g. iPod Touch iOS15.5). This seems to be caused by calling this method from viewDidLoad instead of willLayoutSubviews. This workaround avoids rework of DetailVC's delicate layout.
1 parent 22ac6b8 commit cc63d3d

File tree

1 file changed

+8
-1
lines changed

1 file changed

+8
-1
lines changed

XBMC Remote/Utilities.m

Lines changed: 8 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -1013,7 +1013,14 @@ + (CGFloat)getTopPadding {
10131013
}
10141014

10151015
+ (CGFloat)getTopPaddingWithNavBar:(UINavigationController*)navCtrl {
1016-
CGFloat topPadding = UIApplication.sharedApplication.statusBarFrame.size.height + navCtrl.navigationBar.frame.size.height;
1016+
// Workaround: Using CGRectGetMaxY resolves a layout issue where otherwise the inset ends below the navbar (e.g.
1017+
// iPhone 14 Pro iOS18), but at the same time it causes an issue with the inset not taking into account the status
1018+
// bar (e.g. iPod Touch iOS15.5). This seems to be caused by calling this method from viewDidLoad instead
1019+
// of willLayoutSubviews. This workaround avoids rework of DetailVC's delicate layout.
1020+
CGFloat topPadding = CGRectGetMaxY(navCtrl.navigationBar.frame);
1021+
if (topPadding <= navCtrl.navigationBar.frame.size.height) {
1022+
topPadding = UIApplication.sharedApplication.statusBarFrame.size.height + navCtrl.navigationBar.frame.size.height;
1023+
}
10171024
return topPadding;
10181025
}
10191026

0 commit comments

Comments
 (0)