Как стать автором
Обновить

Комментарии 49

НЛО прилетело и опубликовало эту надпись здесь
Не поддерживается, но крайне популярна. Да и я там написал про AFNetworking как рекомендованную автором замену
это кто вам сказал, что она «крайне» популярна?
Вы бы сначала проверили адекватность ваших рекомендаций.
Например ASIHTTPRequest вообще нет смысла сейчас ипользовать. Он был полезен, пока не появились блоки. А это значит что его следует использовать для поддержки iOS3. Кто сейчас его поддерживает?
Просто набор вот фреймворков бесполезен. Полезной информацией было бы их описание и технический анализ. А так список посмотреть можно и на cocoacontrols.
Вы правы, но ASIHTTPRequest блоки поддерживает
Вы не поняли, смысл в том что ASI не поддерживает блоки, смысл в том, что GCD убил весь смысл существования ASI, именно поэтому его и перестали поддерживать. GCD работает на системном уровне а вся логика ASI реализована на высоком уровне, да еще с большим количеством ошибок и недочетов.
Ладно вам, до Xcode 4.5 люди прекрасно собирали под ios 3. Да и я просто люблю ASIHTTPRequest, простите мою слабость
тут просто вопрос в том, зачем поддерживать iOS3? Если это коммерческий проект — это не нужно. Причин очень много. Но поддержка 3 версии «отбирает» очень много вкусных вещей: GCD, блоки, Gesture Recognisers…
Если for fun, то вопрос совсем другой.
Блоки, кстати говоря, в iOS 3.x работают, но надо компилировать с base sdk > 4 и deployment sdk 3.x.
Правда при этом остаётся только поддержка блоков компилятором, но не SDK. Проверял на 3.1.3 — работало.
ну это понятно, смысл то в llvm. Но мы говорим об ASI, а актуальность ASI пропала с появлением GCD.
Просто понимаете… на 3.1.3 я не просто так проверял :) Мой (прошлый) работодатель поддерживал 3.1.x, и это смог изменить только выход айпада. Теперь они поддерживают 3.1.3 на айфоне и 3.2 на айпаде…
Поясните, пожалуйста, почему актуальность ASIHTTPRequest пропала именно с появлением GCD.
Основная задача, которую решает вся эта конструкция — это очередь асинхронных запросов. Конечно в итоге это разрослось в кучу разных вспомогательных методов. С появлением GCD эту очередь очень просто и быстро стало возможным организовать с помощью dispatch_queue. Причем количество кода уменьшилось просто в десятки раз, вопросы синхронизации и блокировки отпали сами (в ASI для этого использовались достаточно сложные механизмы).
Теперь для решения практически всех задач, для которых была создана эта библиотека, сгодится и набор системных фреймворков. И это будет проще, надежней и быстрее.
Допустим.
Но, во-первых, ASIHTTPRequest работала с блоками, если мне изменяет память. Автор молодец, что их поддержал как только они появились.

Во-вторых, не думаю, что performSelector:onThread:withObject: так уж сильно скажется на количестве кода и на его качетсве по сравнению в выделенной очередью. Так создавали созданный поток, который будет «спать» при отсутствии сетевой активности.
* создавали отдельный поток
а как вы будете синхронизировать, задавать приоритеты, выстраивать очереди из
performSelector:onThread:withObject:
Я боюсь на этот код смотреть.
Как именно я? Если вдруг мне надо будет писать такой код, то легко и понятно, разумеется :) Вроде, с performSelector:onThread:withObject: нет проблем: вызвали и ждите его выполнения на другом потоке. Там еще есть параметр " waitUntilDone: ".

Принципиально с появлением блоков ничего не поменялось. Ну, принципиально. Если это для кого-то стало серебряной пулей, то это здорово.

Да и есть прекрасные NSOperationQueue/NSOperation. Там и приоритеты есть.
Да и у потоков приоретит задается.
Да я не хочу вас ни в чем убеждать, если вы не хотите разбираться и для себя самого, уяснить зачем появился GCD и как он вам поможет в решении задач и облегчит жизнь, то почему это должен делать я?
До GCD пользоваться потоками конечно-же можно было. Я об этом не спорю, я говорю о разнице использования старого и нового подхода. Вот и все.
Так я ведь не спорю о том, зачем они нужны. Я ведь про другое толкую.

Меня просто смутила ваша категоричность в том, что AHIHTTPRequest был убит именно GCD и его «системным уровнем».
Это не моя категоричность, это факт да еще и было написано в прощальном послании. А «системный уровень» GCD — это я приводил как аргумент того, что GCD — это эффективная технология разработки многопоточных приложений, а не как убийственный фактор ASI.
Я прочитал будто ASI был убит именно GCD, и именно его системным уровнем. Мир-дружба!
АААА ну тогда мы говорили ни о чем :-) Жвачка :-)
Что значит «Системный уровень»? Что именно из системного уровня GCD погубило ASIHTTPRequest?

Сам я его не использую, просто интересно выслушать вашу точку зрения более аргументировано.
То что механизм GCD поддерживается на уровне ядра, а механизмы синхронизации и многопоточности ASI были реализованы на уровне кода приложения. Подробней я объяснил тут.
подождите, вы пишете на iOS и не пользуетесь GCD?
Я не поверю что все что вы пишете — однопоточные приложения.
И правильно, что не верите. Я не писал такое подобное.

> Сам я его не использую, просто интересно выслушать вашу точку зрения более аргументировано.
Я считаю, что блоки — великое благо. Просто ASIHTTRequest была крутой библитекой своего времени. До сих пор начинают проекты именно на ней (уж не будем судить таких людей, но они есть и это о чем-то да говорит).
Извините, если я вас обижу, но то что вы до сих пор пользуетесь ASIHTTRequest говорит о вашей профессиональной отсталости. Это всего лишь мое личное мнение и раздувать из этого дебатов я не хочу. Просто воспользовался своим правом высказать свое мнение.
А по поводу того, что такие люди есть, так я часто встречаюсь с чужими проектами. И очень плачевно, что 9 из 10 — полный шлак, от которого хочется выть на луну. Увы, хороших iOS разработчиков у нас очень мало, а iOS разработчиков вообще очень много. Отсюда и такая статистика. И это при том, что я абсолютно не критичен к коду и архитектуре и готов принять очень смелые решения. Но одно дело — когда это решение, пусть даже не стандартное, а другое дело, когда это куча мусора, построенного по принципу «лишь бы работало».
Три раза уже написал.
да, извиняюсь, я подумал вы имеете ввиду что GCD не пользуетесь.
Ох, как же ты прав, как же ты прав.
AHIHTTPRequest достойный пример проекта. Он дал жизнь многим подражателям и сумел с достоинством отдать свои лидирующие позиции, рекомандовав замены. И до сих пор работает без нареканий
Что-то вы перебарщиваете со значимостью ASI. Да он помогал многим экономить время, но «толпы подражателей» не было (можете меня поправить, указав на эту самую толпу). То что All-Seeing отказались от поддержки, я бы не назвал «достойно отдать свои лидирующие позиции». Это просто разумный ход забросить морально устаревший код и направить свои силы в более перспективных направлениях.
То что он работает и сейчас — это логично, код не тухнет. А вот если у вас к нему нет нареканий — это не значит что у него нет проблем. Я лично поправил больше 20 ошибок. Основной проблемой этого проекта была сильно раздутая база кода и изначально не просчитанная архитектура для такого масштаба.

Но это был бесспорно неплохой проект, и главное его достоинство — это его open-source'ность, что его и сделало популярным.

Во втором предложении должно быть "пАленые библиотеки" или "полезные библиотеки"?
Далее в Работа с изображениями про GPUImage должно быть "нАдавленого" или «недавнего » конкурса?
Спасибо, исправил
ASIHTTPRequest — это вы зря.
Приятно быть в списке ^_^
НЛО прилетело и опубликовало эту надпись здесь
Monaco, я полагаю
NLCoreData я бы убрал, поскольку он работает с тредами, но не с рекомендованным GCD. И вообще, обертки делают CoreData менее настраиваемым, а в результате менее полезным.
Тоже голосую за MagicalRecord, превосходная библиотека для Core Data, использую почти в каждом проекте.
Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.