I'm tuning my UI App, but I got an issue that I can't solve.
As I can see Compact height affects all iPhones under 4.7 inches, but my UI is fine except for the iPhone 4S (3.5 inches).
I don't want to modify the layout for all iPhones under 4.7 inches, just the iPhone 4S, at the same time I don't want to left out this device.
There's any workaround so I can set the amendments but just and only for the 3.5 inches portrait? or should I say goodbye to 100 millions devices out there?
I know it's a tough question and almost an opinion poll, but technically speaking I would like to find my best way out here.
@all I can't make things smaller, because I'm dealing with pickerviews which happen to have only three valid heights for UIPickerView (162.0, 180.0 and 216.0). Sizes and constraints apart.
iPhone Sizes: http://www.idev101.com/code/User_Interface/sizes.html , 4S is unique.
So although my approach it's a little bit ugly get the things done, nearly on my point.
So I know it's far from Goodville, don't hit me down, just for sharing:
There is no size class for iPhone 3.5 inch.
So I've made a class category for NSLayoutConstraint to edit it in Interface Builder which is very easy to use:
–
An approach that just worked for me was to use the same constraints for all compact size classes but to use a combination of a greater than or equal to constraint and priorities to modify how the views were positioned on the iPhone 4's smaller screen.
I've got a constraint between the top of a numeric keypad view and its superview that is set to be greater than or equal to 160 (with a priority of 1000) and a constraint between the bottom of the keypad view and the bottom of the superview that is set to a constant of 30 (but with a lower priority of 750).
This means that on the iPhone 4 where there's not enough room for 160+ points above the keypad and 30 points below then it's the space below that goes.
Whilst this approach may not work in all cases, I'd encourage you to think about whether there's a set of priorities that will allow your views to adjust in the way you want on the smaller screen.
Swift 5.0 code for Pavel Alexeev's solution., accounting for some syntax updates and also screen width because I've found that if the device is being held in the landscape orientation when the app is launched, the screen height is not the actual portrait height, but the current landscape height. So, I check that the width is accounted for, too. If the height is less than 660 AND the width is less than 375, we have a portrait SE or 5s.
Swift 3 version of Pavel Alexeev's solution. In Swift you can't use stored properties in extensions, so we apply it directly to the
constant
property.