Question

I’ve been developing an iPhone app, which handed by an experienced developer. I’m just an apprentice programmer and still struggling with practical Objective-C/iOS application development (I have learned Java and PHP on my own, but objective-c is nothing like these to me).

Our app is just another “web-centric” (I don’t even know this word is appropriate…) app which heavily relies on server-side operations, making frequent http post request every single time (such as tracking user locations, send messages to another users etc.).

When I was assigned to develop this app, I saw in the code, that every single http request was written inside each method. Each request was done by dispatching another thread, and each action were written for those requests’ response accordingly.

E.g.

-(void) methodA {  
// Making http request headers...  

// Dispatch another thread  
dispatch_queue_t queue = dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT , 0);  
dispatch_async(queue, ^{  
  // Send synchronous request and handle the response...  
});

}  

-(void) methodB {  
// Making http request headers...  

// Dispatch another thread  
dispatch_queue_t queue = dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT , 0);  
dispatch_async(queue, ^{  
  // Send synchronous request and handle the response...  
});

}  

The codes like above are every where when the app needs to send request to the server.

I’m wondering, why he didn’t create a class that handles http requests.
In Java, you could create a class that make synchronous request to the server:

public class ClassHttpRequest {
     public int makePost {  
        // Send synchronous request and return result...  
     }  
}  

Then make an instance of this class and execute it’s instance method (in this case, makePost) inside a thread:

public class methodA {  

   Thread t = new Thread(new Runnable() {  
         public void run() {   
           public ClassHttpRequest requestHandler = new ClassHttpRequest();  
               if (success == requestHandler.makePost()) {  
                   // Handle response...  
               }  
           }  
         }  
     });

    t.start();  
 }  

Is there any performance penalty or issues in creating a class and let it handles frequent http request in Objective-C? Or, it’s just simply not “recommended” or something? I have heard that, in Objective-C, it is not common to use try-catch statement for exception handling, because it would consume much resources. I do have read several iOS and Objective-C books (and googled), but such kind of “practical” answer for real application development is hard to find, most of the time it’s rather confusing to beginners like me.

I should ask him why he didn’t create a such class, but he’s away now and I couldn’t get in touch with him. Also, I belive that the professionals here in stackoverflow can provide me much more accurate and concise solutions than my predecessor. (I have asked several questions and already got what I wanted to know.)

Thanks in advance.

Answer 1

Normal rules of object-oriented design apply: if it makes sense to represent a HTTP request as a tangible object – in particular, there’s a bunch of boilerplate code that’s necessary and would otherwise be copy-pasted – then it’s probably a good idea to use a class. Otherwise, there’s no need. Though in this specific case, is there a reason you’re not just using the standard, asynchronous system APIs – NSURLRequest, NSURLConnection, NSURLDownload, etc?

@try/@catch are by definition used for exception handling, and should be used as necessary. If you skimp on them your code may fail in unnecessarily interesting ways (e.g. leaving locks dangling) or to unnecessarily degrees (e.g. crashing completely instead of simply failing a specific operation). What you shouldn’t do is use them for flow control – unlike other languages, Objective-C exceptions are for programmer errors, “impossible” conditions, and other such events. Unfortunately a lot of existing Objective-C code is not exception-safe, so while you should utilise them you shouldn’t rely on them.

They’re not particularly expensive in any of the runtimes you’re likely to use these days – the @try is very cheap, almost free. Only if an exception is thrown is there any significant work done, and since you should only be seeing them in very bad situations – i.e. not frequently – the performance cost is irrelevant.