StackOverflow2013

Note that there are some explanatory texts on larger screens.

plurals

PO
text
Body
copied!<blockquote> <p>how can I distinguish in the NSURLConnection delegate (connectionDidFinishLoading) which URL call is being made?</p> </blockquote> <p>Each of the delegate methods (such as <code>-connectionDidFinishLoading:</code>) has a <code>connection</code> parameter that tells you which connection sent the message. A given connection can only load one URL at a time, so there's a one to one correspondence between URLs and connections.</p> <blockquote> <p>How can I tell outside of "connectionDidFinishLoading" when the download is completed?</p> </blockquote> <p>That method <em>tells</em> you when the connection is finished. It's up to you to store that information somewhere where it's useful to your app.</p> <p><strong>Update:</strong> Based on what you've added, your "processing" class is your app's model. The rest of the app shouldn't care that each transaction involves a message to the server -- that's the model's business alone. Also, there's no reason that the model has to be a single object (let alone a singleton) -- it can be a group of objects that work together.</p> <p>So, you might have a class (let's call it Processor) that represents the application's interface to the model (some might even call this a "model controller"). An instance of Processor might create a local database for storing the current local state of the app.You might also have a Transaction class that represents a single transaction with the server. A transaction could create a request, send it to the server, get the response, update the database, and tell the Processor that the transaction is done. Or, maybe when some other part of the app (like one of your view controllers) asks the Processor to process a new transaction, the Processor passes the requesting object along to the transaction that it creates so that the transaction can update the requestor directly.</p> <p>It's hard to say what the best plan for your app is without knowing where you're planning on taking it, but the usual guidelines hold:</p> <ul> <li><p>break your problem into parts that are easier to solve</p></li> <li><p>limit the scope of each class's responsibilities</p></li> <li><p>if something seems to complicated, it probably is</p></li> </ul> <p>Breaking your model up into several classes will make it easier to test, as well. You can imagine how easy it would be to write a set of unit tests for the Transaction class. The same goes for Processor -- if the server transaction stuff is in a different class, it's easier to test that the Processor is doing the right thing.</p>

Querying!

Guidance

An individual column

Larger individual text columns get their own page to allow for proper reading.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload