Пользователь
0,0
рейтинг
27 сентября 2013 в 18:02

Разработка → Apple, допили пожалуйста Interface Builder!

Этот пост — крик гнева в сторону Apple, и все же во мне осталась надежда. Я являюсь iOS-разработчиком уже 4 года, и то, что поначалу казалось сиюминутным несовершенством, несущественными деталями, с годами превращается в китайскую пытку водой, а ведь мы с вами пользуемся IB каждый день, ну или хотя бы раз в неделю.



Возможно, Apple и не заслуживает такой критики — правда, все остальное, ну или почти все остальное, у них на высоте. Исключая iTunes и Apple developer portal (который за последние годы, все же, стал значительно лучше) технологии позволяют сосредоточиться на том, что ты делаешь, а не на том, как это будет смотреться в IE.

Сначала я не использовал IB вовсе, уж таким кривым и убогим он мне казался после других визуальных редакторов. Даже Macromedia Dreamviewer MX, имхо, имел больше шансов называться WYSIWYG-редакторов для UI. Но прошло несколько лет, и появилась замечательная штука — Autolayout — которую катастрофически неудобно имплементить в коде. Мало счастья в таком коде:

UIImageView *iv = [[UIImageView alloc] initWithImage:image];
    UIView *renderView = [[UIView alloc] initWithFrame:iv.bounds];
    NSInteger completedDistance = renderView.bounds.size.width * percentsCompleted;
    UIView *progressView = [[UIView alloc] initWithFrame:CGRectMake(completedDistance, 0, renderView.bounds.size.width, renderView.bounds.size.height)];
    progressView.backgroundColor = RGB_UICOLOR(255, 255, 255, 0.8);
    renderView.clipsToBounds = YES;
    [renderView addSubview:iv];
    [renderView addSubview:progressView];


но код вида

NSMutableArray *constraints = [@[] mutableCopy];
    
    [constraints addObject:[NSLayoutConstraint constraintWithItem:self
                                  attribute:NSLayoutAttributeWidth
                                  relatedBy:NSLayoutRelationEqual
                                     toItem:self.parentView
                                  attribute:NSLayoutAttributeWidth
                                 multiplier:1
                                   constant:0]];
   [constraints addObject:[NSLayoutConstraint constraintWithItem:self
                                  attribute:NSLayoutAttributeHeight
                                  relatedBy:NSLayoutRelationEqual
                                     toItem:self.parentView
                                  attribute:NSLayoutAttributeHeight
                                 multiplier:1
                                   constant:0]];
    [constraints addObject:[NSLayoutConstraint constraintWithItem:self
                                  attribute:NSLayoutAttributeTop
                                  relatedBy:NSLayoutRelationEqual
                                     toItem:self.parentView
                                  attribute:NSLayoutAttributeTop
                                 multiplier:1
                                   constant:0]];
    [constraints addObject:[NSLayoutConstraint constraintWithItem:self
                                 attribute:NSLayoutAttributeLeading
                                 relatedBy:NSLayoutRelationEqual
                                    toItem:self.parentView
                                 attribute:NSLayoutAttributeLeading
                                multiplier:1
                                  constant:0]];
    
    [self.parentView addConstraints:constraints];


ввергает душу девелопера в уныние и депрессию. В IB настройка авторазметки (autolayout) по началу тоже на сахар, но с ходом времени приноравливаешься, начинаешь заставлять себя не замечать жутких косяков, терпеть маленькие недостатки пока… у тебя не случается истерика и количество откровенных ляпов, неисправленных годами, не переваливает за все разумные пределы. А ведь альтернативы нет, формат недокументарованный, сторонних инструментов не будет! Вот мой укороченный черненький списочек:

  • дайте масштаб хотя бы 200%! Если на вьюхе много маленьких элементов, можно сойти с ума тыкая мышкой в микроскопические вьюшечки, выбирать из длиннющего списка — тоже задача не из быстроприятных;
  • визуально можно задать далеко не все свойства вьюх, хорошо если 30%. Вспоминается Borland Delphi и его волшебный Object Inspector, в котором можно было создать практически любую вьюху, и выглядела она почти так же, как и в рантайме. В IB вьюхи похожи на говно, точнее на набор абстрактных квадратов руки Пикассо. Зато есть флаг Hidden (ВСЕ, ВСЕ выставляют его программно в зависимости от событий!) и Stretching (я даже не знаю, что это такое);
  • Раньше в качестве хедера таблицы катила вьюха (UIView), сейчас нужен UITableViewHeaderFooterView. Окей, откуда же мне ее перетащить в ксиб? Правильно, ниоткуда, пиши руками! А если вздумаешь подсунуть таблице UIView-ху, я обижусь и крэшнусь;
  • Нет внятного XML, который генерит IB. Вручную невозможно ни подправить, ни смержить. Начинаешь, прости господи, завидовать Android-разработчикам — у них есть в меру говеный визуальный редактор, но в случае чего пишите ручками — никто не обидится!
  • После смены класса вьюхи ее «IB-сверхъя» не меняется, что ведет к глюкам и крашам как вашего приложения, так и всего xCode. Допустим, вы полчаса создавали UITableViewCell со множеством сабвьюшек и констрэйнтов, и вдруг внезапно поняли, что вам нужен CollectionView и, соответственно, его ячейка. Выход один — пока вы не потратили невосполнимый запас жизненной энергии, удаляйте ксиб и пересоздавайте его с нуля. Только так Apple может гарантировать вам работоспособность приложения;
  • Где внятные best practices по сторибордам, особенно если приложение не блокнот или калькулятор? Когда пытаешься портануть на айпад приложение, которое индус или соотечественник, увлеченный индийской культурой разрабатывал исключительно в сториборде, плачешь кровавыми слезами. Ячейки таблиц нужно вооще запретить создавать в сторибордах, ксибы и только ксибы! Система должна иметь минимальную защиту от дурака;


Мало всего этого, нам недавно добавили новой боли в заднице:

  • Наиглючнейший интерфейс IB (простите тафтологию) из всех предыдущих реинкарнаций! Констрэйнты часто притворяются Leading space (видимо, такая рыба в собственном ксибе). Единственный способ понять, что это такое — чуть-чуть раздвинуть окно Assistant Editor-а, но!
  • При этом наш холст начинает плавно уезжать вверх и влево!
  • За год, прошедший с выхода iOS 6 все уже привыкли, что IB сам доставляет все ненужные констрэйнты до логической целостности, а тут он по умолчанию делает это неявно, во время компиляции ксиба! Так что предугадать, к чему приведет введение одного лишь width, без запуска приложения никак нельзя. Советую использовать команду «Add missing constraints» и верстать по-старинке.


К чести Apple можно сказать, что констрэйнты перестали съезжать от каждого чиха на мышку, а ведь это доводило меня до нервного срыва 4 раза в xCode 4, а напарник друга коллеги даже скончался от сердечного приступа.

Те, кто недавно открыл для себя iOS, хором поют «допилят!», свято веруя в икону яблока и Стива Джобса. На что я возражаю: «Не допилят!», у них всегда найдется десяток дел поважнее. Действительно важных, красивых дел, но Apple — мы имеем с IB дело каждый день, пожалей нас, простых смертных девелоперов!

На прощание хочу предложить интересный опрос:
Как вы верстаете UI в iOS?

Проголосовало 627 человек. Воздержалось 424 человека.

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

@iago
карма
48,0
рейтинг 0,0
Реклама помогает поддерживать и развивать наши сервисы

Подробнее
Реклама

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

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

  • +1
    IB не нужен.

    Сначала все весело-приятно, а потом внезапно пытаешься сделать шаг в сторону и начинаешь проклинать тот день, когда связался с этой шарманкой. Автолейауты можно было бы сделать по-человечески и из кода. Но не делают :(
    • 0
      Я тоже всегда так считал и считаю, но бывает множество факторов, когда приходится использовать ИБ. Например:
      — проект уже год велся с ИБ, переписывать все с нуля не дают;
      — все те же автолэйауты, которые по задумке чудо как хороши;
      — Эппл промоутит IB, и значит каждый день рождаются сотни программистов, которые используют IB. Хорошо если вы пишете свой проект, но придя в команду где используют IB, приходится использовать IB.
  • –3
    И мне кажется, что еще очень не скоро сделают вменяемый визуальный редактор интерфейса для iOS. Достаточно посмотреть на успехи Microsoft на этом поприще. Они свой xaml оттачивают уже с десяток лет, и все равно, его использование периодически напоминает адскую пытку, особенно, когда хочется запилить всякие финтифлюшки с анимациями или переопределением сложных контролов. Вместо одного рабочего языка ты вынужден учить два — сам язык + язык разметки. Тот кто думает, что это удобно, просто вряд ли с этим серьезно работал.

    Понятно, что эта идеология идет из веба. Но в вебе она вынужденная + несет определенные плюшки. Там это продукт стандартизации html. Но в мобильных и десктопных платформах от использования дополнительного языка для разметки мы не получаем никаких плюшек, так как нет единого стандарта. Замечания типа «зато любой дурак может верстать и не знать код» все равно разбиваются о суровую реальность. Не может. В итоге одни минусы и ровно один плюс — можно привлекать начинающих разработчиков тем, что формочки клепаются визуально.
    • +3
      Microsoft не показатель, в 1998 году с выходом Visual C++ 6.0 — сравните визуальный редактор Visual C++ 6.0 и Borland C++ Builder любой версии. Разница была просто колоссальна, а рынок и технологии — примерно одни и те же.
    • +4
      Сказануть такое мог только человек, учивший XAML по третесортным туториалам «как быстро сделать x на WPF». Достаточно прочесть нормально структурированную специализированную книгу, и вопросов не останется — там все очень логично и довольно просто.
      • +2
        Если в систему А добавить компонент Б, то система АБ никак не может быть проще, чем А и Б по-отдельности. Поэтому вводить Б — дурь.
        Можно было ничуть не хуже статическое объвление интерфейсов поддержать на уровне одного языка. Вон, у Xamarin есть JSON-подобный язык разметки для Monotoch.Dialog на основе C#. Работать с этим на порядок удобнее, чтобы ввести кастомное поведение или представление в контрол мне не нужно изгалаться на десяток файлов. Просто наследуешь и все. Что мешало MS сделать то же самое?
  • НЛО прилетело и опубликовало эту надпись здесь
    • –1
      Вы счастливчик, каких немного.
      • +1
        Меня тоже припишите сюда.
        Не имел никаких проблем с IB — только с Autolayout (тут приходится пользоваться своим, менее приятным решением)
        • +2
          Так никаких или с autolayout'ом все же были? :)

          Что еще раздражает, так это то, что Interface Builder при открытии файла зачем-то его меняет. Системы контроля версий (особенно, те, которые лочат файлы, типа P4) дуреют с этого. Точнее, системы контроля версий все контролируют, а дуреют программисты…
          • +1
            Autolayout не использую в принципе — это ужасный геморрой тянущийся сутками. Нервы свои стоит жалеть.
            Думал, в Xcode 5 допилили, ан нет — все тот же ужас.

            Коротко: проблемы были только с Autolayout, пока им пользовался.

            А еще в Xcode 5 у меня полностью отвалилась история версий (git) во всех проектах — не знаю, что делать.

            Недавно начал пользоваться eclipse, пожалел, что там нельзя вести разработку с IB и симулятором :(
            • 0
              Меня Autolayout в Xcode 5 порадовал, если что не так сразу напишет warning или ошибку
              • 0
                Кстати, беру свои слова насчет Autolayout в Xcode 5 назад. Только что научился им пользоваться. Есть пара хаков, которые приходится использовать — но, в основном, Apple отлично поправили его.
                • +1
                  HTML-верстка прекрасно, все одинаково смотрится в разных браузерах, никогда не имел проблем с IE. Есть пара хаков, которые приходится использовать, особенно в CSS, но в остальном никогда не имел проблем.
      • +1
        я тоже xib-ы использую, помоему хорошо так уменьшают объем кода, огорчает отсутствие стилей, если надо поменять шрифт, то надо менять его во всех xib-ах руками
    • +2
      Меня в этот же список запишите. Много лет пользую IB — и ксибы и сториборды. Работаю с разной сложностью интерфейсами, все ок. Autolayout не использую :)
  • +3
    «Еще один не выдержал — слабак!» :)

    Самая пичаль это то, что генерит этот билдер (НЕХ), на андроиде design view используется только как превьюха, т.к. драгндроп работает еще говеннее, чем билдер. Но все прекрасно правится ручками с авто-подстановкой, авто-форматиронием и авто-сделайчтобыбыловсехорошо.

    «Сотрудники компании эппл» решили, что негоже разработчикам трогать руками «сырой» xml и сделали ад и страдания. :) Впрочем, со временем я даже кое-что все таки там правил, смену контроллера и прочие плюшки прям из хмл/
    • 0
      Я тоже пытался, но все без толку — иногда работает, иногда нет — и напарываешься на неочевидные глюки. Потом через 2 часа пересоздашь ксиб, и понимаешь, что произошло что-то тебе не подвластное.
  • +1
    Еще немного раздражает такая мелочь — когда выбираешь в сториборде другую вьюху, список ее компонентов приходится «выбирать из длиннющего списка» всех контроллеров. Можно ведь было сделать подскролл.
  • +2
    Ох, как же я не люблю этот IB… и автор прав насчет автолэйаутов — это такой гемморой, если делать в коде с примесями IB.
  • –1
    >> дайте масштаб хотя бы 200%! Если на вьюхе много маленьких элементов, можно сойти с ума тыкая мышкой в микроскопические вьюшечки, выбирать из длиннющего списка — тоже задача не из быстроприятных;

    Ctrl+Shift+Click выдает полный список вьюх под кликом и дальше двигаем стрелочками.

    >> визуально можно задать далеко не все свойства вьюх, хорошо если 30%.

    Я бы сказал 90% из самых юзабельных. Сейчас на вскидку не могу сказать свойств нет, но они очень нужны. А Вы?

    >> Stretching(я даже не знаю, что это такое)

    Я тоже. Но может тогда оно нам не надо?)

    >> Раньше в качестве хедера таблицы катила вьюха (UIView), сейчас нужен UITableViewHeaderFooterView. Окей, откуда же мне ее перетащить в ксиб? Правильно, ниоткуда, пиши руками! А если вздумаешь подсунуть таблице UIView-ху, я обижусь и крэшнусь;

    Метод у UITableViewHeaderFooterView initWithReuseIdentifier: как бы намекает что там не простая вьюха.

    >> Нет внятного XML, который генерит IB. Вручную невозможно ни подправить, ни смержить. Начинаешь, прости господи, завидовать Android-разработчикам — у них есть в меру говеный визуальный редактор, но в случае чего пишите ручками — никто не обидится!

    XCode 5 сейчас генирит вполне читаемый XML. Даже править можно руками.

    >> После смены класса вьюхи ее «IB-сверхъя» не меняется, что ведет к глюкам и крашам как вашего приложения, так и всего xCode. Допустим, вы полчаса создавали UITableViewCell со множеством сабвьюшек и констрэйнтов, и вдруг внезапно поняли, что вам нужен CollectionView и, соответственно, его ячейка. Выход один — пока вы не потратили невосполнимый запас жизненной энергии, удаляйте ксиб и пересоздавайте его с нуля. Только так Apple может гарантировать вам работоспособность приложения;

    Тут согласен. Надо фиксить.

    >> Когда пытаешься портануть на айпад приложение, которое индус или соотечественник, увлеченный индийской культурой разрабатывал исключительно в сториборде, плачешь кровавыми слезами.

    А в чем конкретно проблемы? Ну скопировал ячейки, по-растягивал и что?
    • +3
      >> Ctrl+Shift+Click выдает полный список вьюх под кликом и дальше двигаем стрелочками.
      это что, удобнее чем 200% масштаб и клик? Это все равно что в фотошопе по слоям находить, либо визуально.
      >> Я бы сказал 90% из самых юзабельных. Сейчас на вскидку не могу сказать свойств нет, но они очень нужны. А Вы?
      Да, могу, список их не вместится на ваш монитор.
      >> Я тоже. Но может тогда оно нам не надо?)
      Но если оно мне и вам не надо, зачем тогда его выносить туда, где итак явный недостаток полезных свойств.
      >> Метод у UITableViewHeaderFooterView initWithReuseIdentifier: как бы намекает что там не простая вьюха.
      Вьюха правильная, но ее нет в IB, поэтому нет возможности задизайнить ее через IB.
      >> XCode 5 сейчас генирит вполне читаемый XML. Даже править можно руками.
      Не настолько правильный, как XAML или андроидовский лэйаут, недокументированный, непредсказуемый. Тоже заменял в нем классы, и бывало напарывался на странные косяки.
      >> А в чем конкретно проблемы? Ну скопировал ячейки, по-растягивал и что?
      Скопировал ячейки, порастягивал и потратил на это час.
      • –2
        >> Ctrl+Shift+Click выдает полный список вьюх под кликом и дальше двигаем стрелочками.
        это что, удобнее чем 200% масштаб и клик? Это все равно что в фотошопе по слоям находить, либо визуально.

        в фотошопе автоселект слоя по клику, тут тоже кликнул и выбрал нужный. Зачем 200%? Вы там вьхи 2х2 двигаете по экрану?

        >> Я бы сказал 90% из самых юзабельных. Сейчас на вскидку не могу сказать свойств нет, но они очень нужны. А Вы?
        Да, могу, список их не вместится на ваш монитор.

        Ого! Я думаю вы недооцениваете мой монитор. Ну давайте хотя бы 10.

        >> Я тоже. Но может тогда оно нам не надо?)
        Но если оно мне и вам не надо, зачем тогда его выносить туда, где итак явный недостаток полезных свойств.

        Может кому-то надо? Где Вы кстати нашли его? Что то не могу найти.

        >>Метод у UITableViewHeaderFooterView initWithReuseIdentifier: как бы намекает что там не простая вьюха.
        Вьюха правильная, но ее нет в IB, поэтому нет возможности задизайнить ее через IB.

        Есть метод делегата — (UIView *)tableView:(UITableView *)tableView viewForHeaderInSection:(NSInteger)section; который должен вернуть UIView из которой потом будет создан таблицей UITableViewHeaderFooterView.

        >> XCode 5 сейчас генирит вполне читаемый XML. Даже править можно руками.
        Не настолько правильный, как XAML или андроидовский лэйаут, недокументированный, непредсказуемый. Тоже заменял в нем классы, и бывало напарывался на странные косяки.

        Я думаю внимательность тут решающий фактор. Вообще я только конфликты в ней решал. В основном IB хватает.

        >> А в чем конкретно проблемы? Ну скопировал ячейки, по-растягивал и что?
        Скопировал ячейки, порастягивал и потратил на это час.

        А как должно быть? Волшебная кнопка «Сгенерировать UI для iPad»?
        • +1
          Глупо спорить с тем, что Xcode — угребище, а Interface Builder и того хуже. Альтернатива первому есть, а вот последнему — увы. То, что вы сейчас затеяли очень похоже на спор ради спора.

          Не надо так.
          • –1
            Так пишите в Vim. Там-то все намного проще.

            То, что Вы затеяли (я имею ввиду пост) очень похоже на нытье. Нравится Вам или нет Вы все ровно будете писать под iOS/MacOS в Xcode. Все альтернативы убогие.
            • +1
              Вы в пылу спора ради спора забыли с кем и о чем спорите. Я не автор поста.

              Пишу частенько в sublime text, кстати. Чуть меньше, чем в Xcode, но все же. Но запросто могу поверить, что кому-то AppCode больше по душе, чем Xcode.
      • 0
        Для пропертей можно юзать «User-defined Runtime Attributes», там даже не property, а keyPath. Другое дело, что этот вариант очень не очевидный, можно несколько дней угробить, разбираясь откуда эти значения берутся. Но вариант.
  • –3
    Сталкивался с IB, только когда писал первое приложение.
    Сейчас приложения используют настолько «нестандартный» интерфейс, что связываться с IB нет смысла вообще
  • +6
    В свете того, что сейчас происходит, у меня более скромные пожелания: «Apple, пожалуйста, не сломай то, что работает!»
  • +3
    С недавних пор перелез на Masonry для конструирования autolayout'а из кода. Визуально количество кода уменьшилось раза в три.

    Тот код из поста переписывается в
    [self makeConstraints:^(MASConstraintMaker *make) {
        make.width.equalTo(@0);
        make.height.equalTo(@0);
        make.top.equalTo(@0);
        make.leading.equalTo(@0);
    }];


    Нервов при написании constraint'ов поубавилось. Оно далеко неидеально, но действительно стоит того, чтобы попробовать.
  • 0
    там появилось волшебная кнопка add another constrains в Xcode 5. Сорвала продолжительную овацию на WWDC %)
    • 0
      Ну да, я ж про нее писал :) если б не она, пришлось бы на картах гадать, куда xCode поставит констрэйнт
      • +1
        у вас глас вопиющего в пустыне. я сразу понял что тут херня и разделил nibs iphone/ipad а там немного подшаманиваю фреймы в зависимости от. получилось мининимум кода и понятно. эплы с constrains реально дали маху. ОЧЧЕНЬ сложно а они не в курсе что сложно :) потому что думают что совсем легко :)
        А когда у вас большой код и вы занимаетесь не только constrains, этот вижуал формат до одного места. это как засунуть в NSDictionary в одном месте volume & key а в другом потом мучительно вспоминать «что я нахрен имел ввиду в этой dictionary» :)
        • 0
          Что я могу ответить? Точняк!
  • 0
    Для уменьшения размера кода при работе с констрэинтами можно использовать Visual Format Language.
    Правда, если после этого вам по какой-то причине понадобится изменить один из добавленных подобным образом констрэинтов (т.е. его константу, больше там ничего менять нельзя), то искать нужный придется перебором массива constraints.
    А так да, работать с автолайаутом в IB не очень удобно. Хорошо, что хоть в XCode 5 этот процесс несколько улучшили, убрав, например, автодобавление недостающих констрэинтов.
  • +3
    Самый правильный путь — это самый простой.
    Да в 4 иксе автолейаут был говнищем. Ждем пока допилят пятый. Писать все в коде все равно не вариант, каждый раз НЕНАВИСТЬ когда сталкиваюсь с таким проектом и таской по рефакторингу или багфиксу оного. Поверьте, то что вы не можете попасть мышкой во вьюшку это ничто, по сравнению с рефакторингом чужого лейаут кода, зачастую похабно написанного.
    • 0
      верю, охотно верю!
  • +1
    Меня очень напрягают мерджи сторибордов на ровном месте, да и файлы проектов тоже не подарок. Хочу попытаться написать мерджилку сторибордов и проектов, хотя бы чтобы разруливались ситуации одновременного добавления экранов/файлов разными людьми. Пока мне кажется, что задача вполне решаема. Хабраюзер, нужна ли тебе такая утилита?
    • 0
      Нужна! Даже помочь могу!
    • 0
      Интуиция подсказывает, что задача не тривиальная, много подводных камней. Вообще, проблема с мерджем сториборда стоит действительно остро и подобный инструмент был бы многим полезен.
    • 0
      Если вы придумали хороший алгоритм, то это будет волшебная тулза!
  • 0
    Я не использую автоматического выравнивания и счастлив наличием IB.

    Что беспокоит меня?
    Подскажите, можно ли из *.xib, заведенного под iPhone сделать аналог под iPad простым копированием?

    Это действительно беспокоит.
    • 0
      Что-то я не понял вопроса. Т.е. вы хотите разные ксибы, но чтобы одинаково вели? Тогда зачем разные ксибы…
      • 0
        Потому что размеры устройств разные. Какая лучшая практика для приложений типа Universal?

        В данный момент я делаю так
        1) завожу iphone_568.xib, создаю controls, связи;
        2) копирую в iphone_480.xib
        3) рихтую view под 480

        Все. С Ipad.xib это не срабатывает. Приходится все элементы управления и связи тупо дублировать руками
        • +1
          Тут только AutoLayout поможет, судя по всему. В AL самое сложное, имхо, понять как он работает. Пока это понимание не пришло я дико плевался и также ненавидел Apple как и ТС.
  • 0
    Проблему с масштабом решал просто — выставлял координаты и размеры вручную. Причем весьма удобно смотреть расстояния до других объектов с зажатым Alt. Так что посмотрел сколько куда пикселей осталось — подвинул, растянул. Макеты получается сверстать пиксель в пиксель. То что на глаз расставил, все равно надо контролировать, чтобы стояло точно на своих местах.
  • +2
    Я ни разу не ios разработчик, но моих фрагментарных знаний как раз хватает, чтобы заявить следующее.
    AFAIK через IB можно задать абсолютно все свойства через user defined runtime attributes (key-value coding). И констрейнты все равно в коде трогать приходится если есть анимация позиции или размера.
    • 0
      Не совсем все, например какой-нибудь CGColor не выйдет. Как-то раз хотели так задать цвет границы у layer, пришлось кодировать
      • +2
        Ну это не такая уж большая проблема, по сравнению со пачкой кода который занимается только лишь расстановкой, порой, статических элементов, содержимое и внешний вид которых не меняется
  • +2
    > а напарник друга коллеги даже скончался от сердечного приступа.

    это шутка, или такое действительно имело место? Как пользователь IB, в реальность такого охотно верю.
    • 0
      Шутка конечно, но недалекая от истины :)
  • +1
    Лолшто? Может не Apple виноват в, простите, кривоватости чьих-то решений и рук?

    Поделюсь с вами тайным секретом, только не рассказывайте никому, а то не дай Б-г люди перестанут писать контроллеры по 800 строк с ручным лэйаутом и ручным же созданием статических элементов.

    Допустим, вы полчаса создавали UITableViewCell со множеством сабвьюшек и констрэйнтов, и вдруг внезапно поняли, что вам нужен CollectionView и, соответственно, его ячейка

    Для решения этой проблемы нужно просто создать xib с UIVIew, накидать на него все что вам нужно, создать класс с таким же названием (опционально) и вывести в этот класс необходимые аутлеты.
    После этого в вашей UITableViewCell, в init'е достаточно написать что-то типа

    NSString *partialIndentifier = NSStringFromClass([AwesomeView class]);
    UINib *partialNib = [UINib nibWithNibName:partialIdentifier bundle:nil];
    self.awesomeView = [[partialNib instantiateWithOwner:self options:nil] lastObject];
    [self addSubview:self.awesomeView];
    


    И в случае когда вы внезапно что вам нужен UICollectionViewCell, то вы просто проделываете все описанные действия в init'е CollectionCell.

    Более, этот метод, позволяет реюзать одну и ту же вьюху в разных частях вашего UI.

    Безусловно это все ужасно, лучше фигачить все руками, да.
    • 0
      Один хитрый трюк, скорее похожий на хак, вы выучили и обвиняете меня в кривости рук — да, вы большой молодец. Это, безусловно, позволяет вам утверждать что я верстаю 800-строчную простыню.
      • 0
        А где здесь хак? Нормальное стандартное решение.
        Меня жутко раздражают вот такие гневные посты с советами от советчиков, «начинающие» разработчики смотрят на такие высказывания и берут их в толк, после чего имеем как раз те самые контроллеры на 800 строк и синглтоны синглтонов завернутые в макрос в макрос в макрос…
        • 0
          Может тогда по всем пунктам пройдетесь, чтобы не быть голословным.
  • +1
    Вся надежда на AppCode :)
    • +1
      Была бы, если бы не на яве… :)
      • 0
        Учитывая как тормозят сториборды в нативном Xcode, будет смешно, если JetBrains удастся сделать более шуструю реализацию на Java.
        • +3
          За что минусуете, они реально тормозят на любом железе.
  • 0
    Использую UIView-AutoLayout для autolayout'a. Все хорошо, IB не нужен, спасибо)
    • 0
      Просмотрел API, либа вроде неплохая. Но не убирает один косяк — если приходится периодически копаться в чужом коде, поддерживать что-то, все равно придется иметь дело со стандартными средствами. Так что стандартные пути все же предпочтительнее.
      • +1
        Да, использую ее в проектах по «обоюдному согласию». Ее плюс в том, что в отличии от других популярных либ (keep и mansory) она ближе к эппловскому стилю и при этом возможностей выстрелить себе в ногу в ней гораздо меньше. В связке с VFL и пониманием того как все работает внутри либы (а там элементарная категория) autolayout можно и руками после нее писать.
        А вообще замечание про чужой код справедливо практически ко всем либам)
        • 0
          Либы — часто хорошо, главное не злоупотреблять :)
  • 0
    Ссылки на несколько хелперов для autolayout в комментариях уже есть, вот до кучи альтернативный подход: github.com/ReactiveCocoa/ReactiveCocoaLayout
  • +1
    Не боитесь, что у вас будут сложности с устройством на работу после этого поста?
    Шутка :) Стивов Джобсов уже нет.

    Никогда не имел проблем с IB, и, скорее, получаю удовольствие от него.
    Даже для самого харкордного кастома от заказчика у меня как-то всё просто получается.
    Часто сложные интерфейсы разделяю на простые вью
    Кода для вью получается не более двух страничек… Или для вью-контроллера — не более, чем трёх страничек.
    На вью обычно у меня от двух до четырех аутлетов. Если становится больше, надо подумать, может быть стоит разбить вью на несколько частей?
    Если вью-контроллер большой, может быть из него стоит вытащить код в невью-котроллеры (типа GameProgressController, MyNetworkRequestsChainController и т. п.).

    Посоветую вам не использовать сторибоарды, если вы не один в команде. Ксибы — хороший способ реюза частей интерфейса и комфортный распределенный девелопмент. Ксибы и сторибоарды можно (а иногда нужно) сочетать.

    В общем, делайте всё для своего удобства. Негритянский труд в виде таскания брёвен — это что-то далекое от программирования и мешает творчески подходить к задаче.
    • 0
      Даже если б и был, я б ему и тогда сказал, что IB как был полусырым продуктом в 2009-м, так и по сей день не выходит из этой фазы.
      В достаточно больших проектах вью контроллеры разрастаются и до нескольких тысяч строк — тогда делю их на DataSource и сам контроллер, выношу делегаты в отдельные классы (например, обработка коллбэков таблицы или collection view) — но у этого есть и обратная сторона медали, вследствие декомпозиции нужно создавать дополнительные интерфейсы и иные связи.

      В общем, в любом случае размер кода растет пропорционально количеству связанных между собой элементов, видимых единовременно на экране. Конечно, если нужно показывать, скажем, прогноз погоды и новости — можно смело делить их в совершенно разные контроллеры.

      Сториборды можно использовать, не надо только там создавать ячейки и лепить много контролов прямо на вьюху контроллера — замучаешься переносить на айпад и обратно.

      И все же, повторюсь, основной посыл статьи таков: Apple может потратить часть ресурсов и допилить IB до более законченного состояния. В 2009 я программил под мак и под iPhone OS — под мак создавать интерфейс в IB было раем, он был очень похож на рантаймовые вьюшки. Под iOS — как было занятие ниже среднего, таким оно и осталось.
      • 0
        >>Даже если б и был, я б ему и тогда сказал, что IB как был полусырым продуктом в 2009-м, так и по сей день не выходит из этой фазы. В достаточно больших проектах вью контроллеры разрастаются и до нескольких тысяч строк — тогда делю их на DataSource и сам контроллер, выношу делегаты в отдельные классы (например, обработка коллбэков таблицы или collection view) — но у этого есть и обратная сторона медали, вследствие декомпозиции нужно создавать дополнительные интерфейсы и иные связи.

        Вопрос, просто, чтобы знать, как там у других художников дела.

        А в ваших проектах как много классов, которые можно просто перетянуть курсором мыши в другой проект и они заработали бы?
        У меня где-то 50%-70% в зависимости от проекта, включая наследников UIViewController и UIView.
        • 0
          Не, никак не 50-70%%. Кроме чего-то универсального, есть 80% кода, который завязан на конкретное приложение и имеет смысл только в контексте его. Возможно, сказывается долгая продуктовая разработка — когда работал на аутсорсинге, процентов соответственно было больше.

          Ну и тут есть обратная сторона медали. Знал одного программиста, который долго работал замкнутый сам в себе, уж очень интровертный человек. Добавили его к нам на проект, к тому моменту уже шедший 1.5 года и в различное время писанный 3-4 девелоперами. Вместе с ним прилетело штук 50 файлов с префиксом от его имени-фамилии, большинство функциональности в которых дублировало уже имеющуюся. В общем, в команде стараюсь пользоваться вмес стандартным, и как можно меньше самописности — особенно в iOS, где стандартные библиотеки вполне неплохи.
  • 0
    [удалён]
  • 0
    Как интересно, наткнулся на свой пост трехлетней давности, а воз и поныне там. Появились Swift, часы, вот API с нейронными сетями на подходе, а IB как был так и остался, статья актуальна до сих пор

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