Say I have a FooController subclass of UIViewController that displays a list of Foos. What's the best practice for dealing with my foo property's lifecycle?
Do I define the #property as being read/write? It's not really -- once it's been set, changing it would potentially result in inconsistent state. Do I create the #property as readonly and write a new designated initializer, initWithFoo:(Foo *) aFoo that calls initWithNibName:bundle:? Now I have to create a new instance every time the controller is popped off the stack, and pushed on with a new foo.
The latter seems to me like the approach to take, but I've never seen anyone do this. So what's standard practice?
Properties are generally the way to go. They give you power of KVC/KVO
You should set the class as an observer of the Foo property (KVO). Then everytime Foo is changed, you get a chance to deal with it. No need to worry about inconsistency.
[self addObserver:self forKeyPath:#"foo" options:0 context:#"fooChanged"];
Then observe the change:
- (void)observeValueForKeyPath:(NSString *)keyPath ofObject:(id)object change:(NSDictionary *)change context:(void *)context{
if([keyPath isEqualToString:#"foo"]){
//do your thing
}
}
Now it doesn't matter if foo is set in the initializer or some time later, you can deal with it. You don't want to have your code break by forcing any objects to work with you class in a predetermined order. That is very inflexible and generally bad practice. In this way you can deal with these changes gracefully.
Objective-C is dynamic language. So don't be so strict in encapsulation. This ivar could be reached thought KVC anyways.
So #property (readwrite) is OK.
Related
I'm trying to learn to play with pointers here.
I have a UIImageView. I need to point its image property to another UIImageViews image property, so that whenever I change the second UIImageViews image, the first one gets updated automatically.
Some pointer manipulation here but I can't seem to get my head around it.
That is impossible. They are just pointers. For example aImageView and bImageView. You can set them's image pointer to point to the same UIImage. But change one of them does NOT change the other.
Maybe you can consider to use KVO to do what you want to do. Change one then your method will be called. Then in your method you can change the other.
you can use Key-Value Observing
from Apple Docs
Key-value observing provides a mechanism that allows objects to be notified of changes to specific properties of other objects.
KVO’s primary benefit is that you don’t have to implement your own scheme to send notifications every time a property changes.
[imageView1 addObserver:self
forKeyPath:#"image"
options:NSKeyValueObservingOptionNew | NSKeyValueObservingOptionOld
context:NULL];
- (void) observeValueForKeyPath:(NSString *)path ofObject:(id) object change:(NSDictionary *) change context:(void *)context
{
// this method is used for all observations, so you need to make sure
// you are responding to the right one.
}
Try to override the setter. Make a subclass of UIImageView, have a property for second UIImageView and write something like
-(void)setImage:(UIImage*)image{
_image = image;
self.secondImageView.image = image;
}
Hope this helps.
In my program I use KVO manually to observe changes to values of object properties. I receive an EXC_BAD_ACCESS signal at the following line of code inside a custom setter:
[self willChangeValueForKey:#"mykey"];
The weird thing is that this happens when a factory method calls the custom setter and there should not be any observers around. I do not know how to debug this situation.
Update: The way to list all registered observers is observationInfo. It turned out that there was indeed an object listed that points to an invalid address. However, I have no idea at all how it got there.
Update 2: Apparently, the same object and method callback can be registered several times for a given object - resulting in identical entries in the observed object's observationInfo. When removing the registration only one of these entries is removed. This behavior is a little counter-intuitive (and it certainly is a bug in my program to add multiple entries at all), but this does not explain how spurious observers can mysteriously show up in freshly allocated objects (unless there is some caching/reuse going on that I am unaware of).
Modified question: How can I figure out WHERE and WHEN an object got registered as an observer?
Update 3: Specific sample code.
ContentObj is a class that has a dictionary as a property named mykey. It overrides:
+ (BOOL)automaticallyNotifiesObserversForKey:(NSString *)theKey {
BOOL automatic = NO;
if ([theKey isEqualToString:#"mykey"]) {
automatic = NO;
} else {
automatic=[super automaticallyNotifiesObserversForKey:theKey];
}
return automatic;
}
A couple of properties have getters and setters as follows:
- (CGFloat)value {
return [[[self mykey] objectForKey:#"value"] floatValue];
}
- (void)setValue:(CGFloat)aValue {
[self willChangeValueForKey:#"mykey"];
[[self mykey] setObject:[NSNumber numberWithFloat:aValue]
forKey:#"value"];
[self didChangeValueForKey:#"mykey"];
}
The container class has a property contents of class NSMutableArray which holds instances of class ContentObj. It has a couple of methods that manually handle registrations:
+ (BOOL)automaticallyNotifiesObserversForKey:(NSString *)theKey {
BOOL automatic = NO;
if ([theKey isEqualToString:#"contents"]) {
automatic = NO;
} else {
automatic=[super automaticallyNotifiesObserversForKey:theKey];
}
return automatic;
}
- (void)observeContent:(ContentObj *)cObj {
[cObj addObserver:self
forKeyPath:#"mykey"
options:0
context:NULL];
}
- (void)removeObserveContent:(ContentObj *)cObj {
[cObj removeObserver:self
forKeyPath:#"mykey"];
}
- (void)observeValueForKeyPath:(NSString *)keyPath
ofObject:(id)object
change:(NSDictionary *)change
context:(void *)context {
if (([keyPath isEqualToString:#"mykey"]) &&
([object isKindOfClass:[ContentObj class]])) {
[self willChangeValueForKey:#"contents"];
[self didChangeValueForKey:#"contents"];
}
}
There are several methods in the container class that modify contents. They look as follows:
- (void)addContent:(ContentObj *)cObj {
[self willChangeValueForKey:#"contents"];
[self observeDatum:cObj];
[[self contents] addObject:cObj];
[self didChangeValueForKey:#"contents"];
}
And a couple of others that provide similar functionality to the array. They all work by adding/removing themselves as observers. Obviously, anything that results in multiple registrations is a bug and could sit somewhere hidden in these methods.
My question targets strategies on how to debug this kind of situation. Alternatively, please feel free to provide an alternative strategy for implementing this kind of notification/observer pattern.
Update 4: I found the bug using a mixture of breakpoints, NSLogs, code reviews and sweating. I did not use the context in KVO, although this is definitely another useful suggestion. It was indeed a wrong double registration that - for reasons beyond my comprehension - resulted in the observed behavior.
The implementation including [self willChange...]; [self didChange...] works as described (on iOS 5), although it is far from beautiful. The issue is that as NSArray is not KVO-compliant there is no way to talk about changes to its contents. I had also thought about notifications as suggested by Mike Ash, but I decided to go with KVO as this seemed like a more Cocoa-ish mechanism to do the work. This was arguably not the best of decisions ...
Yes, calling -addObserver: twice will result in two registrations. A class Foo and some subclass of Foo, Bar, may both (legitimately) register for the same notification, but with different contexts (always include the context, always check the context in -observeValueForKeyPath and always call super in -observeValueForKeyPath).
This means that an instance of Bar will register twice, and this is correct.
However, you almost certainly don't want to register the same object/keypath/context more than once accidentally, and as #wbyoung says overriding -addObserver:forKeyPath:options:context: should help you make sure this doesn't happen. If nesessary keeping track of observers/keypath/context in an array and making sure they are unique.
Mike Ash has some interesting thoughts and code on his blog about using contexts. He is right about it being broken but in practise KVO is perfectly useable.
That is, when you use it to do something it is meant todo. It used to be that you absolutely could not do something like this..
[self willChangeValueForKey:#"contents"];
[self didChangeValueForKey:#"contents"];
because it's a lie. The value of 'contents' when you call -willChange.. must be a different value from when you call -didChange... The KVO mechanism will call -valueForKey:#"contents" in both -willChangeValueForKey and -didChangeValueForKey to verify the value has changed. This obviously won't work with an array as no matter how you modify the contents you still have the same object. Now i don't know if this is still the case (a web search turned up nothing) but note that -willChangeValueForKey, -didChangeValueForKey are not the correct way to handle manual kvo of a collection. For that Apple provides alternative methods:-
– willChange:valuesAtIndexes:forKey:
– didChange:valuesAtIndexes:forKey:
– willChangeValueForKey:withSetMutation:usingObjects:
– didChangeValueForKey:withSetMutation:usingObjects:
It may not still be true that the value must change, but if it is, your scheme is not going to work.
What i would do is have one notification for modifications to your collection. And a different notification for modification of items in that collection. i.e. at the moment you are trying to trigger notifications for #"contents" when instead you could have #"contents" and #"propertiesOfContents". You would need to observe two keypaths but you can use automatic kvo instead of manually triggering the notifications. (Using automatic kvo will ensure that the correct versions of -willChange.. -didChange.. are called)
For automatic kvo of an array take a look at (no NSArrayController needed) :-
Key-Value-Observing a to-many relationship in Cocoa
Then each time an item is added to the collection, observe the properties you need (as you are doing now) and when they change flip a value for self.propertiesOfContents. (ok as i read that back it doesn't necessarily sound less hacky than your solution but i still believe it may behave better).
In response to your modified question, try overriding addObserver:forKeyPath:options:context: in your custom class and setting a breakpoint on it. Alternatively, you can just set a symbolic breakpoint on -[NSObject addObserver:forKeyPath:options:context:], but that will probably get hit a lot.
What is the difference between Delegate and Notification?
I understood like delegate and protocol,
#protocol classADelegate
-(void)DelegateMethod;
#end
classB <classADelegate>{
classA *ObjOfclassA=[[classA alloc]init];
ObjOfclassA.delegate=self;
//while push later, here we have taken the pointer of classB(self) to `classA` and stored in delegate variable of classA. So, from `classA` we can call the function in `classB`
push:classA from here.
-(void)DelegateMethod{
nslog(#"i am rithik from India");
}
}
classA{
id <classADelegate> delegate;
-(void)viewdidload{
[self.delegate DelegateMethod];
}
}
My doubt is
1. Why don't we use in classA like this
classA{
**classB** <classADelegate> delegate;
[self.delegate DelegateMethod];
}
What is the reason for using "id" and what is the difference of them?
2. we have call the method of classB's DelegateMethod function which is came from protocol definition.
instead we can straightly call that method by defining that instance method of classB.because we have the got the pointer for classB in classA's delegate variable.
like this.
classB{
-(void)DelegateMethod;
}
and then call this in
classA{
classB delegate;
-(void)viewdidload{
[self.delegate DelegateMethod];
}
}
So, from the above we have avoided the protocol and id variable .
but I knew many of us use delegate and protocol. Here I came to know about any advantages while use delegate and protocol
here what is the usage of protocol implementation for method of DelegateMethod function.
instead instance definition .
What is the usage of those by #protocol. Please any one guide me right direction.
I'm new to iphone developement. Right now, I knew how to create delegate. but while I came to study about the NSNotification
That is also do the almost right job like delegate. So, when should I use the delgate or NSnotification.
Short Answer: You can think of delegates like a telephone call. You call up your buddy and specifically want to talk to them. You can say something, and they can respond. You can talk until you hang up the phone. Delegates, in much the same way, create a link between two objects, and you don't need to know what type the delegate will be, it simply has to implement the protocol. On the other hand, NSNotifications are like a radio station. They broadcast their message to whoever is willing to listen. The radio station can't receive feedback from it's listeners (unless it has a telephone, or delegate). The listeners can ignore the message, or they can do something with it. NSNotifications allow you to send a message to any objects, but you won't have a link between them to communicate back and forth. If you need this communication, you should probably implement a delegate. Otherwise, NSNotifications are simpler and easier to use, but may get you into trouble.
Long Answer:
Delegates are usually a more appropriate way of handling things, especially if you're creating a framework for others to use. You gain compile time checking for required methods when you use protocols with your delegates, so you know when you compile if you're missing any required methods. With NSNotificationCenter you have no such guarantee.
NSNotificationCenter is kind of "hack-ish" and is frequently used novice programmers which can lead to poor architecture. A lot of times these two features are interchangeable, but more "hardcore" developers might scoff at the use of the NSNotificationCenter.
Q: what is the reason for using "id" and what is the difference of them?
A: Using id allows you to send any object to the method as a parameter. Note that you can not send primitives such as bools, floats, doubles, ints, etc. unless they are wrapped in their respective Object wrappers.
classB{
-(void)DelegateMethod;
}
and then call this in
classA{
classB delegate;
-(void)viewdidload{
[self.delegate DelegateMethod];
}
}
The above example you provided would require that classA's delegate always be of type classB, which isn't advantageous. Instead of using delegates in this scenario, you would probably just use a variable that referred to your other class, say, myClassB. The beauty of delegates is that you can pass around any object, and the code just works as long as they implement the required methods (which the compiler ensures, as long as it's marked as the correct delegate type).
A delegate uses protocols and creates a has-a relationship between the two classes. One of the other benefits of delegates is that you can return something back to the owning class.
Notifications, on the other hand, are more geared towards point to multipoint communication. An example of using an NSNotification might be in a tab bar controller application, where you may need to notify multiple view controllers of a particular event so they can refresh data, etc. This is great for classes that have no knowledge of one another and it wouldn't make sense if they did.
Now, to your other questions:
Why do we use id?
In your class, you want a handle to an object of indeterminate type, but which implements the protocol you define. Take UIWebView, for example. There can be infinitesimal types of classes that can be a delegate for it, therefore, it should not name a specific type of class, but specify that the class must implement the UIWebViewDelegate protocol. This reduces coupling to an absolute minimum and creates a highly cohesive application where you are creating interaction based on behavior, not state.
So, let's run through an example:
#protocol ClassADelegate
- (NSString*) determineValue;
#end
#interface ClassA : NSObject
{
id<ClassADelegate> delegate;
}
// Make sure you are using assign, not retain or copy
#property (nonatomic, assign) id<ClassADelegate> delegate;
#end
The implementation of ClassA:
import "ClassA.h"
#implementation ClassA
#synthesize delegate;
- (void) somePrivateMethod
{
if (self.delegate && [self.delegate implementsProtocol:#protocol(ClassADelegate)])
{
NSString* value = [self.delegate determineValue];
// Do other work
}
}
- (void) dealloc
{
delegate = nil;
}
#end
In the header, we declare that the class will implement the ClassADelegate protocol:
#import "ClassA.h"
#interface ClassB : NSObject <ClassADelegate>
{
}
- (void) someMethod;
#end
In the implementation of ClassB we create an instance of ClassA and set B as the delegate of A:
#import "ClassB.h"
#implementation ClassB
- (void) someMethod
{
ClassA* aClass = [[ClassA alloc] init];
aClass.delegate = self;
// Other work and memory clean up of A.
// Some logic occurs in A where it calls the delegate (self) which will
// call the `determineValue` method of this class.
}
// Here's the delegate method we implement
- (NSString*) determineValue
{
return #"I did some work!";
}
#end
Delegate is passing message from one object to other object. It is like one to one communication while nsnotification is like passing message to multiple objects at the same time. All other objects that have subscribed to that notification or acting observers to that notification can or can’t respond to that event. Notifications are easier but you can get into trouble by using those like bad architecture. Delegates are more frequently used and are used with help of protocols.
Simply We can say,
Delegates:
One - to - One
Notification:
One - to - Many
To declare Delegate
#protocol DelegateName
#required
- (void)method:(NSString *)param;
#optional
- (void)methodOptional:(NSString *)param;
#end
And declare a property for Protocol
#property id <DelegateName> delegate;
You can use
myObject.delegate = <# some object conforming to DelegateName #>;
NSNotification declaration
[[NSNotificationCenter defaultCenter] addObserver:self
selector:#selector(notificationHappened:)
name:MyCustomNotificationName
object:nil];
Then Implement
- (void)notificationHappened:(NSNotification *)notification {
// do work here
}
You can post Notification from anywhere using,
[[NSNotificationCenter defaultCenter] postNotificationName:MyCustomNotificationName
object:self
userInfo:nil];
call removeObserver: when you are finished.
We can use notifications for a variety of reasons. For example, you could broadcast a notification to change how user-interface elements display information based on a certain event elsewhere in the program. Or you could use notifications as a way to ensure that objects in a document save their state before the document window is closed.
The general purpose of notifications is to inform other objects of program events so they can respond appropriately.But objects receiving notifications can react only after the event has occurred. This is a significant difference from delegation.
The delegate is given a chance to reject or modify the operation proposed by the delegating object. Observing objects, on the other hand, cannot directly affect an impending operation.
I have an NSDictionary with some values. Usually, the values in the NSDictionary are static, but in some rare cases (user changes settings), the NSDictionary changes.
The dictionary is used application wide and stored in the app delegate.
The problem that I have now: When the settings change, I release the old dictionary and create a new one. How do I now inform all the relevant parties? I thought of storing NSDictionary** pointers and deference them as I need, in order to get the NSDictionary* (there is never a case where the dictionary is released and not recreated).
NSMutableDictionary* dict = [NSMutableDictionary alloc] init];
...
NSDictionary** ref = &dict;
When I run the debugger I can see that dereferencing ref does get me dict initially. But after some time, it seems that ref is pointing to nirvana. Wondering whether I need to manage memory or sth. for NSDictionary**? Since it's not a pointer to an object, retaining it doesn't make sense. But it does seem like a memory issue?
I'm not going to comment on the complexity of pointers, because that's really not relevant to this situation. Furthermore, I'm not really sure what it is that you want, but I think you are looking for a way to observe changes from one object in another. The nice thing is that Cocoa provides this out of the box.
So, you'll need to have this dictionary as a property to something (your application delegate). Then, use key-value-observing in whichever objects care, to watch that property for changes:
[appDelegate addObserver:self forKeyPath:#"dictPropertyName"];
Then, implement -observeValueForKeyPath:ofObject:change:context::
- (void)observeValueForKeyPath:(NSString *)keyPath ofObject:(id)object change:(NSDictionary *)change context:(void *)context {
if ([keyPath isEqualToString:#"dictPropertyName"]) {
// your property has changed; respond to that here
}
}
Let me know if this is something like what you wanted.
Jonathan's answer is correct. However, since this is a global sort of thing, it might make as much or more sense to simply use a notification to let all interested parties know that the dictionary has changed.
Specifically, see NSNotificationCenter and NSNotification.
I have an NSOperation that wraps some web service functionality. The NSOperation has a delegate that is to be messaged when the operation is over.
As the NSOperation lives on a different thread I have to make the call like this:
[delegate performSelectorOnMainThread:#selector(getDealersIDSuccess:) withObject:result waitUntilDone:YES];
It works just fine, but it gives me a warning:
warning:
'-performSelectorOnMainThread:withObject:waitUntilDone:'
not found in protocol(s)
I completely agree with the compiler on this one, it sees a delegate, it checks the protocol, it finds no declaration of a performSelector method.
My question is: can I remove the warning by making this call in a different manner?
My two guesses are that I could (1) write a method called
- (void) callDelegateMethodOnMainThred {
[delegate getDealersIDSuccess:result]
}
and call that through performSelectorOnMainThread, but I find that solution to be cumbersome and an extra, hard to read, step on top of the delegation.
The second solution could be to cast the delegate to the type of my parent object inside the selector, but that is just plain crazy and goes against the delegate encapsulation pattern.
I would really appreciate a third solution from someone with a better understanding of the language:)
Thank you in advance.
EDIT: Added delegate declaration:
id <ISDealersIDDelegate> delegate;
I declare my delegate as id. The delegate it self extends UIViewController.
I could see that declaring it NSObject would work.
performSelectorOnMainThread:withObject:waitUntilDone: method is declared in NSObject class. If your delegate object inherits from NSObject you can declare it as
NSObject<MyDelegateProtocol> *delegate;
So compiler will know that delegate responds to NSObject's methods and won't issue a warning.
It might be even a better solution not call performSelectorOnMainThread: on a delegate or other protocol implementation.
Make it the responsibility of the delegate/receiver to determine if it needs to do things on the main thread.
[delegate performSelector:#selector(delegateAction:)
withObject:actionData];
Delegate implementation
- (void)delegateAction:(NSData*)actionData
{
[self performSelectorOnMainThread:#selector(updateUIForAction:)
withObject:actionData
waitUntilDone:NO];
}
- (void)updateUIForAction:(NSData*)actionData
{
// Update your UI objects here
}
It might look like more code, but the responsibility is in the right place now
Actually on iOS 4 I prefer using NSNotifications and Observers (with Blocks) to perform updates on the mainthread.
- (id)addObserverForName:(NSString *)name object:(id)obj queue:(NSOperationQueue *)queue usingBlock:(void (^)(NSNotification *))block
I wrote down my design here.
1) Declare your delegate's protocol to extend the NSObject protocol in the .h file
#protocol YourDelegateProtocol <NSObject>
2) Cast to NSObject in your call
[(NSObject*)delegate performSelectorOnMainThread:#selector(getDealersIDSuccess:) withObject:result waitUntilDone:YES];
I definitely recommend number (1).