Comments 18
спасибо
очень доступно
очень доступно
Как в тему. Как раз пишу подобное, будет пример, куда глянуть.
if (self.frame.size.width == 768)
Сурово, а если ширина контейнера будет не на весь экран? Лучше все таки использовать ориентацию экрана, а не ширину для проверки :)
Сурово, а если ширина контейнера будет не на весь экран? Лучше все таки использовать ориентацию экрана, а не ширину для проверки :)
Тут всё зависит от конкретной ситуации. В приведённом примере контейнер заполняет всю экранную область — никаких противопоказаний в использовании абсолютной величины при сравнении нет. В этом нет ничего плохого.
Магические константы это плохо. Особенно плохо(при наличии оного) вместо первичного источника данных — ориентации экрана, упираться на следствие — ширину или высоту.
Я не спорю, что можно использовать макрос UIInterfaceOrientationIsPortrait.
Но мне не очень понятно, чем именно особенно плох мой пример?
Это не универсальный код, а специально для iPad. 768 — это не какая-то магическая константа, а вполне уникальное число для конкретного примера. Эта программа для iPad, который имеет одно заведомо известное разрешение.
Но мне не очень понятно, чем именно особенно плох мой пример?
Это не универсальный код, а специально для iPad. 768 — это не какая-то магическая константа, а вполне уникальное число для конкретного примера. Эта программа для iPad, который имеет одно заведомо известное разрешение.
Добавил в топик вариант с макросом.
Ландшафтную ориентацию я бы лучше назвал «альбомной» иначе с самого начала не очень понятно, о чём речь.
я примерно так же делаю, но через центр и с доп вычислениями
чтоб не проверять по ширине в кокой мы ориентации, думаю лучше использовать UIDeviceOrientationIsLandscape(orientation)
чтоб не проверять по ширине в кокой мы ориентации, думаю лучше использовать UIDeviceOrientationIsLandscape(orientation)
тогда уж лучше делать сравнение self.frame.size.height > self.frame.size.width будет универсально
Приятно встретить человека, который не пользуется Interface Builder'ом :)
И это зря. Саппортить проекты построенные не интерфейс билдером — гораздо сложнее.
Особенно если понадобилось поменять, допустим, цвет шрифта или еще какую мелочь, а создатель проекта не удосужился сделать дефайну (или еще чего подобного) для этого.
В этом случае интерфес билдер ускорит подобный фикс в разы :)
Да и в коде меньше хлама в итоге. Остаются только вещи которые действительно связаны с програмированием (локализиция например).
Кроме того работать с дизайнером гораздо проще получается в IB чем постоянно перекомпиливая проект…
З.Ы. Скорость загрузки данных из xib конешне ниже чем кодом, но в большинстве случаев это абсолютно не критично.
Особенно если понадобилось поменять, допустим, цвет шрифта или еще какую мелочь, а создатель проекта не удосужился сделать дефайну (или еще чего подобного) для этого.
В этом случае интерфес билдер ускорит подобный фикс в разы :)
Да и в коде меньше хлама в итоге. Остаются только вещи которые действительно связаны с програмированием (локализиция например).
Кроме того работать с дизайнером гораздо проще получается в IB чем постоянно перекомпиливая проект…
З.Ы. Скорость загрузки данных из xib конешне ниже чем кодом, но в большинстве случаев это абсолютно не критично.
Ну, дефайны у меня все-таки есть. Даже сделал для себя небольшой фреймворк, для удобного расположения контролов программным способом. Код получается куда прозрачнее. С поддержкой нет никаких проблем, даже при переходе на айпад (хотя под него все равно нужно переделывать весь интерфейс для новых гайдлайнов). Да и контролы, которые я пишу, в IB не реализовать, много различного рода custom view, лейеров и прочего.
Крайности — это всегда крайности :)
ИМХО для стандартных случаев — лучше использовать стандартне подходы.
Для какихто чуть более сложных случаев — свои компоненты (IB тут действительно почти ничем не поможет, хотя опять же расстановку элементов можно сделать там и не перегружать этой инфой код).
В тяжелых ситуациях (например куча кнопок, анимаций и картинок на фоне сложных расчетов) — наверно стоит подумать про OpenGL (тут уж IB почти не при делах).
ИМХО для стандартных случаев — лучше использовать стандартне подходы.
Для какихто чуть более сложных случаев — свои компоненты (IB тут действительно почти ничем не поможет, хотя опять же расстановку элементов можно сделать там и не перегружать этой инфой код).
В тяжелых ситуациях (например куча кнопок, анимаций и картинок на фоне сложных расчетов) — наверно стоит подумать про OpenGL (тут уж IB почти не при делах).
Хороший пример. Только есть один бо-о-ольшой недостаток: у Вас кнопки создаются тупо вызовом одних и тех же методов, а это не есть хорошо. Если Вы будете использовать 15 кнопок — то на что будет похож код?
Sign up to leave a comment.
Авторотация сложных интерфейсов в программах для iPad