Асинхронный по сравнению с Синхронным по сравнению с Поточной обработкой в приложении для iPhone

Я не обесцениваю асинхронные вызовы делегата, но я обычно заканчиваю тем, что использовал потоковый класс рабочего с синхронными запросами. Я нахожу, что легче в конечном счете иметь четко определенный, потоковый API, вместо того, чтобы заполнить Ваш контроллер кодом, управляющим состоянием между асинхронными методами. Вы могли даже сделать асинхронным в Вашем рабочем потоке, хотя обычно легче использовать синхронные методы, если они не поддерживают функцию, необходимо использовать. Конечно, все это зависит от обстоятельств, я могу думать о многих ситуациях, просто использование асинхронных методов было бы оптимальным маршрутом.

Определенно рассматривают NSOperationQueue, если Вы идете этим путем; это значительно упрощает создание нескольких рабочих потоков, и это также поддерживает приоритеты и зависимости между операциями. Прямо сейчас существуют некоторые проблемы с ним на 10,5, но я не услышал ни о каких проблемах о iPhone.

Я лично смотрю на то, что делается, я буду ususally использовать запрос asyc, чтобы гарантировать, что UI не блокирует, однако, меня, МАЙ в ходе того запроса отключает UI моего приложения.

А главный пример этого находится в приложении, которое я создал с "поисковой" кнопкой. Как только поиск был инициирован как асинхронный запрос, я отключу кнопку, пока ответ не возвратился, effectivly ограничение способности к пользователю породить второй запрос asyc.

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

Я рекомендовал бы asychronous путь, никакой вопрос. Затем загрузите информацию только при необходимости и используйте систему делегата для предоставления той информации правильному объекту.

Вы не хотите блокировать UI. Когда-либо. И загрузка информации асинхронно позволяет, Вы лучше управляете по тому, что происходит так, можно подбросить сообщение об ошибке в случае необходимости.

Почему не может Вы использовать асинхронный запрос как так:

- (NSArray *)users {
     if(users == nil && !didLaunchRequestAlready )
        users = do_async_request // Looks good to me
     return users;
 }

Асинхронный абсолютно единственная опция - единственный реальный вопрос состоит в том, если Вы хотите начать использовать отдельные потоки, или если Вы хотите просто использовать асинхронные вызовы. Запустите там и взгляд на управление потоками, если Вы действительно должны.

Официальный ответ состоит в том, что вы должны почти всегда использовать асинхронный режим и что синхронный - это плохо . Я обнаружил, что ASIHTTPRequest упрощает выполнение асинхронных запросов.

Просто мысль: Если вы хотите использовать фреймворк Unit Testing для iPhone, вы возможно захотите иметь синхронную функциональность, поскольку это может облегчить написание тестов.

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

Для этого можно использовать семафор: Ваша функция-обертка запускает асинхронную операцию, а затем использует семафор, чтобы заблокировать себя (т.е. перевести себя в спящий режим). Обратный вызов, сигнализирующий о завершении асинхронного события, освобождает семафор, так что спящий поток обертки может продолжить работу и вернуться.