1

This is a design pattern question.

Imagine a programming task where one is developing a client that will interact with a server asynchronously (via streams). Let's say the challenge is to execute an indeterminate number of tasks, each of which may spawn an indeterminate number of child tasks (i.e. - crawling a tree). Each task makes an asynchronous request to the server and provides two blocks (one for handling expected return conditions and one for error conditions) to handle response processing.

In a scenario like this, it's easy for me to see how one might queue the outbound requests, but having that queue emptied does not imply that the holistic task is completed as subsequent response processing could queue more outbound requests. The outbound request queue could hit zero multiple times in the course of completing the holistic task.

Under iOS, what kind of options (design patterns and useful classes) might you suggest for determining when the holistic task was truly completed?

Another wrinkle in this is that in error scenarios (for any child task) I am going to want the holistic task (and all child tasks) to be cancelled.

Thanks in advance!

xyzzycoder
  • 1,831
  • 13
  • 19

2 Answers2

1

Queueing the outbound requests has to do with the communication between server and client, it is irrelevant for completion.

Whenever you need a task to be performed, you both send a request for the task and add it to a collection of tasks that are currently pending.

When you receive an answer you process it, eventually generating new tasks, and then remove the task the answer relates to from the collection of pending tasks.

You are done when there are no pending tasks.

Aborting on errors requires explicit support from the server. You need to be able to send an abort request for a pending task and the server must be able to abort that task and acknowledge this fact back to you (or ignore the abort request if, on the server, the task has been already completed and the server already sent you an answer for that task).

When processing an error response you walk the collection of pending tasks sending, for each, an abort request to the server and marking them as cancelled (but leaving them in the pending task collection).

When you receive an answer for a task that is marked as cancelled, you ignore it (and remove the task from the collection), regardless of whether it was a success answer, an error answer or an abort acknowledgment.

Analog File
  • 5,280
  • 20
  • 23
  • Thanks, Analog. This may be the right track. That collection exists now, but I was pulling the "active" interaction from it for processing. Perhaps if I left the active task in the collection until it is truly completed, the problem with the tasks in progress hitting zero goes away. I'll noodle that. Thanks again. – xyzzycoder Aug 09 '12 at 18:46
0

Sorry, may be I don't correct understand you, try ASIHTTPRequest, http://allseeing-i.com/ASIHTTPRequest/ , may be it help you.

frankWhite
  • 1,523
  • 15
  • 21
  • Frank, thanks for the tip. Unfortunately I am working at a lower layer than ASI (directly with NSStreams). Also, are you aware that ASI is no longer being actively maintained (at least that's the last that I had heard). – xyzzycoder Aug 10 '12 at 02:27
  • Frank, I have used ASI on many projects. It worked well for the time, but there are newer, block-based libraries that you may want to consider when you need this kind of capability. – xyzzycoder Aug 10 '12 at 18:28