Так ещё Herb Sutter в прошлогоднем (вроде) докладе говорил: «Не использовать shared_ptr для кольцевой, только weak_ptr. Если захватить нечего, то и результат никому не нужен.» Даже с многопоточность такое работает в некоторых случаях.
Про опциональный метод у протокола… Действительно ли нужно переходить в объектам Objective-C ради этого? Может достаточно было бы разделить интерфейсы, а все методы оставить обязательными. Тогда и вызов не должен быть опциональным, а достаточно только разыменовать delegate.
Про пуши, может быть ещё ошибка на сервере, например. Все помнят какой размер могут иметь пши в той или иной версии iOS?
Думаю, что тогда это необходимо явно указать, так как в водит в заблуждение. Создаётся впечатление, что сейчас невозможно поддерживать iOS меньше 8-ой версии, а на самом деле это не так…
При создании проекта необходимо выбрать что мы будем собирать: библиотеку (static library) или фреймворк (dynamic framework). Основное их отличие в том, что фреймворк не совместим с iOS7, а библиотека не поддерживается свифтом.
Мне кажется, что это не совсем правда… Вы хотите сказать, что если я буду писать фреймворк на Objective-C и выставлю Mach-O Type как Static Library, то не смогу этим пользоваться, на iOS 7?
При отрицателной температуре у вас выведется что-то такое: --12.2, то есть два знака "-".
Ещё с сервера приходит ответ в сотых, вот пример ошибки:
если температура 0.01, то на экране выведется +0.0, а судя по коду задумка была в том, что бы при нулевом значении убрать знак. Необходимо округлить, а уже потом сравнивать.
На мой взгляд, при написании клиентских приложений лучше использовать поменьше исключений и ставить просто проверки на ошибки.
Для iOS-разработчиков отсутствие GC не так уж и ужасно.
P.S.: Ну и никто не запрещается отдельные куски писать на Objective-C, C, C++
Ну и это тоже есть, конечно. Просто для каких-то сложных вещей уже не подходит. Например, NSOperation уммеет всякие зависимости выставлять, то есть ожидание завершения какой-то другой операции…
И правда по другому называется у них, просто привык к GOF'у…
Мы же говорим о позиции middle/senior.
А чем реально то они лучше чем GCD или NSOperationQueue вместе с NSOperation? Приходилось ри реально использовать POSIX и как в этом были прюсы? Реально, просто интересно…
Так ещё Herb Sutter в прошлогоднем (вроде) докладе говорил: «Не использовать shared_ptr для кольцевой, только weak_ptr. Если захватить нечего, то и результат никому не нужен.» Даже с многопоточность такое работает в некоторых случаях.
https://youtu.be/xnqTKD8uD64
Ещё похожее это диалоги: dialogflow.com/docs/dialogs
Это когда несколькими запросами необходимо получить определённый надо данных.
И в итоге есть Fulfillment (или Webhook), когда можно с помощью торчащего наружу HTTP метода кастомизировать работу бота.
Про пуши, может быть ещё ошибка на сервере, например. Все помнят какой размер могут иметь пши в той или иной версии iOS?
Мне кажется, что это не совсем правда… Вы хотите сказать, что если я буду писать фреймворк на Objective-C и выставлю Mach-O Type как Static Library, то не смогу этим пользоваться, на iOS 7?
Ещё с сервера приходит ответ в сотых, вот пример ошибки:
если температура 0.01, то на экране выведется +0.0, а судя по коду задумка была в том, что бы при нулевом значении убрать знак. Необходимо округлить, а уже потом сравнивать.
Для iOS-разработчиков отсутствие GC не так уж и ужасно.
P.S.: Ну и никто не запрещается отдельные куски писать на Objective-C, C, C++
Это не конкатинация, конкатинация это
И правда по другому называется у них, просто привык к GOF'у…
А чем реально то они лучше чем GCD или NSOperationQueue вместе с NSOperation? Приходилось ри реально использовать POSIX и как в этом были прюсы? Реально, просто интересно…
1. Запомнить объект и удалить.
2. Запомнить индекс и удалить.
3. Использовать filtered…
4. Сет индексов при удалении нескольких объектов.
Может есть ещё какие, которые необходимо знать?