I have a data structure I am trying to store in objective c for ios5 with ARC.
The data structure is something like -
Class - **Book**
#property (strong) NSArray *pages;
#property (strong) Page *startingPage;
Class - **Page**
#property (strong) Book *book;
#property (strong) Page *nextPage;
#property (strong) Page *previousPage;
The problem as can be imagined is with memory leaks.
There are a couple of cycles here -
Book -> pages -> page -> book
nextPage -> previousPage
Book -> startingPage -> book.
I can't make the properties weak because if I do so, I'll lose the pointer to that value.
So suppose I make book in Page as weak, then when I try to deallocate a page, book will get deallocated. However, I still want the book to remain allocated.
Is there any alternate way this data structure can be stored?
Thanks!
I don't understand why making Page->book weak would lose you the pointer to the book. Weak properties aren't auto-nil'd until the object they point to is deallocated. As long as at least one other object has a strong reference to book you should be fine.
So imagine a Library object that has an NSArray of books. The array retains the books added to it, so all weak references to that book will stay valid until the book's removed from the array (and implicitly released).
Related
I have an NSManagedObject subclass where absences is an NSMutableArray
#interface Record : NSManagedObject
#property (nonatomic, retain) id absences;
#end
I want to be able to add items to the absences array; however, if I do [myRecord.absences addObject:SomeObj the record does not save properly. It almost appears that the NSManagedObject does not know that I updated the absences array.
Nevertheless, if I add SomeObj to some localAray, then set myRecord.absences = localArray, the NSManagedObject saves correctly.
Can someone explain this behaviour and how I might avoid it...thanks
You're exactly right, in the first case you're changing an object outside of NSManagedObject field of view. To solve this, Apple doc says the following
For mutable values, you should either transfer ownership of the value to Core Data, or implement custom accessor methods to always perform a copy.
So declaring your property with (copy) should suffice.
So I'm not sure how this works. I briefly looked at a coworker's C# (I'm not a .NET developer), and I see a lot of stuff that gets passed into methods would be some class object that conforms to an interface. Is this something that is good to do in objective-c as well?
For example, I'm messing around with the MapKit API and I created my own class that conforms to the MKAnnotation protocol so I can have custom views and some extra properties for the typical pin that gets dropped on the map. I plan on using this class I created,
Address : NSObject
as opposed to the MKPlacemark class when I place pins on the map. In my other view controllers and model classes, do I do:
#property (nonatomic, strong) id <MKAnnotation> object; //1
or
#property (nonatomic, strong) Address *object; //2
I started with the example 1, but then when I actually needed some of the properties of the Address object, I found myself having to typecast the object anyway which seemed like what's the point, or I'm missing the point? So I guess my end question is, is 1 or 2 better, and in what scenarios? Thanks.
I would go with option 3 which would look like this:
Address : NSObject <MKAnnotation>
Then when you implement the class, implement the methods required to conform to the MKAnnotation protocol.
This way you can have the best of both worlds.
Protocols are very similar to interfaces in languages such as C# or Java. One of the main differences is the ability to require certain methods and have other methods be optional. Since Objective-C is such a dynamic language, you'll see a number of calls such as [foo responseToSelector:#selector(someSelector:)]. If -someSelector: was marked as optional, you would need to check to see if the receiver "responds" to that message. If it were marked as required, however, the compile would throw up a warning if you didn't implement that method. Take a look at the Objective-C Language Reference for more information
You cannot use strong keyword for id type, use this instead:
#property (nonatomic, assign, readwrite) id<MyDelegate> delegate;
I haven't seemed to run into a problem yet, but I'm trying to make sure I'm using some best practices.
Say I have a UITableViewController with a data source of an NSArray of MyObject objects. So in my UITableViewController I declare my data source like:
#property (strong, nonatomic) NSArray *dataSource;
Then after I touch a cell I want to push a new view that shows a detail view of something, using that cell's MyObject. So in the new UIViewController I have this:
#property (strong, nonatomic) MyObject *myObject;
Now in the UITableViewController when a cell is touched:
MyObject *myObject = [[self dataSource] objectForIndex:[indexPath row]];
NewView *view = [[NewView alloc] initWithMyObject:myObject];
// ... push onto nav controller, etc
Basically what I'm afraid of is my array is declared with strong, MyObject in the detailed view is declared with strong, and who knows maybe there is another view with the same MyObject declared with strong.
Bottom line: is this the proper way to pass an object in between views? I haven't really used a weak reference yet in my apps and I feel like that isn't right. Any help or links to help would be amazing.
I think that what you need to understand is how arc works.
Basically whatever has a strong pointer pointing to it will be retained.
This works by adding a reference counter in the object so when you do this:
#property (strong, nonatomic) MyObject *myObject;
you create a STRONG pointer for myObject, (not the object).
but when you do this
MyObject *myObject = [[self dataSource] objectForIndex:[indexPath row]];
you make this pointer increase the reference counting on whatever you have in the specified index from that data source.
The important part is that as long as the pointer keeps pointing to this object it will be kept alive.
About your concern with the views.
Views created in the interface builder have their elements declared internally with strong pointers. This is when you want to use a weak reference. When you add your own IBOutlet to an element in the view it is good practice to make it weak. If you think about the reason logically, it basically means that you dont care about this interface builder element since you only want it to survive until the viewcontroller is deallocated.
When you usually encounter retain cycles is when an object has a child object, and this child object has a STRONG reference to its parent.
this is:
Object A creates object B with a strong pointer
Object B points to object A with a strong pointer
A will keep B alive and B will keep A alive.
This page will explain to you some basic stuff about how to avoid this kind of stuff:
http://cocoawithlove.com/2009/07/rules-to-avoid-retain-cycles.html
Also about passing objects between views, it is very very simple.
First get a pointer from View 1 to View 2 (can be strong or weak depending on who should be keeping view 2 alive, if its from the IB Builder it should be weak if its programatically it should be strong)
Second, make a property in view 2 (#property (strong, nonatomic) MyObject *myObject;)
now it is as simple as:
Self.view1Pointer.myObject = self.myOtherObject;
Understand here how both views are strongly pointing to this object so the object will be kept alive as long as 1 of the views hasnt been deallocated.
You wont create a retain cycle, you simply have the reference counting from that object set to 2.
Note: When a view is deallocated, all of its pointers are set to nil so any object being pointed by them will decrease in its reference count. IF it reaches 0 it is deallocated. (in the previous case myobject will be 1 because another view is still pointing to it).
The only scenario where you will create a retain cycle is if you manage to make myObject point strongly to View2 as well. So now they are keeping each other alive. (but as explained before you can make myObject point to view2 weakly which wont create a retain cycle).
You can learn more about arc here:
http://www.raywenderlich.com/5677/beginning-arc-in-ios-5-part-1
It's not a retain cycle. It's a fine way to do things. The instance of MyObject doesn't strongly reference any of its owners, so when the last of those owners eventually gets released, so too will the object.
After going through a beginner's iPhone developer book and reading sample code online, I've noticed that most Objective C programmers synthesize nearly every instance variable. Some variables are convenient to snythesize, but most should not when honoring the object oriented principle of encapsulation. The worst are synthetized properties marked as private. A C++ programmer trying to use someone else's code will read the public fields and methods in the header file. They will skip the private variables. This C++ programmer will not know that you intended the private properties to be used in some meaningful way.
Take a look at this sample template on lazy table image loading provided by Apple:
Header
#interface ParseOperation : NSOperation <NSXMLParserDelegate>
{
#private
id <ParseOperationDelegate> delegate;
NSData *dataToParse;
NSMutableArray *workingArray;
AppRecord *workingEntry;
NSMutableString *workingPropertyString;
NSArray *elementsToParse;
BOOL storingCharacterData;
}
Source
#interface ParseOperation ()
#property (nonatomic, assign) id <ParseOperationDelegate> delegate;
#property (nonatomic, retain) NSData *dataToParse;
#property (nonatomic, retain) NSMutableArray *workingArray;
#property (nonatomic, retain) AppRecord *workingEntry;
#property (nonatomic, retain) NSMutableString *workingPropertyString;
#property (nonatomic, retain) NSArray *elementsToParse;
#property (nonatomic, assign) BOOL storingCharacterData;
#end
#implementation ParseOperation
#synthesize delegate, dataToParse, workingArray, workingEntry, workingPropertyString, elementsToParse, storingCharacterData;
Now I know this is not C++ and we shouldn't assume all C++ practices should be honored in Objective C. But Objective C should have good reasons to stray away from general programming practices.
Why are all the private ivars synthesized? When you look at the project as a whole, only NSMutableArray *workingArray is used by outside classes. So none of the other ivars should have setters and getters.
Why are very sensitive ivars synthesized? For one, now that id delegate has a setter, the user of this object can switch the delegate in middle of the XML parsing, something that doesn't make sense. Also, NSData *dataToParse is raw XML data retrieved from the network. Now that it has a setter, the user of this object can corrupt the data.
What's the point of marking everything private in the header? Since all ivars are are synthesized to have getters/setters, they are effectively public. You can set them to anything you want and you can get their value whenever you want.
I follow the idiom modeled by this example in many of my classes, so I can try to explain my own justification for this practice.
The properties in this example are declared in a class extension in the .m file. This makes them effectively private. Any attempt to access these properties from another class will cause a "Property not found" error upon compilation.
For developers coming from other languages, it may seem strange to synthesize getters and setters for private instance variables. Indeed, there is only one reason why I do this. When used consistently, synthesized properties can simplify memory management and help avoid careless mistakes that can lead to bugs. Here are a couple of examples:
Consider this:
self.workingPropertyString = [NSMutableString string];
versus this:
workingPropertyString = [[NSMutableString string] retain];
Many developers would claim that these two assignments are functionally equivalent, but there's an important difference. The second assignment leaks memory if workingPropertyString was already pointing at a retained object. To write code functionally equivalent to the synthesized setter, you'd have to do something like this:
NSMutableString *newString = [NSMutableString string];
if (workingPropertyString != newString) {
[workingPropertyString release];
workingPropertyString = [newString retain];
}
This code avoids leaking any existing object that the instance variable may be pointing to, and it safely handles the possibility that you may be re-assigning the same object to the instance variable. The synthesized setter does all of this for you.
Of course we can see that (workingPropertyString != newString) will always be true in this case, so we could simplify this particular assignment. In fact in most cases you can probably get away with a simple direct assignment to an instance variable, but of course it's the exceptional cases that tend to create the most bugs. I prefer to play it safe and set all my object instance variables through synthesized setters. All my instance object assignments are simple one-liners that look like this:
self.foo = [Foo fooWithTitle:#"The Foo"];
or this:
self.foo = [[[Foo alloc] initWithTitle:#"The Foo"] autorelease];
This simplicity and consistency gives my feeble brain less stuff to think about. As a result I almost never have bugs related to memory management. (I'm aware that the autorelease idiom could theoretically consume excessive memory in a tight loop, but I have yet to encounter that issue in practice. If I ever do, it's a simple case to optimize.)
One other thing I like about this practice is that my dealloc methods all look like this:
- (void)dealloc {
self.delegate = nil;
self.dataToParse = nil;
self.workingArray = nil;
self.workingEntry = nil;
self.workingPropertyString = nil;
self.elementsToParse = nil;
[super dealloc];
}
EDIT: Daniel Dickison pointed out some
risks to using accessors in dealloc
that I hadn't considered. See the
comments.
where every object property is simply set to nil. This simultaneously releases each retained property while setting it to nil to avoid certain crashes due to EXC_BAD_ACCESS.
Note that I've set self.delegate = nil; even though that property was declared as (nonatomic, assign). This assignment wasn't strictly necessary. In fact, I could do away with properties for my (nonatomic, assign) objects altogether, but again I've found that applying this idiom consistently across all my instance variables gives my brain less to think about, and further reduces the chance that I'll create a bug through some careless mistake. If necessary I can simply flip a property from (nonatomic, assign) to (nonatomic, retain) without having to touch any memory management code. I like that.
One could also use consistency as an argument for synthesizing properties for private scalar variables, as your example has done in the case of BOOL storingCharacterData;. This practice ensures that every instance variable assignment will look like self.foo = bar;. I don't usually bother to create private scalar properties myself, but I can see some justification for this practice.
Why are all the private ivars
synthesized? When you look at the
project as a whole, only
NSMutableArray *workingArray is used
by outside classes. So none of the
other ivars should have setters and
getters.
No real need; if you are going to access all the ivars directly anyway, there is no need for #synthesize.
Why are very sensitive ivars
synthesized? For one, now that id
delegate has a setter, the user of
this object can switch the delegate in
middle of the XML parsing, something
that doesn't make sense. Also, NSData
*dataToParse is raw XML data retrieved from the network. Now that it has a
setter, the user of this object can
corrupt the data.
None of the setter/getters are publicly declared. If a client of the class wanted to corrupt things by switching the delegate in the middle, they'd have to break encapsulation to do so.
So, ultimately, a non-issue.
What's the point of marking everything
private in the header? Since all ivars
are are synthesized to have
getters/setters, they are effectively
public. You can set them to anything
you want and you can get their value
whenever you want.
Note that there is no need to even declare the ivars in that example; the compiler will automatically synthesize them based on the #property declaration.
Traditionally, #private protected against someone diddling the ivar directly from externally to an instance of the class.
Note that anInstance->ivar or self->ivar is almost never used (and, when used, it is almost always for the wrong reason). There are uses for it, but it is rare.
I want an array that gets data from one class to be avaliable to me in another class with the same data.
If we declare an array on the applicationDelegate class.
Then declare an object of applicationDelegate in both classes.
And assign the array into appDelegate.array from one class, will i be able get the array across the classes?
I'm with Mike. Leave the App Delegate out of it.
You're in control of when and how your objects are instantiated. If it's important for more than one class to have access to the same data, hand off the data, or a means of getting at your data, as you create instances of the dependent class.
An example, given classes WVParent and WVChild.
WVParent has a property, someArray, which is the array your other objects need:
#interface WVParent : NSObject {
NSArray *someArray
}
#property (nonatomic, retain) NSArray *someArray;
#end
Then you have WVChild, which itself has a property called parentObject:
#class WVParent;
#interface WVChild : NSObject {
WVParent *parentObject;
}
#property (nonatomic, assign) WVParent *parentObject;
#end
Assuming the parent is creating the child instance, you'd allocate it and assign the parent:
WVChild *child = [[WVChild alloc] init];
child.parentObject = self;
Then the child instance can access someArray by:
self.parentObject.someArray
This is just one option. You could also just pass the array itself to the child, assuming the data is static and unlikely to change over the course of the application session.
This way, instead of having a source of data living somewhere in the App Delegate, it lives within a class more appropriately responsible for its creation, maintenance and vending. If you've got a class that pops into existence and can only reach the rest of your app by getting the app delegate, you might want to put a little more thought into your architecture.
More on dependency injection here:
http://en.wikipedia.org/wiki/Dependency_injection
Yes, you could declare a member/property on your applicationDelegate class, although you should try to follow the Single Responsibility Principle and make sure you don't end up stuffing lots of miscellaneous shared stuff in your app delegate (which happens a lot with iPhone code).
Another alternative would be to inject the array into the objects' constructors when you create them.
It's hard to know the best solution in terms of design without knowing what this data is and where it really belongs.