Using NSOperation for threading creates too many objects

Question

I have an app that makes SOAP calls. To keep the UI from blocking, we are putting each SOAP call into a subclass of NSOperation. This works well, but we have a ton of different types of SOAP calls. So if we use 3 WSDLs each with 10 Ports or Operations, then we 30 different calls in SOAP and if we put each of those in a thread using NSOperation, we end up with 30 NSOperation subclasses.

This may not be a bad thing, but we are trying to create a reusable library, so we have one object per WSDL which encapsulates the calls. This is nice because we are using WSDL2ObjC and this encapsulates all that logic. But it seems odd then to have a nice api that we wrap calls to in these many NSOperations. Also, we are doing the threading in the api itself, so that the invoker can use it how he/she sees fit.

Any suggestions would be great.

Answer 1

If I'm understanding you correctly you already have objects that encapsulate the calls to the SOAP service and you just want to cut down on the NSOperation subclasses.

Have you checked into NSInvocationOperation? It's a subclass of NSOperation that let's you make a message send to an object as an NSOperation call. So you still getting the non blocking operation, but you don't need multiple subclasses of NSOperation.