Плюс запрос может просто напросто зафейлиться, значит нужно еще и различать стейты, когда запрос выполняется, а когда он уже выполнен (чтобы при нажатии кнопки знать, нужно ли отправлять запрос заново или нужно ждать) Вариант с флагами вообще адский

Так второй же отправляем уже при нажатии на кнопку?просто один флаг на первый запрос.

Так второй же отправляем уже при нажатии на кнопку?просто один флаг на первый запрос.

второй должен быть отправлен, только если пришел успешный респонз от первого

можно отключить кнопку, пока первый запрос не завершится ?

это чит)

я бы делал на ReactiveCocoa, там вообще без единого флага всё было бы

но боюсь, меня сейчас обвинят в навязчивости)

Через GCD кто-нибудь делал подобное? (dispatch_suspend)

- (BFTask *)request1; - (BFTask *)request2; - (void)viewDidLoad { self.req1 = [self request1]; } - (void)handleClick { __weak weakSelf = self; [self.req1 continueWithSuccessBlock:^id(BFTask *task) { [weakSelf request2]; }]; }

а не проще в NSOperationQueue добавить dependency ? вторая операция зависит от первой

в том смысле, что сформировать queue, поместить туда op1 + op2 (addDependency: op1)

Да проще наверное, но вот решил спросить, делал на практике так кто-нибудь из здесь присутствующих. Мало ли какие подводные камни

в NSOperation никаких подводных камней, можно вручную всё отрегулировать, очередность, зависимости

А если первый запрос зафейлился, операция-то будет считаться выполненной

Ну да, без флагов тут в любом случае не обойтись

так мы всё равно к коллбэку апеллировать должны - что получили в обратку при 1ом запросе, то имеем, нетворкинг ерроры никто не отменял

так а почему нельзя заблочить кнопку то, пока первый запрос не вернулся?

Потому что некрасиво это

Ясное дело, что можно все заблочить, показать спиннер на весь экран и задача решена

о какой красоте речь вообще, если кнопка явно должна слать запрос

просто смысла от кнопы никакого, пока op1 в процессе

а молча не отсылать запрос когда юзер жамкает на нее, потому что не пришло еще ответа - красиво?

я бы просто кнопку задизейблил

можно вместо кнопки активити маленький повесить)

но тоже выглядит странно: загрузилась вьюха, кнопка disabled, чо куда кому - неясно

UI хромает

гипс снимают, юзер уходит

можно вместо кнопки активити маленький повесить)

я тут услышал знакомые слова "активити" говоришь? ?

Пользователь, попадая на экран, видит кнопку Он сразу её жмякает и ждет (ему плевать сколько там запросов) Это лучше, чем он сначала ждет, потом жмякает, потом опять ждет

фидбэк с юзером какой вообще, ну то есть как юзер понимает, что он нажал кнопку и да, "что-то произошло"

?

мож ему картиночку какую анимашку показать, пока op1 отправляет - получает данные?

а то тут вопрос больше не технический по-моему, а к UX

фидбэк с юзером какой вообще, ну то есть как юзер понимает, что он нажал кнопку и да, "что-то произошло"

при нажатии на кнопку появляется спиннер, который крутится, пока выполняется запрос №1 (если он не выполнился еще) и затем запрос номер 2

Ок, ладно, вот рассказываю прямо как есть. Наше приложение рассчитано не под одного клиента, поэтому у нас используются динамические адреса API. Попадая на экран логина, пользователь хочет сразу жмякнуть кнопку входа, а не ждать, пока подгрузятся url ки.

Прятать куда-то, дисейблить эту кнопку не вариант

Раньше у нас была загрузка перед переходом на экран авторизации, но такой вариант, ясное дело, никому не нравится

я бы предложил вернуться к очереди, как предлагали, а если фейлится интернет, то показывать алерт с ним — так сразу будет понятно, что кина не будет. а если с интернетом все ок, то и с очередью будет все ок.

так а какая разница, если у вас все равно кнопка неработает, пока первый запрос не завершится?

буду я теребить эту кнопку, пока там запрос придет первый

толку мне?

никакого отклика от UI

Можно, коненчо, начать выполнять запрос №1 после нажатия кнопки, а затем в коллбеке запрос №2, но в таком случае пользователь будет дольше ждать

не понятно, толи она просто не работает

так ты теребить будешь и пока второй вопрос будет обрабатываться, это уже другая задача, на мой взгляд

никакого отклика от UI

так я же написал, что после нажатия на кнопку на её месте появлятся спиннер

*запрос

так а какая разница, если у вас все равно кнопка неработает, пока первый запрос не завершится?

типа ты зашел на экран, и загрузка автоматически началась, а когда ты нажимаешь кнопку, появляется спиннер на весь экран, который ждет пока завершится первая операция и не убирая спиннера начинает вторую

то есть отклик есть

А что будете делать, если первый запрос в фоне зафейлился?

+

зафейлиться он может только если интернет упадет

А что будете делать, если первый запрос в фоне зафейлился?

Ничего, будем повтороно отправлять при нажатии на кнопку Если он там зафейлится, то будем показывать ошибку

ну вот он взял и упал

ну вот на алерт

в сафари если нет интернета то большая надпись висит что нет интернета

ну вот если твой экран - 2 кнопки и 2 запроса, зачем тебе туда тащить реактивку?

чем плохи 2 флага?

Запрос упал, был отправлен при входе на экран – не будет алерта Запрос упал, был отправлен при нажатии на кнопку – будет алерт

если у тебя все приложение повязано на реактивку - добавить реактивку и сюда

если дальше ожидаются такие же проблемы - взять реактивку

или накидать свою асинхронную операцию с композицией

и использовать их

дело говорит

Из вышеизложенного можно выделить 4 варианта: флаги, nsoperationqueue, bolts, reactive Спасибо

https://gist.github.com/maximgavrilov/a4f2233d4f134feb92ff286833af9c97

https://gist.github.com/maximgavrilov/a4f2233d4f134feb92ff286833af9c97

Я как раз пока склоняюсь к Bolts, так что обязательно гляну, спасибо

Ну, реактивка тут выглядит слишком перегруженно, это всё-таки классическая задача на promise, если хочется чего-то большего, чем флаги

имхо тут хватило бы флагов

оверинжинеринг какой-то на ровном месте иначе

тут всё-таки таски и dependency, или NSOp, или Bolts - удобно

Ребята, подскажите. Можно ли создать приватный framework с закрытым кодом, в котором используются зависимости в виде pods?

я фреймворки не создавал, но использую один приватный с закрытым кодом, он использует разные открытые библиотеки и требует их подключение в любом удобном виде

А как он создавался?

а вот это не знаю — он совсем чужой

а, сори, ввёл немного в заблуждение. на самом деле он не дистрибьютится как цельный фреймворк

Супер https://developer.apple.com/news/?id=08082016a

Если есть ограниченное число запросов, которые надо выполнить последовательно (наример 2-3), я обычно обработку делаю в блоках и просто делаю вложенный запрос в блоке, т.е. первый_запрос:^(){ обработка_результатов_первого запроса; второй_запрос:^(){ обработка_общего_результата; } } Ну можно конечно через RAC компоновать, удобно, когда сложные интерфейсы.

Супер https://developer.apple.com/news/?id=08082016a

?? Прогресс не стоит на месте %))

Подскажите, что можно использовать что-то типа IMEI, чтобы привязать к девайсу аккаунт, но при этом его пропустили в ходе ревью

генерируешь рандомный UDID и сохраняешь в кейчейн

NSUUID

identifier for vendor

Подскажите, через что можно дистрибьютировать Watch приложение? (кроме TestFlight)

Fabric.io

Подскажите, через что можно дистрибьютировать Watch приложение? (кроме TestFlight)

hockeyapp

Fabric.io

А лично пробовал? (именно Watch) Терзают смутные сомнения

А чет про часы упустил. Часы не пробовал.

Приложения для часов никак не отличаются от приложений для iPhone

Можете хоть в Dropbox .ipa файл выкладывать

Можете хоть в Dropbox .ipa файл выкладывать

Спасибо конечно, но хочется что-то удобное наподобии Fabric Погуглив, я не нашел свидетельств того факта, что Fabric поддерживает Watch

Спасибо конечно, но хочется что-то удобное наподобии Fabric Погуглив, я не нашел свидетельств того факта, что Fabric поддерживает Watch

немного не понял - как это "поддерживает" ? Всмысле статистика крашей?

Поддержка Watch не требуется, бандл для часов зашивается в .ipa файл. Мы распространяли приложения для часов как через TF, так и через Fabric, Diawi и так далее

Крашей на часах вообще нигде не увидите - такого просто не придумали еще

Хотя я могу ошибаться, давно это было)

Только я хотел написать "Круто, буду пробовать")