Дополню, это тоже самое, если бы метод — (NSInteger)tableView:(UITableView *)tableView numberOfRowsInSection:(NSInteger)section в UITableViewDataSource протоколе сделать опциональным. И в случае, если этот метод не реализован, то таблица будет отображать пустоту. Это некорректное состояние для таблицы.
так как я намеренно сделала переменную-замыкание yForX Optional
В этом то и проблема, yForX не должен быть опциональным, потому что без этого замыкания GraphView не имеет значения, так как она не выполнит своего главного назначения — отобразить график. Указывая здесь optional Вы прячете потенциальный баг в приложении.
Если бы я делал эту фичу с помощью протокола, я бы сделал этот метод @required, в таком случае ошибка не будет запрятана.
Единственный минус использования замыканий/блоков вместо протоколов заключается в том, что компилятор/анализатор не подскажет Вам, если Вы забудете проинициализировать свойство замыкания/блока (в примере было yForX). В случае использования протокола мы получим warning о том, что обязательные методы протокола не реализованы в классе-делегате.
Я с Вами не соглашусь. То, что в коде, с которым вы сталкивались не используются блоки в качестве делегатов, не значит, что в целом разработчики игнорируют такой способ. Замена делегатов на блоки в стандартном SDK и количество плюсиков у библиотеки, на которую я сослался в предыдущем комментарии, подтверждают мои слова.
То, что в Swift замыкания описываются более лаконично, чем в Objective-C, нельзя считать причиной того, что Objective-C разработчики предпочитают использовать делегирование вместо блоков. Потому что Swift в целом изначально проектировался как лаконичный язык, большое количество возможностей сократить код замыкания в зависимости от условий (наличие аргументов, наличие возвращаемого типа и т.д) хорошо демонстрирует это.
Вы же не скажете, что Objective-C разработчики стараются избегать объявлять свойства в классе, а Swift разработчики обожают это делать, потому что в Swift это выглядит просто и красиво:
Objective C:
Пример грубый, но я думаю ясно отражает суть мысли.
Повторюсь, мой изначальный комментарий был не о том, что Swift плохой, а Objective-C хороший или наоборот, а о том, что в Вашей статье неточность:
… а вот передача информации «назад» из текущего MVC в предшествующий осуществляется с помощью делегирования как в Objective-C, так и в Swift.
Нужно выполнить 6 шагов, чтобы внедрить делегирование во взаимодействие View и Controller. Однако в Swift мы можем заменить этот процесс более простым...
В Objective-C этот процесс можно сделать таким же простым как и в Swift.
Вы так написали, как будто возможность использования замыканий вместо делегирования появилась только в Swift.
В Objective-C замыкания (блоки) появились 5 лет назад, и с тех пор в iOS SDK делегирование постепенно заменяется на блоки. Не говоря уже про сторонние библиотеки, которые заменили делегирование на замыкания почти для всех основных классов стандартного SDK.
Перейти в «My books» -> Нажать «Restore purchases», при этом заранее ничего не покупая -> Результат: индикатор загрузки висит вечно. Пришлось перезапускать приложение.
Баг с реиспользованием ячеек
Перейти в поиск -> Выбрать одну из категорий -> Купить одну из книг -> Во время скачивания книги выключить доступ к интернету -> Вернуться в приложение -> Проскролить список книг -> Результат: на каждой четвертой ячейке отображается «6.68%». На скриншоте проценты загрузки отображаются на книге за 6.99$, а я покупал за 0.99$.
Некорректное сообщение об ошибке
Перейти в «My books» -> Выбрать одну из книг -> Выделить какой-либо текст -> Нажать на иконку Evernote -> Откроется диалог Evernote с просьбой авторизоваться -> Нажать «Cancel» в верхнем правом углу -> Результат: при любых условиях соединения с интернетом выдается сообщение об ошибке.
Пропадание закладки
Перейти в «My books» -> Выбрать одну из книг -> На одной из страниц выставить закладку свайпом вниз -> В верхнем тулбаре изменить размер шрифта на максимальный -> Результат: закладка пропадает. Ее можно найти в другой странице, если немного полистать книгу. При чем контент этой страницы полностью отличается от изначальной страницы, где была выставлена закладка.
Некорректное поведение Notes
Перейти в «My books» -> Выбрать одну из книг -> Выделить часть текста -> Добавить в Notes -> Выделить еще одну часть текста (текст должен включать часть предыдущего выделения) и добавить в Notes -> Перейти в Notes -> Удалить одно из выделений -> Вернуться в книгу -> Результат: в тексте выделение не убралось (баг) -> Выделить удаленную (из заметок) часть текста -> Нажать Highlight -> Результат: приложение переходит на экран Notes, список пуст, все выделения сняты (баг).
Баг с индексацией в Notes
Перейти в «My books» -> Выбрать одну из книг -> Выделить 3 части текста -> Добавить все в Notes -> Удалить вторую заметку из Notes -> Попытаться перейти по последней (ранее третьей, сейчас второй) вкладке на страницу в тексте -> Результат: приложение переходит на страницу с первой заметкой.
Дергание слайдера при навигации по книге
Перейти в «My books» -> Выбрать одну из книг -> Потянуть слайдер вперед (например до 50%) -> Подождать пока загрузится страница -> Потянуть слайдер в обратную сторону (например до 20%) -> Результат: слайдер самостоятельно перемещается на 21%, далее загружается страница, и слайдер сам возвращается на 20%.
Слабый user experience при попытке купить книгу в оффлайне
Отключить соединение с интернетом -> Перейти в «Market» -> Попробовать купить книгу -> Результат: на долю секунды отображается индикатор загрузки «Connecting to iTunes», никаких сообщений об ошибки. Хочется, чтобы меня оповестили о том, что соединение с интернетом отсутствует.
Слабый user experience в поиске
Форма для поиска не очищается после возвращения с результатов поиска. Видя заполненное поле поиска, ожидаешь, что снизу отображается отфильтрованный контент. На самом деле отображаются категории, никак не связанные с поиском.
В общем ничего нового, я от своих слов в изначальном комментарии не отказываюсь.
Хотя жена не была так категорична: «Дизайнеры молодцы! А приложений без багов не бывает. Жалко только, что книги все платные :)»
Почему именно Бизнес. Книги. 3.0?
«Банк открытие» — у меня нет счета в этом банке, ничего не протестируешь;
«Живой словарь» — нет ссылки на приложение;
«Смотри+» — нет ссылки на приложение;
«Ренессанс Страхование» — не доступно в американском App Store. Русского аккаунта у меня нет;
«Redigo» — нет ссылки на приложение;
«Бизнес. Книги. 3.0» — на этом и остановились.
Что ж, давайте пойдем дальше, не могли бы Вы указать приложение, которое было разработано в вашей компании в последнее время, чтобы избежать вышеописанной ситуации. Только в данном случае, чтобы было честно, я подключу жену — QA. Предпочитаю верить делу, а не словам.
Так красиво Вы все расписали, что я не выдержал и пошел на сайт, чтобы потестировать одно из написанных вами приложений.
Выбор пал на приложение «Газета.ru» (не самый крупный клиент, но и не самый мелкий).
Понадобилось 10 минут, чтобы убедиться, что не все так гладко как на словах.
Вот несколько контраргументов громким словам в статье:
Крутая гибкая вёрстка
Форма поиска перекрывается со статус баром.
Написание красивых и удобных компонентов интерфейса «строго по конвенции
Заголовок секции таблицы перекрывает содержание самой секции.
Писать красивый и отказоустойчивый код
Приложение упало после выбора всех пунктов в настройках «Автозагрузка» и быстрого скролирования контента на главном экране приложения.
Стилизация
Стильный черный прямоугольник внизу при загрузке комментариев.
Маркетинг это конечно хорошо, но нужно знать меру.
И раз уж ребята будут разрабатывать реальные компоненты и учавствовать в реальных проектах, то и денюжку можно было бы платить реальную, но это чисто мое мнение, не связанное с предыдущей частью комментария.
Ну я бы так категорично не высказывался, как мои «братья по разуму».
«Забавно, что в оригинал написал владелец Теслы.»
Вот это как раз не забавно, и очень ожидаемо.
Рассказ получился в стиле: берем особенности Теслы и ее сервиса, которые сейчас у всех на слуху и распиарены и проецируем на автомобили с ДВС. Будущем здесь и не пахнет. Здесь настоящее, причем субъективное, так как сравнение идет Теслы за 80-100 к$ или дешевенького бензинового авто за 20-30 к$. На это и указывают комментаторы к статье.
А статья стала популярной не из-за содержание, а из-за темы «электромобили», которая сейчас у всех на слуху.
Я думаю, что люди негодуют не из-за темы или жанра статьи, а из-за ее содержания.
Способ подачи информации в обоих статьях одинаков, но
приведенная Вами статья написана на 5 с плюсом,
а эта, как по мне, на 3 с минусом.
И переводчик здесь не при чем.
Когда её примут и примут ли её еще неизвестно. Или уже есть какая-то официальная инфа по этому поводу? Уже не слежу за этим вопросом.
А на L1 не каждый согласится: компанию сменить нельзя, green card сложнее получить на сколько я знаю, да и изначально нужно работать в американской компании, имеющей филиал в России. Хотя, возможно я недооцениваю этот вариант.
Все равно количество заявок на h1b сильно превышает квоту (140 000 заявок при квоте 65 000 в 2014 году). В этом году заявок будет еще больше. Так что количество эмигрирующих может и увеличится, но не сильно.
Чтобы увидеть картинку нажмите на иконку в правом верхнем углу -> нажмите Encryption Key снизу.
Индикатором того, что Вы используете секретный чат является замочек возле имени собеседника.
Значит изначально я все-таки вас неправильно понял.
В таком варианте да, нужно проверять на nil.
Получается, target хранится как weak, то есть как Вы хотели — не нужно заботиться о втором пункте.
В теле listener можно спокойно использовать self как unowned, так как механизм гарантирует вызов замыкания только пока self жив.
Ну и потокобезопасность добавить.
Но наличие методов unBind и removeListener я бы все же оставил, так как иногда действительно нужно отписаться где-то в середине жизненного цикла подписчика.
Согласен, это имеет смысл, о таком варианте я не подумал.
В этом то и проблема, yForX не должен быть опциональным, потому что без этого замыкания GraphView не имеет значения, так как она не выполнит своего главного назначения — отобразить график. Указывая здесь optional Вы прячете потенциальный баг в приложении.
Если бы я делал эту фичу с помощью протокола, я бы сделал этот метод @required, в таком случае ошибка не будет запрятана.
То, что в Swift замыкания описываются более лаконично, чем в Objective-C, нельзя считать причиной того, что Objective-C разработчики предпочитают использовать делегирование вместо блоков. Потому что Swift в целом изначально проектировался как лаконичный язык, большое количество возможностей сократить код замыкания в зависимости от условий (наличие аргументов, наличие возвращаемого типа и т.д) хорошо демонстрирует это.
Вы же не скажете, что Objective-C разработчики стараются избегать объявлять свойства в классе, а Swift разработчики обожают это делать, потому что в Swift это выглядит просто и красиво:
Objective C:
Swift:
Пример грубый, но я думаю ясно отражает суть мысли.
Повторюсь, мой изначальный комментарий был не о том, что Swift плохой, а Objective-C хороший или наоборот, а о том, что в Вашей статье неточность:
В Objective-C этот процесс можно сделать таким же простым как и в Swift.
В Objective-C замыкания (блоки) появились 5 лет назад, и с тех пор в iOS SDK делегирование постепенно заменяется на блоки. Не говоря уже про сторонние библиотеки, которые заменили делегирование на замыкания почти для всех основных классов стандартного SDK.
В общем ничего нового, я от своих слов в изначальном комментарии не отказываюсь.
Хотя жена не была так категорична: «Дизайнеры молодцы! А приложений без багов не бывает. Жалко только, что книги все платные :)»
«Живой словарь» — нет ссылки на приложение;
«Смотри+» — нет ссылки на приложение;
«Ренессанс Страхование» — не доступно в американском App Store. Русского аккаунта у меня нет;
«Redigo» — нет ссылки на приложение;
«Бизнес. Книги. 3.0» — на этом и остановились.
Выбор пал на приложение «Газета.ru» (не самый крупный клиент, но и не самый мелкий).
Понадобилось 10 минут, чтобы убедиться, что не все так гладко как на словах.
Вот несколько контраргументов громким словам в статье:
Маркетинг это конечно хорошо, но нужно знать меру.
И раз уж ребята будут разрабатывать реальные компоненты и учавствовать в реальных проектах, то и денюжку можно было бы платить реальную, но это чисто мое мнение, не связанное с предыдущей частью комментария.
«Забавно, что в оригинал написал владелец Теслы.»
Вот это как раз не забавно, и очень ожидаемо.
Рассказ получился в стиле: берем особенности Теслы и ее сервиса, которые сейчас у всех на слуху и распиарены и проецируем на автомобили с ДВС. Будущем здесь и не пахнет. Здесь настоящее, причем субъективное, так как сравнение идет Теслы за 80-100 к$ или дешевенького бензинового авто за 20-30 к$. На это и указывают комментаторы к статье.
А статья стала популярной не из-за содержание, а из-за темы «электромобили», которая сейчас у всех на слуху.
Способ подачи информации в обоих статьях одинаков, но
приведенная Вами статья написана на 5 с плюсом,
а эта, как по мне, на 3 с минусом.
И переводчик здесь не при чем.
А на L1 не каждый согласится: компанию сменить нельзя, green card сложнее получить на сколько я знаю, да и изначально нужно работать в американской компании, имеющей филиал в России. Хотя, возможно я недооцениваю этот вариант.
и
не вижу.
Аргументируйте, и за одно расшифруйте остальные символы в аббревиатуре.
Индикатором того, что Вы используете секретный чат является замочек возле имени собеседника.
В таком варианте да, нужно проверять на nil.
Получается, target хранится как weak, то есть как Вы хотели — не нужно заботиться о втором пункте.
В теле listener можно спокойно использовать self как unowned, так как механизм гарантирует вызов замыкания только пока self жив.
Ну и потокобезопасность добавить.
Но наличие методов unBind и removeListener я бы все же оставил, так как иногда действительно нужно отписаться где-то в середине жизненного цикла подписчика.