Как реализовать callback для обновления UI из http-запроса (NSURLSession)?

Question

[Никита Козлов]

Здравствуйте!

Пишу свое первое приложение на objective-c для iOS 7.1. Я, видимо, что-то принципиально не понимаю, поэтому у меня этот вопрос и возник.

Приложение довольно простое: клиент для взаимодействия с внешним сервисом по некому web api. Для отправки http-запросов я использую NSURLSession.
Архитектура у меня простая.

THETALETestViewController - это view controller. Данный класс использует THETALEAPI.h
THETALEAPI - это реализация web api. Я выделил в отдельный класс, чтобы каждый метод внешнего API был реализован в одном месте. Здесь происходит формирование запроса для каждого метода. Данный класс использует THETALEHttpHandler.h.
THETALEHttpHandler - этот класс отвечает непосредственно за отправку http-запроса и прием http-ответа.

Приведу код из THETALEHttpHandler.m для отправки POST - запроса.

-(void) sendPostToURL:(NSURL *)url withParams: (NSString *) inParams competion:(void (^) (NSData *data)) completion{
    NSLog(@"sendPostToURL");
    
    // _csrftoken некий токен в cookie
    NSMutableDictionary *cookieProperties = [NSMutableDictionary dictionary];
    [cookieProperties setObject:@"csrftoken" forKey:NSHTTPCookieName];
    [cookieProperties setObject:_csrftoken forKey:NSHTTPCookieValue];
    
    [cookieProperties setObject:[[NSDate date] dateByAddingTimeInterval:2629743] forKey:NSHTTPCookieExpires];
    
    NSHTTPCookie *cookie = [NSHTTPCookie cookieWithProperties:cookieProperties];
    [_httpCookieStorage setCookie:cookie];
    
    [_sessionConfig setHTTPCookieStorage:_httpCookieStorage];


 // пробовал и так
 // //   NSURLSession *defaultSession = [NSURLSession sessionWithConfiguration: defaultConfigObject delegate: nil //delegateQueue: [NSOperationQueue mainQueue]];   
    NSURLSession *defaultSession = [NSURLSession sessionWithConfiguration:_sessionConfig];
    
    
    NSMutableURLRequest * urlRequest = [NSMutableURLRequest requestWithURL:url];
    
    // _csrftoken некий токен в параметр
    NSString *params = [@[inParams, _csrftoken] componentsJoinedByString:@""];
    
    [urlRequest setHTTPMethod:@"POST"];
    [urlRequest setHTTPBody:[params dataUsingEncoding:NSUTF8StringEncoding]];
   
    NSURLSessionDataTask * dataTask =[defaultSession dataTaskWithRequest:urlRequest
                                                       completionHandler:^(NSData *data, NSURLResponse *response, NSError *error) {
                                                        NSLog(@"Got response %@ with error %@.\n", response, error);
                                                           if(error == nil)
                                                           {
                                                               NSString * text = [[NSString alloc] initWithData: data encoding: NSUTF8StringEncoding];
                                                               NSLog(@"Data = %@",text);
                                                           }
                                                       completion(data);
                                                       }];
    [dataTask resume];
    
}

Так вот, блок completion выполняется не в main thread, а асинхронно, поэтому пока отправляется запрос и идет прием и обработка ответа - main thread выполняется дальше. В принципе, это понятно и логично, но я хочу "логиниться" с помощью данного метода, соответственно, по нажатию на кнопку "Войти" у меня должен отправиться запрос и после успешного ответа и его обработки пользователь должен увидеть ответ. Какими возможностями iOS добиться такого поведения, чтобы main thread ждал завершения выполнения асинхронного блока и выводил соответствующую информацию? Или, может быть, ему не стоить ждать, а просто его как-то нужно оповестить?

Если, конечно, не выносить отдельные классы, а все делать в viewController, то, предполагаю, что подошли бы делегаты, но я хочу внести немного модульности в свое приложение.

Думаю, что данное требование достаточно банально и ответ где-то рядом, прошу объяснить, заранее спасибо!

Answer 1

[kaspartus]

Блок completion нигде не выполняется и никуда не идет, он начинает выполняться, когда запрос выполнился так или иначе. А main thread никого ждать не должен. Просто в нужное время сессия вызовет completion-блок, действительно, не в главном потоке.

Немного советов и схема. Возможно предложу не идеальный вариант.
1. Выпиливаем все до создания сессии в отдельный метод, оно и логично - мы все подготавливаем к дальнейшей работе.
2. Пишем отдельно метод, который создает таск, при помощи которого будем логиниться(то что в вашем методе после создания сессии). Создаем сам таск при помощи метода dataTaskWithRequest:completionHandler:, completion-блок вызовется когда таск выполнится тем или иным образом. Если успех - к п.3
3. Вызываем отдельный метод внутри этого блока, где будем писать дальнейшую логику после логина, туда можно накидать создание других тасков. Метод лучше вызвать в главном потоке, т.к. наверняка захочется что-то сделать с UI.

[self performSelectorOnMainThread:@selector(afterLoginLogicMethod) withObject:nil waitUntilDone:NO];

P.S. По поводу callback'a от тасков
Можно его получать через completion-блоки, а можно через делегатные методы, кому как удобнее.

Comments

[Никита Козлов]

Спасибо за ответ! Кое-что у меня улеглось в голове ровнее после его прочтения.
"completion-блок" - это вы имели ввиду completionHandler ?
Если да, то где мне реализовать метод "afterLoginLogicMethod"? Мой httpHandler не должен ничего знать о смысле запроса, он его просто выполняет. Может отсюда мне лучше делегировать обработку во VIEW путем вызова метода на view controller объекте?

[kaspartus]

Да, потому что это блок, блоки - это замыкания в Objective-C.
Я два раза переписал ответ и лучше теперь понял вопрос :)

Предлагаю такую связку: ViewController(vc) <-> THETALEHttpHandler(handler) все работает на патерне делегат(придется написать protocol для этого)

1. VС создает handler и назначает его делегатом себя. Во время создания отдаем туда все куки, все параметры сессии и прочее.
2. Handler создает сессию в отдельном методе - она одна ведь, а тасков будет много, там юзаем все параметры.
3. VC вызывает метод handler'a для запроса(в первый раз в качестве урла подставляем урл для логина), а другие параметры нам больше не нужны, они лежат в сессии. Сессия создает в этом методе таск и начинаем выполнять.
4. Попали в completion-блок c тем или иным результатом, надо сообщить об этом VC.
5. Вызываем делегатный метод handler'а у VC в главном потоке, в параметрах отдали данные и надо бы урл, по которому стучались.(Тут лучше прочесть один из небольших мануальчиков по тому, как сделать кастомного делегата и свой протокол)
6. В делегатном методе разделяем все по запросам. выделили там логин, выполняем всю логику, VC отдает следующий запрос handler'у, внутри handler'а создаем новый таск, выполняем, результат отправляем в VC через делегатный метод и т.д.

[Никита Козлов]

Спасибо огромное за развернутый и подробный ответ! Поясните, пожалуйста, в п.5 мы вызываем делегатный метод из handler'a, а вызываемый метод принадлежит VC?
Я, в целом, хочу всю логику по обработке ответа и формированию запроса вынести в отдельный класс THETALEAPI, чтобы все, что связано с API было в одном месте, данный класс будет прослойкой между THETALEViewController и httpHandler. Правильно ли я понимаю, что мне нужно будет сделать такую же схему с делегатами, только чуть посложнее?
1. VC создает API и назначает себя его делегатом
2. API создает handler
3. Handler создает сессию в отдельном методе.
4. API вызывает метод Handler'a для запроса
5. Попали в completion-блок c тем или иным результатом, надо сообщить об этом API. Если посмотреть мой код, то там в блоке написано completion(data); так мы сообщим о том, что есть данные.
6. API обработает ответ, распарсит, создаст объекты модели, замапит туда данные
7. API в главном потоке вызовет делегатный метод у VC и передаст туда нужные данные.
8. VC сделает необходимые действия по обновлению UI.

Верно?

[kaspartus]

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

В пункте 5 я по сути описал один из шагов реализации кастомного делегата. Про пункт 5 я специально написал, что надо будет прочесть про патерн делегат в iOS: куча туториалов по запросу "how to create custom delegate in ios" в гугле. Это один из основных патернов, его лучше понимать. В Objective-C интерфейс называется протоколом, это список методов. Есть VC, он реализует некий интерфейс. В частности там будет метод, который будет вызываться, когда таск будет заканчиваться. VC назначаем делегатом тому, кто будет обрабатывать эти запросы. Собственно тот, кто создал таск, узнает о том, что таск закончился в completion блоке, после чего вызовет метод окончания таска у своего делегата(VC в нашем случае). Я вроде расписал, но лучше туториалы посмотреть, чтобы было поянтнее. Но судя по тому, как вы расписали - вы это понимаете :)

Теперь про саму архитектуру.
Так, я себе представлял, что класс API просто генерит урлы и ничего более, и связка только между VC и handler. Как вы расписали - тоже хорошо. Одно но, в вашем п.5, если поставить брейкпоинт в completion блок, то мы увидим, что находимся в потоке, который связан в очередью тасков сессии(это по идее значит что обработка ответа, парсинг и пр. полетит в тот же поток, но лучше проверить), как оттуда выбраться: stackoverflow.com/questions/5662360/gcd-to-perform...

[Никита Козлов]

Я вас понял. Спасибо большое, вы многое расставили в моей голове по местам :) Не перестаю это повторять.
Насколько я понял, вас смутило, что в п.5 обработка логики может попасть в поток сессии и сессия будет висеть очень долго, следовательно может не начаться следующая таска, либо начаться, но будет больше ресурсов кушать. Судя по ссылке, вы советуете логику обработки в модуле API делать в main thread, тогда тред с сессией завершится?

[kaspartus]

@njc Не могу назвать себя про в мультитрединге, в пункте 5 не нравится именно то, что находимся в потоке, где по идее крутятся таски нашей сессии и вызвав делегатный метод класса API, а следом и обработку - мы все это отправим туда же, что вообще говоря может ничем не грозить, а может и грозить. Я бы предпочел выбраться из того потока и хотя бы начать в главном потоке всю логику в классе API. Отдельным моментом скажу, что парсить в главном потоке уж точно не стоит, потому придется все дорогое выкидывать в дургие потоки уже в API.

[Никита Козлов]

@kaspartus спасибо огромнейшее!