Комментарии 11
Вы стали жертвой непонимания терминов.
Табы в понимании Mac OS X — это именно то, что вы увидели.
Вкладки сафари — стандартным элементом системы, вроде бы как, не являются.
А вообще iOS в плане API по сравнению в OS X выглядит как большая работа над ошибками.
Табы в понимании Mac OS X — это именно то, что вы увидели.
Вкладки сафари — стандартным элементом системы, вроде бы как, не являются.
А вообще iOS в плане API по сравнению в OS X выглядит как большая работа над ошибками.
Забавно, что в упомянутом Qt такое есть. Правда, начиная с 10.10 работает как-то криво.
Что касается ваших скриншотов, табы в том же Finder выглядят немного иначе — нет крестика и ширина растягивается на все окно.
Что касается ваших скриншотов, табы в том же Finder выглядят немного иначе — нет крестика и ширина растягивается на все окно.
Когда вы пишете "Какие-то примеры можно найти на сайте cocoacontrols.com" или "Что-то предлагалось на stackoverflow.com", то я ожидаю, что ссылки ведут на "как-то примеры" и "что-то", а никак не на главную страницу сайтов. Вы два раза сослались на обсуждения на СО, и оба раза дали ссылку на главную страницу. Если уж даёте ссылки, до делайте их полезными, а не для галочки. Вы бы ещё написали "нашёл в Google" и дали ссылку на главную страницу поисковика.
Да, помню, как брали PSMTabBarControl и допиливали до какого-то адекватного состояния…
Кстати, а MMTabBarView нормально дружит с Autolayout?
Кстати, а MMTabBarView нормально дружит с Autolayout?
Добро пожаловать на борт.
Не используйте InterfaceBuilder. Он принесет больше боли, чем пользы. На всех платформах боль от использования средств создания интерфейса графическим путем примерно одинакова, но в случае ios/osx интерфейс эпически просто создавать из кода благодаря оберткам над AutoLayout (использовать его в чистом виде это как пить чистый спирт, не надо).
https://github.com/Tricertops/KeepLayout
Добавление Вашего таб бара бы выглядело в методе -loadView следующим образом:
```
MMTabBarView *tabBar = [MMTabBarView new];
tabBar.foo = bar; // тут выставляем всякие параметры
[view addSubview:tabBar];
tabBar.keepTopInset.equal = 0;
tabBar.keepHorizontalInsets.equal = 0;
tabBar.keepHeight.equal = 20; // Опционально, если автор не указал стандартный размер через -intrinsicContentSize
_tabBarIvar = tabBar;
```
Накодить эти строчки гораздо быстре, чем искать в списке, перетягивать, растягивать, раставлять констрейнты мышкой, создавать IBOutlet, линковать его с вьюхой, о боже.
И еще: AppCode, Cocoapods.
Happy coding! ^_^
Не используйте InterfaceBuilder. Он принесет больше боли, чем пользы. На всех платформах боль от использования средств создания интерфейса графическим путем примерно одинакова, но в случае ios/osx интерфейс эпически просто создавать из кода благодаря оберткам над AutoLayout (использовать его в чистом виде это как пить чистый спирт, не надо).
https://github.com/Tricertops/KeepLayout
Добавление Вашего таб бара бы выглядело в методе -loadView следующим образом:
```
MMTabBarView *tabBar = [MMTabBarView new];
tabBar.foo = bar; // тут выставляем всякие параметры
[view addSubview:tabBar];
tabBar.keepTopInset.equal = 0;
tabBar.keepHorizontalInsets.equal = 0;
tabBar.keepHeight.equal = 20; // Опционально, если автор не указал стандартный размер через -intrinsicContentSize
_tabBarIvar = tabBar;
```
Накодить эти строчки гораздо быстре, чем искать в списке, перетягивать, растягивать, раставлять констрейнты мышкой, создавать IBOutlet, линковать его с вьюхой, о боже.
И еще: AppCode, Cocoapods.
Happy coding! ^_^
Почему все так хейтят InterfaceBuilder? Вас никто не заставляет в нем все делать. Это еще один инструмент. И иногда в нем быстрее и удобнее что-то сделать, чем написать дофига строк кода. Например, когда дизайн до конца не утвержден и заказчик хочет посмотреть как это будет на девайся, потыкать пальцами, а потом половину переделать. И здесь IB и Storyboard'ы очень даже помогают.
AutoLayout даже в коде я использую безо всяких оберток (может потому что и спирт чистый пил когда-то давно). Я вообще не очень люблю тянуть кучу всего стороннего в проект. Не хочу зависеть от компонентов, которые написали непроверенные люди и неизвестно собираются ли они свои велосипеды поддерживать.
И еще: не использую AppCode, не использую Cocoapods, хотя пробовал и умею пользоваться и тем и другим.
Вообще, почему-то в среде iOS разработки популярно мнение: Apple сделало что-то (CoreData, AutoLayout, подключаемые Frameworks) слишком сложно, не хочу разбираться, скачаю что-нибудь попроще. А потом получается — а зачем мне использовать NSURLSession или ту же CoreData, если я уже умею AFNetworking и MagicalRecord, например.
AutoLayout даже в коде я использую безо всяких оберток (может потому что и спирт чистый пил когда-то давно). Я вообще не очень люблю тянуть кучу всего стороннего в проект. Не хочу зависеть от компонентов, которые написали непроверенные люди и неизвестно собираются ли они свои велосипеды поддерживать.
И еще: не использую AppCode, не использую Cocoapods, хотя пробовал и умею пользоваться и тем и другим.
Вообще, почему-то в среде iOS разработки популярно мнение: Apple сделало что-то (CoreData, AutoLayout, подключаемые Frameworks) слишком сложно, не хочу разбираться, скачаю что-нибудь попроще. А потом получается — а зачем мне использовать NSURLSession или ту же CoreData, если я уже умею AFNetworking и MagicalRecord, например.
Все хейтят IB потому что люди не умеют его готовить и строят громадные приложения в одной сториборде, а потом за ними переписывай.
И я заказчику накодю что угодно, и даже не буду ждать перекомпиляции проекта — хоткей и в симуляторе интерфейс перестроился. Если писать без обертки на чистом AL, то это действительно дольше, чем в IB.
AL без оберток очень плохо читаем.
iOS разработка != java dev != c++ dev. Тут другие правила и по факту 50 зависимостей в cocoapods гораздо лучше, чем свои решения и на практике проблем с ними не возникает. Есть непоправленная бага в стороннем проекте — форкни, поправь, в поде выставь ссылку на свой git, profit. Pull request не забыть сделать. Это гораздо быстрее, чем делать что либо самому. Потом на ваше место прийдет другой разработчик, и ему в этом всем разбираться.
А собственно ответьте на свой вопрос сами: а зачем? Чтобы понимать? Ясен перец нужно, а еще?
И я заказчику накодю что угодно, и даже не буду ждать перекомпиляции проекта — хоткей и в симуляторе интерфейс перестроился. Если писать без обертки на чистом AL, то это действительно дольше, чем в IB.
AL без оберток очень плохо читаем.
iOS разработка != java dev != c++ dev. Тут другие правила и по факту 50 зависимостей в cocoapods гораздо лучше, чем свои решения и на практике проблем с ними не возникает. Есть непоправленная бага в стороннем проекте — форкни, поправь, в поде выставь ссылку на свой git, profit. Pull request не забыть сделать. Это гораздо быстрее, чем делать что либо самому. Потом на ваше место прийдет другой разработчик, и ему в этом всем разбираться.
А собственно ответьте на свой вопрос сами: а зачем? Чтобы понимать? Ясен перец нужно, а еще?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Весёлые табы в MAC OS X или история про тот самый Tab View