Вы конечно извините, но это совсем не отвечает на поставленный вопрос, а только показывает вашу некомпетентность и невежество в данном вопросе. Почему выдаст ошибку? Как это связано с "альфа-каналом названия" кнопки?
Возможно вы хотели ответить подобным образом, но ошиблись в парочке слов:
Так как, из CGColor легче получить альфа-канал, чем из UIColor(который backgroundColor), я буду обращаться к нему. Тут есть два способа его получить, мы можем получить его из UIColor (backgroundColor.cgColor) или из леера, который имеет тот же цвет (см. документацию как работает леер) — layer.backgroundColor. По каким-то личным причинам, я выбрал второй путь, и мой выбор никак не зависит от названия кнопки, потому что оба этих цвета — цвет фона кнопки. Извините, что ввел вас в заблуждение таким предложением, я обязательно его отредактирую, что бы не вводить в заблуждение следующих мои уважаемых читателей.
При чем тут что выдаст ошибку — это только показывает ваше не знание данного вопроса.
С уважением, читатель.
Вот все вроде хорошо, только пожалуйста, не путайте симуляцию и эмуляцию. Это разные вещи. Remote iOS Simulator — видимо это симулятор (как сказано на самом сайте), а не эмулятор. В Mac нет и не было iOS эмуляторов, только симуляторы.
В этом ключе — да, конечно вы правы. Но я не говорил, что вообще не нужно так делать, но и в большинстве случаев, это излишне. В статье про такие вещи не сказано ни слова, из чего можно сделать вывод, что отдельные сториборды так же используются вместо xib'ов в большинстве случаев.
Тут конечно же нужно смотреть по ситуации, что необходимо использовать, но никогда не прыгать из крайности в крайность и использовать лишь один инструмент для всех случаев.
Потом один сторибоар для одного экрана, по мне дак попахивает костылем
Согласен с вами, человек использует Storyboard, но ограничивается функциональностью xib. Почему бы сразу не использовать xib'ы? Тогда бы вся статья уложилась в одно предложение и было бы более хорошее решение. Просто: "Лучший способ работать со сторибордами? Не работайте с ними, используйте xib. " — вот и вся статья.
Но автор решил пойти трудным путем и использует более мощный инструмент лишь на малую его часть. По аналогии, это как взять КАМАЗ для того, что бы перевезти детскую песочную лопатку.
Статья очень хорошая и полезная, спасибо автору за его труд.
Но так же было бы очень приятно видеть не только описание FRC, но и заметку о его проблемах и в каких случаях его лучше не использовать. Тогда бы статья была из ряда must have по core data.
P.S. Почему в методе конфигурации ячейки вы делаете return cell ?? UITableViewCell()
если строкой выше вы уже используете force-unwrap :)
Проблема не только в том, что помешались на MVC, а в том, что еще и этот MVC они не понимают или понимают не правильно. Полностью согласен с комментарием выше(коммент). Очень много авторов, кто пишет о паттернах и не понимает MVC, так что уж говорить об остальных разработчиках
Заранее извиняюсь, если своим комментарием я оскорблю ваши чувства.
Данный комментарий является сугубо моим личным мнением.
Мне кажется, или существует какой-то негласный закон, что статьи об одном и том же без новой информации должны публиковаться каждые пол года/год?
Подобных статей на хабре уже достаточно(Что бы не быть голословным: Хабрапоиск). Да и на остальных ресурсах есть куча статей про блоки. Вы не внесли никакой новой информации в свою статью.
Так же по заголовку статьи, я ожидал увидеть о том, как работают блоки, а не как с ними работать. Слишком поверхностно описали блоки.
Например, сразу же возникают следующие вопросы: Что же есть стек хранения блоков, где он находится? Когда умирают блоки в стеке и какой их жизненный цикл в общем? Что есть куча? Какое её отличие от стека? Когда умирают глобальные блоки? Какой их жизненный цикл?
Вы конечно извините, но это совсем не отвечает на поставленный вопрос, а только показывает вашу некомпетентность и невежество в данном вопросе. Почему выдаст ошибку? Как это связано с "альфа-каналом названия" кнопки?
Возможно вы хотели ответить подобным образом, но ошиблись в парочке слов:
При чем тут что выдаст ошибку — это только показывает ваше не знание данного вопроса.
С уважением, читатель.
Вот все вроде хорошо, только пожалуйста, не путайте симуляцию и эмуляцию. Это разные вещи. Remote iOS Simulator — видимо это симулятор (как сказано на самом сайте), а не эмулятор. В Mac нет и не было iOS эмуляторов, только симуляторы.
В этом ключе — да, конечно вы правы. Но я не говорил, что вообще не нужно так делать, но и в большинстве случаев, это излишне. В статье про такие вещи не сказано ни слова, из чего можно сделать вывод, что отдельные сториборды так же используются вместо xib'ов в большинстве случаев.
Тут конечно же нужно смотреть по ситуации, что необходимо использовать, но никогда не прыгать из крайности в крайность и использовать лишь один инструмент для всех случаев.
Согласен с вами, человек использует Storyboard, но ограничивается функциональностью xib. Почему бы сразу не использовать xib'ы? Тогда бы вся статья уложилась в одно предложение и было бы более хорошее решение. Просто: "Лучший способ работать со сторибордами? Не работайте с ними, используйте xib. " — вот и вся статья.
Но автор решил пойти трудным путем и использует более мощный инструмент лишь на малую его часть. По аналогии, это как взять КАМАЗ для того, что бы перевезти детскую песочную лопатку.
Сейчас xib'ы никуда не делись. Не знаю почему автор использует Storyboard на каждый экран, вместо использования xib'ов. Очень странный подход
Статья очень хорошая и полезная, спасибо автору за его труд.
Но так же было бы очень приятно видеть не только описание FRC, но и заметку о его проблемах и в каких случаях его лучше не использовать. Тогда бы статья была из ряда must have по core data.
P.S. Почему в методе конфигурации ячейки вы делаете
return cell ?? UITableViewCell()если строкой выше вы уже используете force-unwrap :)
Данный комментарий является сугубо моим личным мнением.
Мне кажется, или существует какой-то негласный закон, что статьи об одном и том же без новой информации должны публиковаться каждые пол года/год?
Подобных статей на хабре уже достаточно(Что бы не быть голословным: Хабрапоиск). Да и на остальных ресурсах есть куча статей про блоки. Вы не внесли никакой новой информации в свою статью.
Так же по заголовку статьи, я ожидал увидеть о том, как работают блоки, а не как с ними работать. Слишком поверхностно описали блоки.
Например, сразу же возникают следующие вопросы: Что же есть стек хранения блоков, где он находится? Когда умирают блоки в стеке и какой их жизненный цикл в общем? Что есть куча? Какое её отличие от стека? Когда умирают глобальные блоки? Какой их жизненный цикл?