CODEWITHSUNDEEP
objective-carchitecture
thekevinscott
thekevinscott

Reputation: 5413

Obj-C iPhone architecture regarding instantiation of classes

I have a noob question regarding how to architect my iPhone app.

I have two main components, a map and an audio player, both self contained classes (MapController and AudioController). I read this great article and am trying to apply it to my app:

http://blog.shinetech.com/2011/06/14/delegation-notification-and-observation/

I have a third class, WebServices, that handles uploading POST data to my server as well as making queries to external API's.

My question:

  1. Do I import header files, and create a new instance of WebServices in both the map controller, and the audio player? And then each controller can reference it's own WebServices for queries?
  2. Or, should I create one WebServices instance on the RootController, and then pass this to the map and audio controllers on init?

In particular, I'm interested in which approach consumes memory more efficiently. Or if it doesn't matter at all.

Thanks!

Upvotes: 2

Views: 120

Answers (3)

justin
justin

Reputation: 104698

Point Zero

Do not resort to singletons, and especially not in multithreaded contexts. You can search this site if you need explanations (hint: the reasons against them are quite similar in OO languages similar to ObjC. e.g. C++, Java, C#...).

To share, or not?

It ultimately depends on the behavior your design needs, but I favor Option #1 as the default.

  • If you need multiple instances, do not be afraid create multiple (unless you have a really, really, really good reason not to).
  • If they are heavy to construct, consider what immutable data they can share.
  • Favor smaller, specialized objects (WebServices may be huge). Smaller objects allow more flexibility and reduce the chances that your program will compete for resources.
  • What will you gain in this case by sharing? Often, this just increases runtime and implementation complexity... but there can be gains. Without identifying those gains, you should stick to multiple instances to reduce complexity.
  • Multiple instances allow your program to perform multiple asynchronous requests, based on what they need. Multiple async requests is fine (but it will obviously be slow if you have too many active requests).
  • Most programs are more logical and easy to maintain when the objects they depend on allow multiple instances (they do not enforce sharing).

Assume multiple instances (1) until have identified a problem. Even after the problem is identified, you can usually avoid sharing.

To determine which consumes less memory requires much more information. If the objects you are considering sharing are not huge (very unlikely), they themselves are not problems wrt memory consumption.

Either approach proposed can result in more memory consumption - it depends entirely on the context and execution. We'll need some more information to answer this specifically.

This is not to imply that sharing is bad, but sharing usually complicates things because you need to design objects to behave predictably when shared (especially since you are operating in a multithreaded context).

Ask yourself:

  • What significant benefit(s) would sharing WebServices provide?
  • How would sharing WebServices improve your program and reduce complexity?

It's likely the case that the WebServices map stuff does not interact with the audio stuff. In that case, WebServices may be a good candidate for a base class, where the audio and map services are separate subclasses (assuming the WebServices class is already complex).

Upvotes: 0

Kenny Winker
Kenny Winker

Reputation: 12107

I would suggest an NSOperationQueue with a number of NSOperations, instead of a WebServices singleton.

Look at this sweet example from Apple where they do this for concurrent image-downloading. It's a Mac example, but all the classes shown are available on iOS. They use NSInvocationOperation, but you can use an NSOperation subclass, or an NSBlockOperation for cleaner code.

You can add these from anywhere to a single queue, by calling [NSOperationQueue mainQueue]; to fetch the main queue singleton. The singleton's job, in this case, is only to manage the queue (so not too many downloads happen at once), not to do any data processing (that's all handled by your NSOperation).

Upvotes: 0

James Webster
James Webster

Reputation: 32066

Consider creating a singleton for your WebServices class and use a shared instance. It seems this is the design pattern you require here.

With regard to the efficiency part of the question, the second option is more efficient purely because you're not storing as much data in RAM. The difference however, assuming your classes are not storing too much internally, is likely to be unnoticable. 

@interface WebServices: NSObject
{
}

+ (WebServices*)sharedInstance;
@end

static WebServices *sharedInstance;
@implementation WebSerivces

+ (WebServices*)sharedInstance
{

  @synchronized(self)
  {
    if (!sharedInstance)
      sharedInstance = [[WebServices alloc] init];

    return sharedInstance;
  }
}

@end

Upvotes: 2

Related Questions