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

это чит)

я бы делал на 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