A bit confused here... I have an app with multiple views, and each view needs to share a common GKSession. I would like to implement this with a singleton pattern.
My confusion: should the singleton class be a subclass of GKSession OR rather, should the singleton class be an NSObject which is a GKSessionDelegate? I am inclined to believe the proper pattern is to implement the class as a delegate.
thanks...
Related
I am in the process of creating a UITableViewController sub-class (call it "MyTableViewClass", that would ultimately be sub-classed for specific table view controllers (call it "MySpecificTableViewClass". Ideally I want some methods that are in the MySpecificTableViewClass to be "required" ie. have the developer interface say "implementation is not complete". Is there a way to do that without having to declare in the protocol in MyTableViewClass?
MyTableViewClass.h
#import <UIKit/UIKit.h>
#class MyTableViewClass;
#protocol MyTableViewClassProtocol <NSObject>;
-(void) fooBar;
#end
#interface MyTableViewClass : UITableViewController <NSFetchedResultsControllerDelegate, MyTableViewClassProtocol>
....
This will indicate in my implementation of MyTableViewClass that I have "forgotten" to implement fooBar. I think I can just handle that with a stub method (is that the best way?).
MySpecificTableViewClass.h
....
#import "MyTableViewClass.h"
#interface MySpecificTableViewClass : MyTableViewClass
....
In the implementation of MySpecificTableViewClass - no warning shows that I am missing
-(void) fooBar
If I change MySpecificTableViewClass.h to
....
#import "MyTableViewClass.h"
#interface MySpecificTableViewClass : MyTableViewClass <MyTableViewClassProtocol>
....
Then I do get the warning, but remembering to define the protocol, seems counter intuative, or am I completely missing something?
I haven't found a great way to implement this other than to put in stubs and call NSAssert() in them to catch (at runtime) any unimplemented methods. Objective-C doesn't have the concept of an abstract class.
That said, and while I've used this pattern myself, often it is better to rethink your design and use the Strategy pattern and protocols. That is, instead of having an abstract MyTableViewClass, create a MyTableViewHandler that is a subclass of NSObject and contains whatever special logic you need. Then your table view controllers can be direct subclasses of UITableViewController and delegates of MyTableViewHandler. As a delegate, the protocol can be enforced. And this creates a simpler and more flexible object model. It's not always appropriate, and abstract classes have their place, but do consider the Strategy pattern before you jump to pure inheritance. It often works better.
As MyTableViewClass is already implementing the protocol, its subclasses will get those implementations available for them, It means subclasses are also kind of implementing them. You can change/extend the implementations in your subclasses.
I've been looking at Apple's MVCNetworking example project and part of the interface definition for AppDelegate is puzzling me. In the .h file we have this:
#interface AppDelegate : NSObject
{
...
But in the .m file we have this:
#interface AppDelegate () <SetupViewControllerDelegate>
...
So this class is privately conforming to the protocol. But why would you want to do this instead of publicly declaring it in the header?
In general, you should publicly expose as little as possible. The fact that the AppDelegate can be a SetupViewController's delegate is probably used when the AppDelegate presents a SetupViewController. No other class should be setting the AppDelegate as some other SetupViewController's delegate, so it wouldn't make sense to publicly advertise that conformance.
It looks like the implementation uses a SetupViewController internally in one of its "private" methods presentSetupViewControllerAnimated:. Since the view controller is not publicly accessible (through a property or otherwise), there's no need to declare the class as conforming to the protocol from the public point of view. In other words, the protocol is related only to the implementation of the class, and not to the public interface that it presents.
There are times where you want to be a delegate for another object, but in so doing you may get compiler warnings because you aren't explicitly declaring that your class conforms to the required methods of the protocol. As others have mentioned, one of the pillars of Object Oriented programming is information hiding. It is not desirable to declare in your header that a class implements a particular protocol because you would be breaking that principle. It also opens your class to abuse or to be used in ways it was not intended because it is making that information known to other classes. By declaring a private category in the .m file and letting the compiler know of your intention to implement this protocol, you not only get rid of the warnings that may crop up, but you are, in effect, making your code self-documenting.
Maybe because you don't want anybody to know about your protocol with except yourself. So no somebody externally of AppDelegate will pass instance of Appdelegate as delegate to another class instance. So you will able to pass it as this internally.
I'm learning Objective-C and as I can see, in some tutorials they use Object(imported from objc/Object.h) and in others i see the use of NSObject(imported from Foundation/NSObject.h), but what are the main differences between they?
Regards.
You should ignore Object.
Objective-C allows multiple root classes. Object is a root class that predates NSObject. It's never something you would want to go use. It's only relevant when something somehow already interacts with Object, so you have to deal with it. This is very rare.
Object doesn't implement -retain and -release, for example.
Objective-C is just the language.
The Cocoa frameworks use the NSObject base class as the root class for the hierarchy. Other implementations use their own root classes, in your case the Object class.
NSObject contains all the infrastructure of the Cocoa framework. In other words it conforms to several protocols that Object does not and will respond to certain methods that Object will not. Specifically see NSObject Class Reference and
There are a couple of things about Objective-C that are confusing to me:
Firstly, in the objective-c guide, it is very clear that each class needs to call the init method of its subclass. It's a little bit unclear about whether or not a class that inherits directly from NSObject needs to call its init method. Is this the case? And if so, why is that?
Secondly, in the section about NSObject, there's this warning:
A class that doesn’t need to inherit any special behavior from another class should nevertheless be made a subclass of the NSObject class. Instances of the class must at least have the ability to behave like Objective-C objects at runtime. Inheriting this ability from the NSObject class is much simpler and much more reliable than reinventing it in a new class definition.
Does this mean that I need to specify that all objects inherit from NSObject explicitly? Or is this like Java/Python/C# where all classes are subtypes of NSObject? If not, is there any reason to make a root class other than NSObject?
1) Any time an object is allocated in Objective-C its memory is zeroed out, and must be initialized by a call to init. Subclasses of NSObject may have their own specialized init routines, and at the beginning of such they should call their superclass' init routine something like so:
self = [super init];
The idea being that all init routines eventually trickle up to NSObject's init.
2) You need to be explicit about the inheritance:
#instance myClass : NSObject { /*...*/ } #end
There is no reason to have a root class other than NSObject -- a lot of Objective-C relies heavily on this class, so trying to circumvent it will result in you needlessly shooting yourself in the foot.
Since it is possible to inherit from different root base classes, yes you must explicitly declare you inherit from NSObject when you make any new class (unless of course you are subclassing something else already, which itself in turn probably subclasses NSObject).
Almost never is there a need to make your own base class, nor would it be easy to do so.
Objective-C can have multiple root classes, so you need to be explicit about inheritance. IIRC NSProxy is another root class. You'll likely never want or need to create your own root class, but they do exist.
As for calling NSObject's init, it's part custom and part safety. NSObject's init may not do anything now, that's no guarantee that future behaviour won't change. Call init to be safe.
You need to call [super init] because there is code behind initializing that you dont have to write because it is written for you in NSObjects init, such as probably actual memory allocation etc.
For example:
#interface Fraction: NSObject {
...
When wouldn't NSObject be used and is NSObject the ultimate parent class for all other classes?
Please feel free to correct me on any wrong terminology used.
In any Cocoa app, if you examine the runtime class tree, you will find five root classes: NSObject, Object, NSProxy, NSMessageBuilder, and NSZombie.
Most ordinary objects in your app will be descended from NSObject. Object is the original root class from the early days of Objective-C, and it was superseded by NSObject when NeXT was developing the Enterprise Objects Framework.
NSMessageBuilder is used by the runtime for message forwarding. NSProxy is used by the distributed objects implementation to deal with marshaling messages to send to objects in other processes or even on other hosts. NSZombie is a class that's used for debugging memory leaks.
Cocoa has two root classes: NSObject and NSProxy.
NSObject is the root class of almost all Cocoa objects.
NSProxy is an abstract superclass defining an API for objects that act as stand-ins for other objects or for objects that don’t exist yet, and is the root class for classes like NSDistantObject.
Both classes implement the NSObject protocol.
It is also possible to write your own Objective C classes that do not have a root class, but you would probably never do that, and you would not be able to use it with Cocoa for much of anything unless you also implemented the NSObject protocol, and even then it would be of dubious use.
If I was writing a subclass of NSView, I would write:
#interface Fraction: NSView {...
because my class is inheriting from NSView. Classes in Objective-C inherit from only a single parent class. As you work your way up the chain from NSView (to its parent class, NSResponder), you would find that it eventually inherits from NSObject.
I'm not sure about the second part of your question. I think all classes in Apple's Cocoa Frameworks eventually inherit from NSObject, but don't quote me on that. There's no reason, in Objective-C, why there couldn't be other root objects (otherwise Objective-C would only be used on Apple systems). However, in Cocoa, NSObject is the root.