I have a simple case of an iOS application I would like to measure: a UITableView built with custom extended cells. Each cell is a composition of a main views and some subviews. Based on some criteria I am hiding or showing subviews in table cell.
Supposing I have to decide if adding subviews when needed, or built xib with all the outlets and hide/show when needed.
What could be the best approach for deciding between those two ?
Supposing also you didn't read Apple guidelines about composition of cell, what concrete steps you would do either via code (by putting NSLog statement for example), or via Xcode instruments (which one to choose etc...) to confirm the choice.
This is quite a new matter for me, so please be as much specific as you can.
This http://blog.giorgiocalderolla.com/2011/04/16/customizing-uitableviewcells-a-better-way/ is a great resource.
Having many subviews with transparent backgrounds degrades scrolling performance.
Dynamically adding subViews could get difficult to track, and if you don't do it "right" then you'll end up with cells with too many "extra" subviews, via the cell reuse queueing mechanism.
You'll have to add the subViews in the init method of the cell itself and not in the cellForRow method of your data source. (unless you're using some way to track the creation/availability of any given subview, like viewWithTag etc.)
Related
I will be creating a custom control (based on UIView).
Is there a way it could work with UIViewControllers using auto layout as well as UIViewControllers that do not?
The control should work in both cases. The difference is that in one case you will use constraints to layout it and in the other one, setting the frame programmatically.
If your control contains other subviews, it is important how you configure these. For example, if you do the setup of the subviews in initWithFrame: and you use the given frame to layout them (meaning static frames, instead of constraints), in the auto layout viewControllers, the frames will no get updated.
However, layouting the subviews with constraints will have no impact on the non-autolayout viewControllers. The subviews will have the layout according to your constraints, in the given static frame of the custom control.
It is a general explanation since I don't know that much about your particular controller. Hope this makes sense and you can find helpful.
This may be a general discussion instead of a real question. When I started using NSTableView and NSOutlineView, I thought : oh, a instance of NSView may do almost everything. So I return a NSView instance in my delegate and dataSource.
Of couse it did not work and I realized that NSTableView consitsts of instances of NSCell which inherits directly from NSObject.
I sensed that it may be important to understand why Cocoa constructed NSTableView based on NSCell but NSView. But few documents explain it clearly. Therefore I turn to Stackoverflow. Does anyone know that? Thank you at advance!
You can switch to a view based NSTableView or NSOutlineView in the inspector
The reason for a cell based cell would be if your only want to display a string. If you only want to display a string it would be a waste of resources to init a whole view to each cell. It is basically about memory control vs. what you need to display.
#d00dle's answer shows how to use an NSView backed table view, but it doesn't answer the question of why NSTableViews historically used NSCells in the first place.
The answer is that NSViews are heavy objects and expensive to manage. NSTableViews typically need many many rows and columns of "view-like" things, and if you naively added them all as actual NSViews, you can't maintain a responsive UI.
This is reflected in the trickiness Apple added to support NSView-backed table and outline views; it creates a limited number of NSViews and recycles them in clever ways to reduce the total number of NSViews in use at any given moment.
Out of the following, which is the best way to hide a view?
Setting frame to CGRectZero
Hidden Property to YES
alpha Property to 0.0
Does one have benefits that the other does not? In terms of saving resources at runtime? Specifically in a UITableView with reusable cells where some subviews may not be needed by one cell versus another.
It depends on what you want/need to accomplish. For views that will likely be reused alot, a combination of view.hidden=TRUE (my choice for this case) and/or view.alpha=0.0, and maybe manipulate the z-index to make sure your view is no longer at the front.
I am not sure about the benefit of setting the view's frame to CGRectZero, it might be more appropriate to remove the entirely at that point.
In short, if you don't need it, don't keep it.
UPDATE:
With the mention table cells, also consider the possibility of creating multiple custom cells, especially if removing subviews causes layout problems. Each cell can be created based on whatever criteria you have set.
UPDATE 2:
Based on a comment left below, if the cells are complex, drawing the cell via code may be the right solution.
With UIView's, alpha=0 has the advantage of being animatable whereas hidden=YES does not. frame=CGRectZero is also animatable but is quite a different effect. When animating alpha=0.0 will cause the view to fade out whereas frame=CGRectZero will cause it to appear to vanish into the upper left. I wouldn't worry about the system resource expense of any of these techniques as they're all pretty lightweight.
I have a NSTableView that holds a name to all of my NSImageView's, and depending on the order that the NSImageViews were added, the last one would be in the front.
But in the case that I want the user to be able to bring a NSImageViews in front of another, how would I do that?
Thanks in advance.
As explained on the NSView reference page, the z-order of a view's subview is given by their oder in the view's subviews array. You can insert a new subview relative to the others using -addSubview:positioned:relativeTo:, and you can reorder the existing subviews by getting the subviews property, reordering the views therein as you like, and then calling -setSubviews: to set the new order.
Specifically, the docs say:
The order of the subviews may be considered as being back-to-front,
but this does not imply invalidation and drawing behavior.
What you are asking about, I think, is how to control the z-order of views.
For historical performance reasons this is not well supported in AppKit (unlike UIKit in iOS), since until somewhat recently you couldn't actually have sibling views that overlap.
A common approach to this (on recent OS X releases) is to use Core Animation (in particular, CALayer) which does support z-ordering natively, but this is probably overkill for what you need (and in any event is going to have a learning curve for you).
What are you actually trying to do? Are these images (image views) precisely on top of one another? If so, the easiest (and much better performing) approach is to have a single NSImageView and to just send -setImage:... to it to change the displayed image.
Ok, so I have this issue where I need to get access to the headers/footers displayed in a UITableView. Moreover, I need to do this from a subclass of UITableView (so I can't simply assign tags to the view from the UITableView Delegate). UITableView does keep an array of visible headers and footers but it provides no access to those arrays even to the subclass, which I personally think is asinine.
I need this so that I can provide a custom drag-n'-drop insertion/move user interface. I'm trying to get it to work almost exactly like Apple's own rearranging interface, but of course, with my own custom implementation (like the ability to drag from another table). Everything works perfectly except for the headers/footers.
At the moment I'm trying to hack it by iterating through all the subviews of UITableView. I'm pretty sure that the only subviews of UITableView is: backgroundView, UITableViewCells, and Headers/Footers. So I just need to determine which are UITableViewCells (very easy), which is the background view (also easy) and which are headers/footers (not so easy). I'm pretty sure I can do it this way but it's definitely a hack and I'd rather find a better way if possible.
UPDATE
I'm overriding the - (void) setDelegate:(id<UITableViewDelegate>)delegate method and checking to see if the delegate responds to the appropriate selectors to generate headers/footers (and set BOOL's appropriately). This is making it a lot easier to determine what a particular subview is since the progression of header -> cells -> footer is predictable.
You say you can't use UITableView delegate methods, but did you consider letting the UITableView subclass object be its own delegate? Create a separate property on the subclass called realDelegate and pass any other delegate calls through to that.