In ARC, I want to release the custom view added to parent view and array.
#property (nonatomic, weak) IBOutlet UIScrollView* panelScroll;
#property (nonatomic, retain) NSMutableArray *medsSectionViews;
Above are the two properties in which a customview object is added as below:
CustomView* newView;
newView = [[CustomView alloc] init];
[panelScroll addSubview:newView];
[self.medsSectionViews addObject:newView];
newView = nil;
Its not releasing the object. What is the problem? How can I achieve it? Please mention the reference count at required points.
CustomView *newView = [[CustomView alloc] init]; // 1 owner (the newView local variable)
[panelScroll addSubview:newView]; // 2 owners (local variable, the superview panelScroll)
[self.medsSectionViews addObject:newView]; // 3 owners (local variable, superview, array medsSectionViews)
newView = nil; // 2 owners (superview, array)
now
[array removeAllObjects]; // 1 owner (superview)
[newView removeFromSuperview]; // 0 owners
// view gets deallocated because it has no owners
Some method will retain object:
In your code:
1. addSubview:
2. addObject:
retain your view;
so your just need:
[array removeAllObjects];
[newView removeFromSuperview];
and why newView = nil can't release view ?
Because In ARC it's use Reference counting to management object life cycle.
Your newView variable appears to be a local variable. As soon as that goes out of scope it will release it's strong reference to your view. Thus you don't really have to set it to nil.
You have 2 other strong references:
Arrays maintain strong references to their contents.
When you add a view to a superview, the superview holds a strong reference.
If you want it released, you need to both remove it from the array and remove it from it's superview. Note that it will then be deallocated.
Related
I am working on the UIPopover and in one of the example I found that the Popover object is
created but then the object is assigned to the property of the Viewcontroller.
UIPopoverController* aPopover = [[UIPopoverController alloc] initWithContentViewController:content];
self.popoverController = aPopover;
What is the merit in such assignment and any reason for not assigning object to the property directly?
There is no "merit" in it. Saying
self.popoverController =
[[UIPopoverController alloc] initWithContentViewController:content];
would be absolutely equivalent.
On the other hand there is nothing wrong with using a temporary variable (aPopover) as shown in your example. It's just a name (a pointer); there is no significant waste of space or time. Moreover, saying self.popoverController repeatedly (either to set or to get its value) is to be avoided, because this is a method call - you are passing through the setter method or getter method (which may be synthesized, may have side effects, and does in fact take some extra time). Thus, when there is much configuration to be done (for example), it is best to do it as shown in your example:
UIPopoverController* aPopover =
[[UIPopoverController alloc] initWithContentViewController:content];
// lots of configuration here, using the local automatic variable aPopover...
// ...and then, only when it is all done, call the setter:
self.popoverController = aPopover;
The only reason for that is that you probably read this in a tutorial somewhere. And the author did it for readability for beginners. You could absolutely use:
self.popoverController = [[UIPopoverController alloc] initWithContentViewController:content];
All depending on how familiar you are with programming in general and how readable you want your code to be.
I agree with the others that, in this case, the assigning of the popover controller to a local variable before later assigning it to a class property is largely a stylistic matter. But this is only the case because you are keeping a strong reference to that popover controller. There are other situations where you have weak properties, in which this local variable pattern is critical.
For example, let's assume that we have a bunch of controls that we're going to add to our view controller's view programmatically:
#property (nonatomic, strong) UIView *containerView;
#property (nonatomic, strong) UILabel *usernameLabel;
#property (nonatomic, strong) UILabel *emailLabel;
// and more labels
When you want to add these to your view controller's view, you could do something like:
- (void)addSubviewsAtPoint:(CGPoint)location
{
self.containerView = [[UIView alloc] initWithFrame:[self frameForContainer:location]];
[self.view addSubview:self.containerView];
self.usernameLabel = [[UILabel alloc] initWithFrame:[self frameForUsernameLabel]];
[self.containerView addSubview:self.usernameLabel];
self.usernameLabel.text = self.username;
self.emailLabel = [[UILabel alloc] initWithFrame:[self frameForEmailLabel]];
[self.containerView addSubview:self.emailLabel];
self.emailLabel.text = self.email;
// etc.
}
But it also means that when you remove the subviews, you not only have to remove the container view from your view hierarchy, but you also have to remember to nil all of the properties for all of those subviews:
- (void)removeSubviews
{
[self.containerView removeFromSuperview];
self.containerView = nil;
self.emailLabel = nil;
self.usernameLabel = nil;
// etc.
}
This introduces a maintenance issue, that every time you add a new control via addSubviewsAtPoint, that you also have to remember to add it to removeSubviews, too, or else you might be hanging on to the control well after you've removed it from the screen.
To simplify your life, you might make all of these properties weak (with the intuition being that it's the view that owns these subviews, not the view controller):
#property (nonatomic, weak) UIView *containerView;
#property (nonatomic, weak) UILabel *usernameLabel;
#property (nonatomic, weak) UILabel *emailLabel;
// etc.
But now, using ARC, your addSubviewsAtPoint no longer works, because when you assign an object to a weak property, if there are no other strong references, it will be immediately become nil:
self.containerView = [[UIView alloc] initWithFrame:[self frameForContainer:location]];
[self.view addSubview:self.containerView]; // FAIL!!! self.containerView will be nil!
So, instead, we employ that local variable pattern of your question to ensure that the controls are not prematurely deallocated while we're adding them to our view:
- (void)addSubviewsAtPoint:(CGPoint)location
{
UIView *containerView = [[UIView alloc] initWithFrame:[self frameForContainer:location]];
[self.view addSubview:containerView];
self.containerView = containerView;
UILabel *usernameLabel = [[UILabel alloc] initWithFrame:[self frameForUsernameLabel]];
[containerView addSubview:usernameLabel];
usernameLabel.text = self.username;
self.usernameLabel = usernameLabel;
UILabel *emailLabel = [[UILabel alloc] initWithFrame:[self frameForEmailLabel]];
[containerView addSubview:emailLabel];
emailLabel.text = self.email;
self.emailLabel = emailLabel;
// etc.
}
And, as a result, because we're using weak properties, our removal of those subviews is now much simpler, as we don't have to nil all of those properties when we remove the containerView from our view controller's view:
- (void)removeSubviews
{
[self.containerView removeFromSuperview];
// because all of those `containerView` subviews were `weak`,
// we don't have to manually `nil` them
}
I have these two properties defined in my appDelegate:
#property (nonatomic, strong) UIView * mainView;
#property (nonatomic, strong) MyCustomClass * customObj
What is the best way of adding subviews to mainView from code inside customObj?
I am not providing any sample code because (a) my code is terrible and (b) I just want to understand the best approach of doing this, so I can learn from this in the future, rather than having one solution to one specific problem.
Many thanks.
well, what about creating a method in MyCustomClass like this:
-(void)addSubViewToView:(UIView *)view
{
[view addSubview:otherView];
}
And then call it like this:
[customObj addSubViewToView:mainView];
It depends on what kind of class MyCustomClass is. Is it responsible for building mainView's view hierarchy? Then I'd inject a reference of mainView to customObj, like this:
customObj = [[MyCustomClass alloc] initWithView:mainView];
In this scenario, customObj would be some kind of builder object, that creates the view hierarchy inside mainView. Then I'd use the addSubView: selector inside MyCustomClass:
-(id)initWithView:(UIView*)view{
if(self = [super init]){
[view addSubView: ...];
[view addSubView: ...];
[view addSubView: ...];
}
}
I cant seem to figure out how to set a scrollview's delegate as a viewcontroller within the scrollview.
ChildView *child = [[ChildView alloc] init];
_scrollview.delegate = child;
My child view controller is using the scrollview delegate:
#interface ChildView : UIViewController <UIScrollViewDelegate>
But it won't call scrollViewDidScroll;
- (void)scrollViewDidScroll:(UIScrollView *)scrollView {
NSLog(#"%f", scrollView.contentOffset.y);
}
Basically, I would like the scrollview offset of a scrollview to be passed to a view controller nested within it.
There are several ways you can assign a property in Objective C.
Assign means to simply performs a variable assignment and sets one variable equal to another. You won't be able to use the variable if it goes out of scope. This is typically only used for C primitives.
Weak tells the compiler to keep a reference to the object as long as someone else points to it strongly.
Strong tells the compiler to keep a strong reference to the given object. This means that the object won't go out of scope until the object holding it goes out of scope.
As #Aaron pointed out, delegates properties are set using assign. This means that if the variable you are setting the delegate to goes out of scope, the reference becomes invalid. To remedy this, you have to keep a strong pointer to the object around so that it does not go out of scope.
To do this, create a property in your main view controller:
#property (strong, nonatomic) ChildView * child;
Then, when you create the child view, set the property equal to it.
self.child = ChildView *child = [[ChildView alloc] init];
Now you can set the delegate and it won't go out of scope once your function terminates.
_scrollview.delegate = self.child;
child is getting deallocated by the time the delegate method fires.
From UIScrollView.h:
#property(nonatomic,assign) id<UIScrollViewDelegate> delegate; // default nil. weak reference
This is a weak reference, so it won't be retained. To fix it, create a strong #property in your main view controller, and set it to child.
If I know a UIView has been added to a parent, is there a native way to access the parent from within the child?
eg.
[self parent] // returns parent UIView
Sure: UIView has the superview property.
You could try UIViews property superview
[self superview]
in the Childs .h create a property for the parent:
ParentView *parentView;
#property (nonatomic, retain) ParentView *parentView;
(make sure to #synthesize your property in Childs .m)
then, when you alloc an instance of child imediatly asign self to the parentView property
in Parent .m:
Child *child = [[Child alloc] init];
[child setParentView:self];
then you can access the Parent view from the Child with:
[self parentView];
I run the analyse build on Xcode, and get a warning for a leak because of an object that is a property and instance var
.h
UIView *_transparentView; }
#property (nonatomic, retain) UIView *transparentView;
.m
#synthesize transparentView = _transparentView;
self.transparentView = [[UIView alloc] initWithFrame:transparentViewFrame];
- (void)dealloc {
[_transparentView release];
so I release the ivar on dealloc, but how to release the property?, [self.transparentview release] ??
As Tom has answered replace the line that assigns the "transparentView" with:
self.transparentView = [[[UIView alloc] initWithFrame:transparentViewFrame] autorelease];
when you any value to a retained property you should you should release the assigned value if you are done with it, and release the property when deallocating the class.