ios и синхронные запросы

Question

Всюду, включая документацию Apple (sendSynchronousRequest:returningResponse:error), говорится, что она не использует синхронную сеть. Я хочу знать, как вы могли бы решить следующие требования без синхронного вызова:

1. Приложение не требует логина для большинства действий. Некоторые действия требуют, чтобы пользователь вошел в систему.
2. Когда пользователь выбирает действие, требующее, чтобы они вошли в систему, им предоставляется возможность входа в систему. Они нажимают кнопку входа в систему, действие входа аутентифицирует пользователя, а затем делает запрос на получение изображения аватара. Этот логин + выборка действий аватара, не должны ли они быть синхронными? Что нужно, чтобы пользователь продолжал работу с ui, когда им нужно, чтобы они вошли в систему.

Answer 1

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

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

Answer 2

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

Answer 3

Подумайте об этом 2-х типов запросов:

• синхронно:

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

• asynchrounously:

Это выполняет сетевую задачу в фоновом режиме. Это не заморозит ваше приложение. Это означает лучший пользовательский интерфейс. потому что во время выполнения сетевой операции. вы получите возможность обновить интерфейс с помощью «пожалуйста, подождите сообщение».

---

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

• Теперь, чтобы ответить на ваш вопрос, вы должны использовать выполнить запрос сети asynchrounously только потому, что это лучший пользовательский интерфейс.
• Вы не позволяете пользователю перейти на другой экран, вы просто свободны делать другие вещи, выполняя запрос. Это позволяет, например, использовать UIIndicatorView или progressView.

Пользователей потерять терпение быстро они могут подумать, ваше приложение просто slugish/отстающих

Answer 4

Да, Логин и выборка не должны происходить одновременно по отношению друг к другу. Но они должны происходить асинхронно по отношению к основному потоку. Как правило, вы должны инициализировать логин асинхронно, а в блоке завершения (или, если используете сетевой запрос на основе делегата в методе делегирования завершения), убедитесь, что логин был успешным, затем инициируйте дальнейшие сетевые запросы, такие как получение аватар, снова убедившись, что они запускаются асинхронно.

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