ios and Synchronous Requests

Question

Everywhere including Apple's documentation (sendSynchronousRequest:returningResponse:error) says not to use synchronous networking. I want to know how would you solve the followining requirement without a synchronous call:

1. The app does not require login for most actions. Certain actions require that the user should be logged in.
2. When user chooses an action that requires them to be logged in, they are given a choice to login. They tap the login button, the login action authenticates the user and then makes a request to get their avatar image. This login + fetching avatar actions, shouldn't they be synchronous? Whats the point of letting the user continue with the ui when what they need to do requires them to be logged in.

Answer 1

If you block the UI with synchronous calls, the user may believe that your app has locked up and leave it. Also if there's a synchronous call blocking the main thread at the time you background the app, the OS may kill the app, believing also that it has locked up. In general, the UI should never be frozen up when it doesn't have to, and networking calls should never have to, they should always be executed on background threads. So if you use the synchronous methods, they should be done on background threads.

During the time that you're making network calls, you should display some kind of progress/busy indicator in the app. It is fine if you disable interaction with your UI while this is going on, but the user should be able to see that there's some kind of UI activity, so they know your app isn't frozen.

Answer 2

Some actions do need to be synchronous, that is fine. But when possible it is generally best to perform blocking operation on other than the main thread.

Answer 3

Think about it 2 request types:

• synchronously :

This perform the network operation on the main thread. It could be okay sometimes but remember anything that takes more than a second is too long nowadays. So that would just be a poor experience for the user.

• asynchrounously:

This performs the network task in the background. Which won't freeze your application. Which mean a better user experience. because while performing the network operation. you get the chance to update the interface with a "please wait message".

---

This login + fetching avatar actions, shouldn't they be synchronous? Whats the point of letting the user continue with the ui when what they need to do requires them to be logged in.

• Now to answer your question, you should use perform network request asynchrounously just because it is a better user experience.
• You are not letting the user continue to another screen, you are just free do to other stuff while doing the request. This allows you to for example use a UIIndicatorView or progressView.

Users loose patience quick they might think your app is just slugish/lagging

Answer 4

Yes, the login and fetching should not be happening concurrently with respect to each other. But they should be happening asynchronously with respect to the main thread. So typically you'd initiate the login asynchronously, and in the completion block (or, if using a delegate-based network request, in the completion delegate method) confirm that the login was successful, then initiate any further network requests, such as retrieving the avatar, again making sure that they run asynchronously.

The only time you should contemplate synchronous network requests is when you initiate them in a background queue, thus while they behave synchronously with respect to the background thread, they behave asynchronously with respect to the main thread. But the synchronous network request techniques are inherently limiting (e.g. no cancelation methods, unable to handle authentication challenges, etc.), so many will forgo the synchronous network request technique entirely, using the more robust asynchronous delegate-based network request mechanisms.