0,0
рейтинг
9 сентября 2013 в 11:53

Разработка → UIAppearance. Управление внешним видом iOS-приложений перевод

Стиль или Суть
Сообщение или Носитель
Риторика или Диалектика

Красота — это нечто поверхностное или же идущее из глубинных истин?
Что значит «хороший дизайн»?
Эстетические суждения относительны или абсолютны?

Это важные вопросы, которые обсуждались философами, художниками и поэтами на протяжении тысячелетий.

И пока мы продолжаем наши поиски красоты и понимания мира, рынок мобильных приложений в данной области однозначно утверждает:

Пользователи платят за красивые приложения.

При покупке iPhone, пользователь покупает также философию Apple: вещи должны не только хорошо работать, но и хорошо выглядеть. То же относится к разработке на iOS — некрасивый интерфейс пользователя сказывается и на программном коде.

Исторически даже для незначительного изменения внешнего вида приложения в iOS требовался набор хаков, сопряженных с опасностью отклонения приложения в AppStore. К счастью, начиная с iOS 5 у разработчиков есть новый инструмент: UIAppearance.

UIAppearance позволяет единообразно управлять стилем компонентов во всем приложении.

Для реализации этого с сохранением существующей структуры UIKit специалисты Apple реализовали достаточно интересное решение: UIAppearance — это протокол, предоставляющий прокси-объект, который используется для конфигурирования объектов конкретного класса. Почему именно прокси, а не свойство или метод самого UIView? Потому что существуют объекты, не входящие в иерархию UIView, такие как UIBarButtonItem, со своим собственным представлением. Внешний вид может быть изменен у всех компонентов определенного типа или только у привязанных к специфической иерархии:

  • +appearance возвращает прокси-объект для данного класса элементов.
  • +appearanceWhenContainedIn:(Class )ContainerClass,...: возвращает прокси-объект для объектов, находящихся в определенном контейнере.
  • .

    Дух перфекционизма жив и в iOS. Сообщество постоянно развивает систему в сфере пользовательского взаимодействия. Это делает разработку под iOS более сложной, но и гораздо более приятной.

    Не соглашайтесь на полумеры.
    Делайте свои приложения прекрасными от внешнего вида до реализации.
Перевод: Mattt Thompson
Николай Семченков @nsemchenkov
карма
20,0
рейтинг 0,0
Реклама помогает поддерживать и развивать наши сервисы

Подробнее
Спецпроект

Самое читаемое Разработка

Комментарии (12)

  • 0
    Спасибо за NUI и UISS :)
  • 0
    Может быть мой вопрос слишком профанский, но почему бы не использовать для определения списка доступных свойств приведение типа указателя к указателю на объект своего класса?
    • 0
      Если я вас правильно понял, после приведения типов компилятор будет выдавать ровно тот список свойств, к типу которого вы привели. Т.е.
      - (void) methodWithId:(id)theId
      {
        UIButton *button = (UIButton *)theId;
        [button setText:@"Text" forControlState:UIStateNormal];
      }
      

      Скомпилится без ошибок, в реальности же приведет к крашу в случае, если передастся не UIButton, а UILabel (unrecognized selector).

      Но, конечно же, можно сделать намного проще — все свойства являются также и селекторами, другими словами никто вам не запрещает написать так:
      if([theId respondsToSelector:@selector(setText:forState:)]) {
      }
      
      • 0
        Возникает резонный вопрос: зачем указатель на UILabel приводить к (UIButton*)? :)
        • 0
          Вам приходит id, вы не знаете на момент компиляции что туда придет.
          • 0
            Видимо, у меня просто не было таких ситуаций, так как я уже во время написания кода знаю что и куда мне придет. Хотя бы только потому что об этом можно спросить у Runtime.
            • 0
              ну да, isKindOfClass:. Но все же весьма и весьма нередки ситуации в больших проектах, когда это неочевидно. особенно если пишете что-то универсальное, какой-нибудь хитрый контрол.
              • 0
                В больших проектах, если не проверять класс контрола, какой-нибудь другой программист обязательно передаст вам что-нибудь такое, после чего вы будете отлаживать приложение в течение пары недель.
                • 0
                  Каких нахрен пары недель, такие краши лечатся за 10 минут — неприятно, но не самое худшее. Хуже, если программист злоупотребляет блоками, используя их там где можно использовать методы — тогда стек не размотать.
  • 0
    Надеюсь Apple будет добавлять поддержку большего числа методов. Только что решил два кейса через UIAppearance для UINavigationBar и задумался о кастомном UIToolBar, потому что выглядит как костыль:

    кейс 1
    заменить кнопку Back на маленькую картинку:

    [[UIBarButtonItem appearance] setBackButtonBackgroundImage:[[UIImage imageNamed:@"back_nav_button"] resizableImageWithCapInsets:UIEdgeInsetsMake(0.f, 21.f, 0.f, 5.f)]
                                                          forState:UIControlStateNormal
                                                        barMetrics:UIBarMetricsDefault];
    


    resizableImageWithCapInsets нужен для того чтобы нам не отресайзило картинку криво (фактически ее ресайзить не надо, но поскольку это bg image, то она растягивается по умолчанию)

    кейс 2
    убрать текст с кнопки Back (по дизайну не надо)

    [[UIBarButtonItem appearance] setBackButtonTitlePositionAdjustment: UIOffsetMake(0.f, -44.f) forBarMetrics:UIBarMetricsDefault];
    
  • 0
    Создается впечатление, что в связи с выходом iOS7 необходимость в стилизации почти пропадет — ведь в ней эпл утверждает что реалистичный вид приложений (имитирующий объекты реального мира) это прошлый век.
    • 0
      Apple любит сегодня утверждать одно, и хомячки соглашаются — Apple всегда прав. А завтра Apple утверждает совершенно обратное, и хомячки опять соглашаются. этожэпл!

Только зарегистрированные пользователи могут оставлять комментарии. Войдите, пожалуйста.