iOS online API workflow and best practice

Targets iOS
#1

I am currently adapting a desktop & webapp to an iOS App.
Of course, because of the new framework everything has to be written from scratch, but the API used to access the database will still be used.

In the desktop and webapp most API calls were done synchronously so a class function loading and processing some data would basically look like this:

Dim jsResult as JSONItem
Dim processedString  As String

//mySocket is a httpSocket
//the Query function synchronously sends a GET request and returns a JSONItem
jsResult = mySocket.Query("someURL")
//Do something with jsResult
processedString = jsResult.value("something")


jsResult = mySocket.Query("someOtherURL")
//Do something with jsResult
processedString = processedString + jsResult.value("somethingElse")

//End of loading, return the processed String value
Return processedString

Now that xojo.net.HTTPSocket only works asynchronously I have one function to setup all HTTPSocket queries
and use a callback delegate to process each response.

What would be the best practice to wait for all queries to be performed and then return a dictionary or a processed string Value ?

Side note: the downfall of the above code is that it can lock up the Application if the query takes too long.
As soon as the iOS app is ready, the desktop and WebApps will be updated to use asynchronous queries.

#2

The whole point of doing it asynchronously is that you’re not waiting for the response. You’d want to run all of your requests and then fire an event or callback to process the data.

One possibility would be to create a class that is responsible for dealing with the responses from HTTPSocket which knows how many responses it should get and only fires the callback when all sockets have responded. Just keep in mind that this class also needs to be able to deal with error conditions or you may never get the callback if one of the requests fails.

#3

I understand the whole point is to run everything at the same moment. The issue is that upon application initialization (or user login) it must query the API several times, and use some retrieved data to build the next query, and so on.

I started working on a class that expects to receive N responses and only then do the callback to the current view. Thanks for pointing out error handling.

#4