I've been reading aaron hilliegass's Cocoa programming book and I've just done Chapter 7 where he talks about KVC and KVO. For the life of me I cannot get my head around KVC. I've gone to google and looked at numerous articles and the apple documentation for it but I cannot grasp why/how i should use KVC. Anyone able to help here?
Got a tip for us?
Let us know
Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.
macOS Don't understand Key-Value Coding at all.
- Thread starter danchurchill123
- Start date
- Sort by reaction score
KVC is the idea is that if you name your getters/setters a certain way, then other classes will know they are getters/setters and not other methods.
KVO is one application of this. It is the runtime system using those naming conventions to watch for properties changing on your objects and let you know.
KVO is one application of this. It is the runtime system using those naming conventions to watch for properties changing on your objects and let you know.
Hi,
I have been confused myself by the KVC, KVO and I still not quite familiar with it.
I think the main gain of the KVC is the generic way it works.
Lets say that you have a call will several instance variables. I will use two of them since it is easier to write the example.
Then you create setters and getters, I show only setters:
Now you created an instance of that class and call it ourCar.
You can set the data in the normal way
Or using KVC
It seems the same and in the KVC example you even have more to write. To be more funny the KVC is using your setters…
Now imagine that you have to make a real program. Then the names can change and it is not fun to make changes all over the code manually.
Lets say that you keep the cars in a array, a data base or something similar.
You use loop to set them and now you will use the KVC to make it simple and generic. You really need only one line to do the set job.
Is it not simpler ???
You just have to supply the keys and values and you have a generic pice of code.
There are as well possibilities to set all the instance values of an object in a single line by using setValuesForKeysWithDictionary but it is another story. Good luck with the book.
Hope it will help
/petron
I have been confused myself by the KVC, KVO and I still not quite familiar with it.
I think the main gain of the KVC is the generic way it works.
Lets say that you have a call will several instance variables. I will use two of them since it is easier to write the example.
Code:
NSString *manufacturer;
NSString *regPlate;Then you create setters and getters, I show only setters:
Code:
- (void) setManufacturer: (NSString *)val;
- (void) setRegPlate: (NSString *)val;Now you created an instance of that class and call it ourCar.
You can set the data in the normal way
Code:
[ourCar setManufacturer:@”Volvo”];
[ourCar setRegPlate:@”XYZ 123"];Or using KVC
Code:
[ourCar setValue @”Volvo” forKey @”manufacturer”];
[ourCar setValue @”XYZ 123” forKey @”regPlate”];It seems the same and in the KVC example you even have more to write. To be more funny the KVC is using your setters…
Now imagine that you have to make a real program. Then the names can change and it is not fun to make changes all over the code manually.
Lets say that you keep the cars in a array, a data base or something similar.
You use loop to set them and now you will use the KVC to make it simple and generic. You really need only one line to do the set job.
Code:
[carList setValue value forKey key];Is it not simpler ???
You just have to supply the keys and values and you have a generic pice of code.
There are as well possibilities to set all the instance values of an object in a single line by using setValuesForKeysWithDictionary but it is another story. Good luck with the book.
Hope it will help
/petron
thanks guys for the replies. i'm (beginning) to get the grasp of KVC and KVO. also heard that it helps with
-(by making your classes KVC code compliant) you make your classes able to be used in the future in a very generic way without re-writing code etc.
-using the features of undo/redo in cocoa.
I don't understand what you mean by this line.
___
Now imagine that you have to make a real program. Then the names can change and it is not fun to make changes all over the code manually.
___
-(by making your classes KVC code compliant) you make your classes able to be used in the future in a very generic way without re-writing code etc.
-using the features of undo/redo in cocoa.
I don't understand what you mean by this line.
___
Now imagine that you have to make a real program. Then the names can change and it is not fun to make changes all over the code manually.
___
I meant that when making a software that somebody will use, you, your friend or somebody else, you will soon discover that "requirements" change all the time, new features are added... and one need to make some changes.
If one write a generic software then the changes are small, easy, fast and not so buggy. The use of KVC helps on the way.
/petron
If one write a generic software then the changes are small, easy, fast and not so buggy. The use of KVC helps on the way.
/petron
ok thanks!
so i should use KVC all the time for accessing my instance variables (ivars) rather than direct accessing or calling accessors/getters directly so i've made it KVC compliant?
I wouldn't use KVC all the time. To be KVC compliant you just need to name your setters and getters properly.
What this does is allow other parts of the cocca framework that use KVC internally to work properly. You will see that later in the book. Look for it and try to understand how things are working behind the scenes. The framework doesn't know the names of your properties, so you assign the propery name (key) to a variable. KVC then allows the property to be changed, since your property name can't be hard coded into the frameworks code. KVC is the only way methods in the framework can call methods in your objects.
Using KVC for everything (i.e. [foo setValue:x forKey:y] instead of foo.y = x
will just make your app unnecessarily slow, and remove all the benefits of the compiler's type-checking. It has its uses, but accessors (or properties) are often a better choice.
will just make your app unnecessarily slow, and remove all the benefits of the compiler's type-checking. It has its uses, but accessors (or properties) are often a better choice.
What you gain from KVC really boils down to what the Cocoa framework gives you.
Cocoa Bindings use KVC to let you describe how the view attaches to the controller or data.
Core Data exposes your properties you create in the data model via KVC so that you don't have to jump through hoops creating shim objects for each entity unless you want to extend the behavior of an entity.
By encouraging you to write code in a way that can be used generically in the future, it opens up a lot of opportunities going forward as new tech gets added that makes our job easier.
Cocoa Bindings use KVC to let you describe how the view attaches to the controller or data.
Core Data exposes your properties you create in the data model via KVC so that you don't have to jump through hoops creating shim objects for each entity unless you want to extend the behavior of an entity.
By encouraging you to write code in a way that can be used generically in the future, it opens up a lot of opportunities going forward as new tech gets added that makes our job easier.