I get how to use K-V-O for simple property stuff. I have a model that looks like
#interface WateringScript : NSObject
#property (strong, nonatomic) NSMutableArray* spans; // holds WateringSpans
...
#end
#interface WateringSpan : NSObject
#property (strong, nonatomic) WateringAnchor* begin;
#property (strong, nonatomic) WateringAnchor* end;
...
#end
#interface WateringAnchor : NSObject
#property (assign, nonatomic) NSTimeInterval offset;
...
#end
Basically a top level object that holds a series of spans, the spans being defined as end and begin anchor objects, which amongst other things have an offset.
I have a custom view that would like to draw all of the offsets. Is there a simple way to observe all of the offsets? Such that as they change, or spans or added or removed, I can be notified of it and react accordingly?
Or do I have to observe the collection, and then on initial/add/remove changes observe and unobserve the collection elements? I think I could code this up if I have to, the real question is there KVO Juju that makes it easier?
You can't key-value observe through arrays. You have to observe the to-many property (spans) for changes to its content and separately observe the elements.
Once you handle addition and removal of elements so that you start and stop observing their properties, you can leverage that for the initial setup by specifying NSKeyValueObservingOptionInitial when you start observing the to-many property itself. You'll essentially be told that the initial elements have been "added".
For actually handling the added and removed elements, you can use -[NSArray addObserver:toObjectsAtIndexes:forKeyPath:options:context:] and -removeObserver:fromObjectsAtIndexes:forKeyPath: to start and stop observing their properties en masse.
It ends up being not too much code.
Related
There are at least 3 methods of creating an IBOutlet in Objective-C, for making iOS 10 App, in Xcode 8.
Method 1: in ViewController.h
#interface ViewController : UIViewController
#property (nonatomic, strong) UILabel *textLabel;
#end
Method 2: in the interface of ViewController.m
#interface ViewController () {
IBOutlet UILabel *textLabel;
}
#end
Method 3: in the interface of ViewController.m, using #property
#interface ViewController ()
#property (nonatomic, strong) UILabel *textLabel;
#end
Given that the textLabel has to be accessed & its text is needed to be updated frequently, which method is the correct way to do so?
That all depends on whether you need your outlet to be accessible to classes outside of the containing one; generally I would discourage this because it is good practice to keep your view controllers responsible for updating your UI and not pass this task around to other classes. With this being said, Method 3 would be the best option, however, if you do have to access your object from another class, then simply use Method 1 so it is exposed in your class header.
Method 2 utilises iVars rather than object properties and is not the proper way to declare outlets, it may even cause unexpected behaviour so it is best to avoid this method.
Your code contains no proper IBOutlet. Outlets are connections to Storyboard.
Method 1
This is a property. As it is in .h file, it can be reached from outside. The Objective-C pattern for public.
Method 2
This is an iVar. Do not use iVars if you do not have to.
Method 3
This is a property. As it is in .m file, it can not be reached from outside. The Objective-C pattern for private.
Method 4
A proper IBOutlet looks like this:
#interface ViewController ()
#property (nonatomic, weak) IBOutlet UILabel *label;
#end
It is a simple property. You have to decide if you put it in .h or .m file depending on whether or not you want to publish it.
The IBOutlet simply makes the property connect-able to Storyboard. It's an annotation for Xcode and does not alter the semantic of your code.
Edit 1:
As Sulthan correctly mentions in the comments:
In most situations the correct design pattern is to hide outlets because it's an implementation detail. External classes should not set data directly using views.
Edit 2:
Why "not to use iVars if you do not have to" (2)
Opinion based:
I consider it as good OOP practice to use getters & setters (and thus not to access the variables directly). Also code is easier to read as you know while reading what x = self.variable (property) and x = variable (local variable) are.
If you have to use iVars for some reason, it is common to (and I would recommend to) prefix the name with _. x = _variable (iVar).
This might be a completely dumb question, but I'm a CD noob...
I have an object that tracks rectangular points on maps by defining the top left and bottom right corners, like this...
#property (nonatomic) float latitudeNorth; // same as "northwest"
#property (nonatomic) float latitudeSouth; // same as "southeast"
#property (nonatomic) float longitudeEast; // same as "southeast"
#property (nonatomic) float longitudeWest; // same as "northwest"
Now I need to add four more points, so that we can have polys instead of pure rectangles. So I want to add this...
#property (nonatomic) float latitudeNorthEast;
#property (nonatomic) float latitudeSouthWest;
#property (nonatomic) float longitudeNorthEast;
#property (nonatomic) float longitudeSouthWest;
These data points are ephemeral and exist only as long as the app is running. They were, however, originally built in the xcdatamodeld. Is this a problem? Or am I find just adding the additional properties and using the old xcdatamodeld as-is?
I depends on you complete structure.
If you have some more entities that are fetched several times and saved again, and you need every time you fetch also the ephemeral properties, you have to hold them of course in the DB.
But if you only need them while you fetched and holding the Object, you can handle them just in class and there is no need to put them into the DB.
Not every item in the DB also has to be in the extracted class ;)
But the most attributes will also be saved, because they have to be updated via other services i.e. or have to present these updates in other views. Or maybe also because you don't want to hold the attributes all the time or will fetch them again (i.e. after a tableView.reloadData) and don't want to lose the calculated results
You can have other properties declared in your managed object subclass. They won't be initialized when you load up your object from a persistent store (when you close your app and open it up again, the values will go away), but you can get around that. However, there are better ways to do this. For example, you can write methods that calculate the values on the spot:
-(float)latitudeNorthEast;
-(float)latitudeSouthWest;
-(float)longitudeNorthEast;
-(float)longitudeSouthWest;
In your case, all that these methods do is return one of the other property values, so this seems like the way to go.
I know that if I use
#interface TPN : UIViewController{
IBOutlet UIView *testView;
}
#property (strong, nonatomic) IBOutlet UIView *testView;
I know that the first one is essentially a private variable that is only accessed within the class. and the second one "#property" is able to be accessed from an instantiated object. I find it odd in most tutorials that people tend to set properties when they are usually changing an outlet from within the class itself. Is there any guideline I should be following?
You no longer need to specify the ivar at all. Nor is there a need to use #synthesize.
Use a property, but make sure it is weak, not strong
#interface TPN : UIViewController
#property (weak, nonatomic) IBOutlet UIView *testView;
In the implementation you can now access the ivar as _testView.
For a private property (above is public) instead put the #property within a category in the implementation file:
#import "TPN.h"
#interface TPN ()
#property (weak, nonatomic) IBOutlet UIView *testView;
#end
#implementation TPN
....
You are right. If you are only going to use the instance variable inside the class, there is no point to make it a property. A property simply means a pair of getter/setter. If you don't need to do anything specially when getting/setting, you can just use the instance variable directly.
Prior to ARC, there was a side benefit to using properties everywhere, in that it was easier to do memory management for object pointers -- properties declared as retain would automatically release and retain for you when you set it, without you typing that code yourself like you would have to do with an instance variable directly. However, now in ARC, the compiler does that for you anyway when you assign, if it's a strong instance variable. So this benefit is now irrelevant.
I would suspect that a lot of the reason people use properties for outlets is because of perpetuation of that usage in almost all tutorials and examples (possibly due to the previous benefit with retain memory management), and they simply don't realize they can do something different.
My problem is a follows
I have a UIViewController subclass which holds a UISegmentedController and four tableviews that I layed out in interface builder.
#interface MultiTableHoldingView : UIViewController{
}
#property (strong, nonatomic) IBOutlet DataTV *dsDataTV;
#property (strong, nonatomic) IBOutlet EnviroTV *dsEnvironmentTV;
#property (strong, nonatomic) IBOutlet LocationTV *dsLocationTV;
#property (strong, nonatomic) IBOutlet Note_AnimalTV *dsNoteAnimal;
#property (strong, nonatomic) IBOutlet UISegmentedControl *diveElementSegmentController;
#property (strong, nonatomic) DiveSite* currentSite;
- (IBAction)diveElementSegmentControllerDidChange:(UISegmentedControl *)sender;
-(void) setFreshWaterColor;
-(void) setSaltwaterColor;
#end
setFreshWaterColor and setSaltWaterColour just set the background colour properties of the MultiTableHoldingView instances UIView and the four tableviews it contains. Both these method work fine when called from MultiTableHoldingView's viewDidLoad method. Heres one of them
-(void) setSaltwaterColor{
DLog(#"in set salt water colour");
self.view.backgroundColor= SaltWaterColor;
_dsLocationTV.backgroundColor=SaltWaterColor;
_dsDataTV.backgroundColor=SaltWaterColor;
_dsEnvironmentTV.backgroundColor=SaltWaterColor;
_dsNoteAnimal.backgroundColor=SaltWaterColor;
}
The other is the same except sets to FreshWaterColor - both are #define i have set up.
I use the segmentedController to turn the hidden properties of the various tableviews on and off. All nice and simple. The tableviews are pulling in their data. Working fine.
When selecting one of my tableview cells on one of the tableViews I want to change the background colour of both my tableview ( in fact all of my tableviews ) and the UIView that is the superview
self.superview.backgroundColor = FreshWaterColor;
works fine for reaching back and changing the instance of MultiTableHoldingView views background property but I want to call the instance of MultiTableHoldingView's setFreshWaterColor and setSaltwaterColor methods.
I have imported MultiTableHoldingViews header into the relevant tableview (EnviroTV), so it knows about it its superviews methods. But if I try to call either of the two methods on self.superview the methods do not show up and if i type them in full I get an the following error
no visible interface for 'UIView' shows the selector 'setFreshWaterColor'
So i checked what kind of object the superview was and its a "class of superview UIViewControllerWrapperView"
I search on this and its apparently "
This is a private view used by the framework. You're not supposed to modify it or whatsoever."
I'm obviously missing something here - how should i call the method on the instance of MultiTableHoldingView ?
Thanks in advance
Simon
Doh - its just delegation as danypata mentions in the comments - i've posted exactly how I did this as an answer below. Tried to make it as clear as possible how delegation works
THE SOLUTION
Step one - get more sleep before coding .
This really is basic objective-c stuff - I just went off at a tangent, looking for someway else to do it, getting confused by my discovery of UIViewControllerWrapperView along the way.
The solution, as danypata rightly suggests in the comments, is to use delegate -a common design pattern in Objective-C - just like you do, for example, when you use another class to supply tableview data
As I've been a numpty and wasted hours of my time today I'll try and make the 'how' clear for other relative newbies or people having an off day and not thinking straight.
In my case I set this up as follows
In my subview class's interface file - EnviroTV.h - I define the following protocol just before the #interface declaration
#protocol EnviroTVProtocol <NSObject>
-(void) setFreshWaterColor;
-(void) setSaltwaterColor;
#end
Then in the #interface section of the same file I add a property of type id which must conform the protocol I just declared .
#property (nonatomic, strong ) id<EnviroTVProtocol> colorChangeDelegate;
You make the type an id - a generic object - as you really don't care what kind of object is going to act as your delegate just that it implement the methods that you need it to run. When an object declares itself to implement a protocol its just promising to implement the method(s) that are required by the protocol
So, when I want to run the methods on the superviews class I call
[self.colorChangeDelegate setFreshWaterColor];
Or
[self.colorChangeDelegate setSaltWaterColor];
The final piece of the delegation pattern is to go into the class thats going to be the delegate (in this case my MultiTableHoldingView class ) and state that it conforms to the protocol
I do this in the MultiTableHoldingView.h file
Changing this line :
#interface MultiTableHoldingView : UIViewController
into this line :
#interface MultiTableHoldingView : UIViewController <EnviroTVProtocol>
means this class promises to implement all the required methods of the EnviroTVProtocol.
Luckily I had already written the two methods. So when I compiled it ran correctly
Newbies - don't be afraid of delegation - its awesome and not as complex as you first imagine it to be
Meanwhile, if anyone can explain what UIViewControllerWrapperView is .....
Like a doop I'd been declaring Instant Variables (iVar) and then #property in the interface .h file for a while now.
#interface MainGameViewController : UIViewController {
UserFactorsViewController *userFactorsViewController;
UITableView *myTableView;
}
#property (nonatomic, retain) UserFactorsViewController *userFactorsViewController;
#property (nonatomic, retain) IBOutlet UITableView *myTableView;
Under Automatic Reference Counting, should I just dispense with iVar and go all #property? Should I even have the word "retain" in property? What if I'm deploying for iOS 4.3, should I still use ARC?
Don't feel like a doop, even though the compiler will add ivars for you if you don't include them, many people still declare them (many book authors as well) to make the code a little bit easier to read (easier to distinguish between ivar and property).
When creating a property now, Apple wants you to think in terms of Object Graphs, so do some research on "strong" and "weak" property attributes instead of retain and releases.
Also, iOS 4 is setup as a target for ARC so you should be ok. But I believe if you wanted to support iOS 3.0 you would have to manually manage retain and releases as before.