Comments 26
и элементы вашего приложения будут выглядеть всегда одинаково и на iPhone 14 Pro Max, и на iPhone SE.
кажется, что цель изначально была неверной
Но что если ваше приложение должно работать на iPhone SE 1 поколения? Тогда с вероятностью в 100% где-то вёрстка поедет.
если в логике вёрстки были изъяны, то да. Но далеко не у всех что-то куда-то поедет с вероятностью 100%
тут скорее речь шла про то что в высоту экраны различаются и не все что должно отображаться сразу будет отображаться в силу этого фактора) Но спасибо за замечание)
Можно пример того, что непременно "должно отображаться сразу" при живом-то UIScrollView?
Допустим у тебя профиль с определенным размером аватарка информации профиля и тд. На разных девайсах отображение всей информации будет выглядеть по-разному. Например, на большом айфоне отобразится вся информация, а на маленьком устройстве только аватарка с датой рождения. Ну это так в качестве примера)
Что же здесь ненормального? Для того скроллинг и был изобретён, чтобы размер экрана мог быть меньше размера контента.
тем не менее нельзя отрицать, что экраны iPhone SE 1 гораздо меньше любого pro max. И гораздо удобнее видеть все что необходимо на экране сразу (чуть уменьшенное например), чем просто скролить. Тем более что UI из-за этого может выглядеть как текст в ватсап у наших бабушек или дедушек)
Тем более что UI из-за этого может выглядеть как текст в ватсап у наших бабушек или дедушек)
если речь об увеличенных шрифтах, то это неправда. Если специально не портить, то размеры элементов будут одинаковыми, и на большом экране поместится больше контента. А как раз-таки в статье, как я понял, предлагается скейлить элементы (уменьшать) для разных размеров экрана. Что я считаю провальной затеей в большинстве случаев.
Добрый вечер.. что значить "специально не портить, размеры будут одинаковыми". Мы об одном и том же говорим? Я пишу про UI.
У тебя есть аватарка 24х24, где бы ты ее не открыл, на каком угодно девайсе, она всегда будет у тебя 24х24, если нет определенных условий, например в расширении как я описал выше.
А если по тз она должна быть 400х400? у тебя аватарка уйдет за пределы экрана)
Тогда надо или выключить голову и делать "как в ТЗ", или в тз на самом деле нет требования именно о размерах 400х400.
Вообще такие расчёты в зависимости от Размера Экрана Устройства заведомо неправильные. Как минимум потому, что почему-то подразумевается исключительно полноэкранный режим, и как правило ещё и заведомо портретный. И то, и другое вдруг оказывается неправдой, а половина проекта уже подсела на эти "константы", которые вдруг константами быть перестали.
Поэтому наиболее жизнеспособный вариант это всё-же отталкиваться от размеров своей superview. Тогда в качестве прямой замены этих умножений и делений можно хотя бы использовать NSLayoutDimension.constraint(equalTo:multiplier:):
view.widthAnchor.constraint(equalTo: superview.widthAnchor, multiplier: 0.2)
чтобы заставить view занимать 20% ширины.
И гораздо удобнее видеть все что необходимо на экране сразу (чуть уменьшенное например)
на чём основывается убеждение, что "чуть уменьшенное" это "гораздо удобнее", чем "нормального размера", такого же как во всех других приложениях?
extension UIDevice {
var current: ScreenType {
switch UIScreen.main.nativeBounds.height {
расширяется код инстанса UIDevice, а данные читаются из UIScreen.main. Может тогда надо было в UIScreen и добавлять код определения типа экрана?
При смене ориентации экрана или подключении устройства ко внешнему монитору вся кастомная логика, завязанная на ‘UIDevice’ и ‘UIScreen.main’, сразу упорется
Но ведь давно уже придуманы size classes, разве нет? https://developer.apple.com/library/archive/documentation/UserExperience/Conceptual/AutolayoutPG/Size-ClassSpecificLayout.html
Мои 3 способа для выравнивания UI на разных девайсах в Swift