Pull to refresh

Comments 18

Как в тему. Как раз пишу подобное, будет пример, куда глянуть.
if (self.frame.size.width == 768)

Сурово, а если ширина контейнера будет не на весь экран? Лучше все таки использовать ориентацию экрана, а не ширину для проверки :)
Тут всё зависит от конкретной ситуации. В приведённом примере контейнер заполняет всю экранную область — никаких противопоказаний в использовании абсолютной величины при сравнении нет. В этом нет ничего плохого.
Магические константы это плохо. Особенно плохо(при наличии оного) вместо первичного источника данных — ориентации экрана, упираться на следствие — ширину или высоту.
Я не спорю, что можно использовать макрос UIInterfaceOrientationIsPortrait.

Но мне не очень понятно, чем именно особенно плох мой пример?

Это не универсальный код, а специально для iPad. 768 — это не какая-то магическая константа, а вполне уникальное число для конкретного примера. Эта программа для iPad, который имеет одно заведомо известное разрешение.
Ну вот в том и проблема, что не универсальный. :) Сегодня вы пишите специально для айпад, а завтра (внезапно!) выходит айпад %random%G с другим разрешением и тысячи программеров делавших софт по такому вот примеру должны будут вносить правки в свой код.

p.s.
Спасибо за поправку. ;)
Добавил в топик вариант с макросом.
Ландшафтную ориентацию я бы лучше назвал «альбомной» иначе с самого начала не очень понятно, о чём речь.
я примерно так же делаю, но через центр и с доп вычислениями

чтоб не проверять по ширине в кокой мы ориентации, думаю лучше использовать UIDeviceOrientationIsLandscape(orientation)
сколько раз убеждаюсь, что нужно больше читать доку по framworks! Обратил внимание на viewWithTag, такая мелочь, а полезно, как-то раньше не встречал, хоть и активно параметр tag использую! Спасибо!
тогда уж лучше делать сравнение self.frame.size.height > self.frame.size.width будет универсально
Приятно встретить человека, который не пользуется Interface Builder'ом :)
И это зря. Саппортить проекты построенные не интерфейс билдером — гораздо сложнее.
Особенно если понадобилось поменять, допустим, цвет шрифта или еще какую мелочь, а создатель проекта не удосужился сделать дефайну (или еще чего подобного) для этого.
В этом случае интерфес билдер ускорит подобный фикс в разы :)
Да и в коде меньше хлама в итоге. Остаются только вещи которые действительно связаны с програмированием (локализиция например).
Кроме того работать с дизайнером гораздо проще получается в IB чем постоянно перекомпиливая проект…

З.Ы. Скорость загрузки данных из xib конешне ниже чем кодом, но в большинстве случаев это абсолютно не критично.
Ну, дефайны у меня все-таки есть. Даже сделал для себя небольшой фреймворк, для удобного расположения контролов программным способом. Код получается куда прозрачнее. С поддержкой нет никаких проблем, даже при переходе на айпад (хотя под него все равно нужно переделывать весь интерфейс для новых гайдлайнов). Да и контролы, которые я пишу, в IB не реализовать, много различного рода custom view, лейеров и прочего.
Крайности — это всегда крайности :)
ИМХО для стандартных случаев — лучше использовать стандартне подходы.
Для какихто чуть более сложных случаев — свои компоненты (IB тут действительно почти ничем не поможет, хотя опять же расстановку элементов можно сделать там и не перегружать этой инфой код).
В тяжелых ситуациях (например куча кнопок, анимаций и картинок на фоне сложных расчетов) — наверно стоит подумать про OpenGL (тут уж IB почти не при делах).
Хороший пример. Только есть один бо-о-ольшой недостаток: у Вас кнопки создаются тупо вызовом одних и тех же методов, а это не есть хорошо. Если Вы будете использовать 15 кнопок — то на что будет похож код?
Only those users with full accounts are able to leave comments. Log in, please.