I need to write some methods in a non ARC project in Xcode. I have to implement a NSXMutableDictionary class, a mutable dictionary that can contain up to four key-value pairs. The methods I have to implement are following:
- (void)setObject:(NSObject *)theObject forKey:(NSObject *)theKey;
- (void)removeObjectForKey:(NSObject *)theKey;
I have no clue how to do it, any help would be highly appreciated.
Thanks.
It's not a lot to go on.
But with what you provided, it's best to subclass NSObject and have a private property that is an NSMutableDictionary.
That allows you to implement all of the same methods of NSMutableDictionary just by declaring them, then in your implementation of each you just call the same method on your actual dictionary property.
The difference you add is a check to see if you already have 4 KVPs or not. And any additional methods you need or want.
This is the design pattern of Composition.
I agree with #uchuugaka. Create an object that has an NSMutableDictionary inside it. (This is a "has-a" relationship rather than an "is-a" relationship)
The NSDictionary family is what's known as a "class cluster". A class cluster is a public interface that's actually implemented by a set of private classes that you don't see.
Subclassing a class that is part of a class cluster is tricky, and not for beginners. There are a whole set of primitive methods you have to implement in order to create a subclass of a class cluster. Plus, your custom subclass will likely not preform as well as the original class because you won't adapt to different use-cases like the class cluster does.
Related
Im trying to understand the high level implementation of protocols without delegates in Apple frameworks. When a subClass conforms to and implements a protocol method, how is that method called? Lets consider the NSCoder protocol methods (encodeWithCoder: and initWithCoder:) for instance.
Without delegates, could you provide any uses cases for protocols (other than achieving polymorphism? I see that some methods could be abstracted away from base classes and grouped into an interfaces but without any implementation (as mixins for instance), what is the significant use?
First, protocol methods are not special in any way. They, like every other Objective-C method, gets called by a message sent to an object. There's nothing special about that part of things. Protocols are basically just a hint to the compiler, though you can query whether an object conforms to one at runtime and make decisions based on that.
You can verify this by implementing a protocol method (or the entire protocol) without declaring that fact in a classes' interface, and call the function on an instance of that object after casting it to be id<YourProtocol>, and it will work.
You can (and sometimes should) call NSCoding methods yourself -- you may decide that you want to persist objects to the disk, and that this is the best way to do it.
NSCoding is actually a great example of why protocols are still useful even though they do not provide any implementation -- the implementation of initWithCoder: and encodeWithCoder: will be different for every class that implements them -- there is no sense in providing an implementation.
Building on that, consider the datasource property of a UICollectionView; as there is no multiple inheritance in Objective-C, it would be undesirable for the datasource to be a class itself, as that would prevent you from using a UIViewController as the data source, and force you to make a whole new class for that express purpose.
Protocols can also be used to implement multiple inheritance in a type safe way without redeclaring the interface of the giver in the inheritor. If the entire interface of the class being inherited from is a protocol, then the inheritor can simply conform to that protocol as well.
Objective-C does provide mixins in the form of Categories, which can implement protocols on existing classes.
For a full throated defense of protocols (in Swift), see the Protocol-Oriented Programming WWWDC 2015 talk.
Taking the example of the NSCoding Protocol, the two required methods in the protocol, basically implement the steps an object should perform to encode itself to be archived. It also implements the initWithCoder to recreate the object from the archive.
Lets say you create a custom object, only your object knows which properties it needs to archive.
When you call a method to archive your custom object, the method call ultimately flow to your encodeWithCoder or initWithCoder to take action specific to your class.
***** Updated ****
Looking at this with an example :
Lets say our data structure looks like this
someArray = [String,CustomObject,aDictionary]
When we want to archive someArray, we call the archiveRootObject method on it. Now inorder for someArray to archive itself, it needs all its contained items to inturn archive themselves. The Array simply instructs the sub items to archiver themselves calling the encodeWithCoder method on them.
By adopting and conforming to the NSCoding protocol, you are just confirming to the root array that Yes, I know how to archive and unarchive myself.
Hope this helps.
I was looking at the Map Kit Framework documentation and it got me wondering why some classes are referred as objects. I know his may be a lack of knowledge on OOP in general but I need to ask.
For instance, this is how they are describing the MKDirections class in the MapKit Framework Reference.
An MKDirections object provides you with route-based directions data from Apple servers.
And this is how they describe the MKDirectionsRequest class.
The MKDirectionsRequest class is used by apps that work with turn-based directions.
Is there a reason why they couldn’t describe the MKDirections class in a similar fasion as the MKDirectionsRequest class? In other words something like...
The MKDirections class is used to provide you with route-based directions data from Apple servers.
My main confusion comes because I was under the impression that you create an object as soon as you instantiate a class. In other words we know that an object will be created when using the MKDirections class so, why not call it class.
Sorry if my question doesn't make any sense but I’m curious if there is something I should be aware when reading the documentation and I come across these two different references, is there something special on the classes they describe as objects?
Thanks
So in OOP classes are objects. The class objects are like blueprints, or printing plates, for instance objects which are created in the run of the program and actually perform the methods which are called. When a program loads, all of the class objects are initialized from the NSObject inheritance as a framework, which then allows you to create instance objects of all the basic types (or custom types if they're loading) during the run of the program. So the class objects are templates. But in filling out, say, a paper form, you don't want to fill out the template itself, you create a copy of it which you then fill out, leaving the template itself unchanged and available for further copying. This is the essential distinction between a class object and an instance of that object.
The difference between MKDirections and MKDirectionsRequest has to do with object inheritance. MKDirectionsRequest is what's called a subclass of MKDirections. The subclass object and its instances contains all of the properties and can perform all of the methods of its superclass, but can perform additional methods or properties outlined in its class profile. So an MKDirectionsRequest instance object is of the class MKDirectionsRequest which inherits from the MKDirections class.
Matt Neuberg's Programming iOS 6 is available for free online (since it's outdated), but his early chapters on C-language inheritance and OOP orientation are still valid and very helpful. Here's a link to the section on Classes and Instances:
http://www.apeth.com/iOSBook/ch02.html#_classes_and_instances
You're right that the object is created by instantiating the class. Maybe the distinction is due to the fact that the MKDirectionsRequest class has a class method isDirectionsRequestURL:. MKDirections only has instance methods.
One possible reason for the difference -- and I'm stretching here -- is that one of those classes has a class method while the other only has object/instance methods. It is possible to use a MKDirectionsRequest class without creating an instance. (+ (BOOL)isDirectionsRequestURL:(NSURL *)url)
It's more likely, though, to be a style difference. If you assume that apps usually use classes by creating an instance of them first, the "class" description is functionally equivalent to the "object" one.
I've read more than once that the Delegate Pattern used in Cocoa is an implementation of the Adaptern Pattern (http://en.wikipedia.org/wiki/Adapter_pattern).
They share the same intent, which is: let two objects with incompatible interfaces to work with each other.
The delegate object is the Adapter, because it adopts a protocol required by a client, the class that requires the protocol and has a weak reference to a delegate is the Client (so, this would be a class of the Cocoa framework).
My question is: who is the Adaptee? The delegate pattern doesn't wrap itself around any object, from what I've seen, who is the object that needs to be adapted?
Delegates are not really an example of the Adapter pattern. Protocols would be closer, but the best way to implement the Adapter pattern in Objective C is to create a new object that contains the object you want to adapt and uses it to serve a client.
Categories are another way of implementing the Adapter pattern, but they have some limitations. You can't override the implementation of existing methods in a category, and you can't add additional instance variables to a class with a category. However you can implement properties using associated objects and you can also add new instance methods.
You can also use multiple inheritance to implement the Adapter pattern in languages like C++ that offer it, but Objective-C does not support multiple inheritance.
A simple example of an Adapter using a category that I use in my projects is as follows:
Interface Builder (IB) includes a feature called "User Defined Runtime Attributes" that lets you set properties on your custom interface objects using Key Value Coding (KVC). It lets you specify a limited number of data types (ints, floats, bools, points, rects, UIColors, and a few others.)
You can use User Defined Runtime Attributes to set the border width and corner radius on a view's layer, and you SHOULD be able to use it to change the layer's border color or background color. However, layer colors are specified as CGColors, and UIViews use UIColors. Since IB only accepts UIColors in a User Defined Runtime Attribute, it doesn't work.
To fix this, I created a category of CALayer called CALayer+setUIColor. It has 2 methods, setBorderUIColor and setBackgroundUIColor. Those methods are very simple. They take UIColors as input, and simply convert the UIColor to a CGColor and set the layer's border color or background color.
You can see an early version of this category in my github project KeyframeViewAnimations.
I'd say that is a completely wrong view of the Cocoa delegate pattern.
The object needing a delegate is intentionally left incomplete. But instead of having an abstract class and adding the required functionality through subclassing, we add the required functionality by providing another object, the delegate.
Nowadays people will more and more switch from using delegate objects to providing the required functionality by passing one or more blocks instead.
I've found a solution in the official documentation, as I suspected there is no adaptee:
https://developer.apple.com/legacy/library/documentation/Cocoa/Conceptual/CocoaFundamentals/CocoaDesignPatterns/CocoaDesignPatterns.html#//apple_ref/doc/uid/TP40002974-CH6-SW5
Delegation is not a strict implementation of the Decorator pattern.
The host (delegating) object does not wrap an instance of the class it
wants to extend; indeed, it’s the other way around, in that the
delegate is specializing the behavior of the delegating framework
class. There is no sharing of interface either, other than the
delegation methods declared by the framework class.
Delegation in Cocoa is also part of the Template Method pattern
(Template Method).
Source: https://developer.apple.com/library/archive/documentation/Cocoa/Conceptual/CocoaFundamentals/CocoaDesignPatterns/CocoaDesignPatterns.html#//apple_ref/doc/uid/TP40002974-CH6-SW19
The DELEGATE object is Adapter because:
It uses special protocol of special object and wrap it to itself special protocol.
I understand how to use NSCoding to convert my objects to archive objects. That's not my question.
What I'm wondering is why there isn't a default implementation of NSCoding that could handle probably 99% of cases.
For instance, every time I write a custom class that I want to archive, I perform the following:
Implement -(void)encodeWithCoder: and -(id)initWithCoder:.
Go down my property list, writing a pair of statements (one encode, one decode) for each property.
If the property is an object, I use the encode/decodeObject method.
If the property is a value, I use the corresponding encode/decode method.
I always use the property's name as my key.
I would suspect that almost every implementation of NSCoding is exactly like mine, with the only changes being the particular properties that need to be manipulated.
It seems to me that this would be a perfect place for a standard implementation, with the option to override if your particular case if funky.
Do I have a misunderstanding of what's going on? If not, could I add a category on NSObject to implement this common method on all objects in my projects?
I suspect that the answer to your question is simply that NSCoding was designed long before Objective-C properties existed. (NSCoding was part of the OpenStep spec in 1994, whereas properties arrived with Objective-C 2.0 in 2007.) Additionally, some classes have properties that are not appropriate to be serialized for later.
However, your proposed solution could be a great time-saver! At least one such solution already exists. Check out AutoCoding.
I have class called ViewController. How to make this class is a sub-class of "metaiosdkViewController" and "JWslideViewController". Help me with syntax.
i have written like this
#interface ViewController : MetaioSDKViewController,JWslideViewController
but this giving me error
objective-c doesn't support multiple inheritance,but if you want to add some extra behaviour you can achieve it through delegates..
yes objective-c doesnt support multiple inheritance but you can give one parent so
#interface ViewController : MetaioSDKViewController
and
#interface MetaioSDKViewController : JWslideViewController
this is just an idea I know you can implement well as per your need
What is it that you want to achieve with multiple inheritance?
Do you want to override methods from each of these super classes?
Note that objective c provides 2 mechanisms for extensibility:
1) Implementing a Protocol and make your object the delegate:
#interface ViewController : <MetaioSDKViewController,JWslideViewController>
This enforces ViewController to implement certain methods as defined in contract by 2 delegates, and at some point in processing, they get called. If you don't implement them, they may simply not be called but you may not get desired functionality.
Example: UITableViewDataSource protocol that defines many methods that UITableViewController subclass implements. cellForRowAtindexPath is very famous example of a delegate method that your own table view subclass must implement to draw your own custom cells.
Note that this is not the type of extensibility that subclasses provide in general sense. Your class does not extend any functionality here. Rather it becomes what it says - a delegate - someone who is assigned to do some task. Like you do:
yourTableView.delegate = self; //tell self to be the delegate of yourTableview
Library code does it's stuff and in some point in processing it calls [delegate someMethod]. If your own class implements it, it calls it, otherwise delegate will be nil, and it may just be NO-OP and you don't get desired functionality. Again, this is implementation-dependent. Maybe the protocol defines that the method is compulsory, in which case your class MUST implement this method in order to compile.
2) Implement a category:
This is sort of a shortcut way to extend library classes. They act like an extra stub which, when your code runs, attaches itself to the already existing memory layout of the library objects and provides extra functionality.
You can define a category on any of the in-built classes as well. In fact that is the primary objective it is used for. For example, here is an NSString category which provides HTML conversion. There are hundreds of categories implemented as open source and they provide enormous benefits where library code falls short. Discussing their suitability in entirety is however out of scope for this discussion.
One thing to note however is: You do not override anything using a category. Rather you are supplying something in extra. For example if you want some custom drawing across all your app views, you can define a category on UIView in your project and then all your views could simply include the category header file. You don't even have to inherit from this category, you simply inherit from the base type.
e.g. in the NSString category example above, you do not have to define your NSString to be of type NSString+HTML. Instead you just include the responsible NSString+HTML.h file wherever you want those extra methods like stringByConvertingHTMLToPlainText and so on. The changes remain limited to your project - to the files where you include this category.
Categories do not provide for extra data members - and that is something that only inheritance can provide. Yet, multiple inheritance among viewcontrollers is something you should definitely reconsider hundred times - you will see that what you are looking for is not multiple inheritance.