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.
Related
I am developing my first app for OSX. Sorry for asking stupid questions. I have spent a few hours trying to figure this out on my own, with no luck so far.
I want to make an iTunes-like interface. I used NSSplitView, placed NSView for navigation and NSTableView above that. [I am aware that there better alternatives to NSSplitView, yet my goal is to both - develop an app and also to learn Cocoa/OSX in the process.]
Atop NSView panel designated for navigation, I am trying to place NSTableView. However, my table is not being displayed. I therefore have questions...
I understand that for cells to be populated, controller must implement NSTableViewDataSource. I tried that, but was so far unsuccessful - to the point that I don't see the table. Please advise:
Can I have a working NSTableView-derived custom class also implementing NSTableViewDataSource? If this cannot work, please advise why or point me to an explanation.
Am I correct in thinking that all elements can be manipulated programmatically, in the sense that I use IBOutlet in headers to point to the right object, yet do nothing with InterfaceBuilder - have everything controlled from within my Objective-C code? Do I have to use IB?
Thank you.
Yes that will work but it's an unusual approach. Generally the tableview delegate/datasource is something enclosing the tableview. You'd normally only subclass NSTableView if you require some additional functionality not provided by default (for me that has been custom behaviour to input).
Yes you can do it all programmatically, however you will find it much easier to use IB. The IB-loaded views are created programmatically under the hood, using the information contained in the nib file. You will find it long-winded and tedious pretty quickly.
WRT to your issue with not seeing the table, you will need to add logging/breakpoints on the few key delegate/datasource methods to ensure they are being called (start with the daddy of them all numberOfRowsInTableView:). If they are not then you aren't setting the delegate/datasource correctly in the tableview.
My iPad and iPhone interfaces use a UICollectionView and a UITableView respectively. In each case, there is a lot of commonality:
each has the same number of sections (hard-coded)
each section has the same number of respective rows/items (derived from the same data source)
each has identical cell content (these are custom views built using auto layout so are suitable for both cases)
each has identical section headers and footers (again, custom content)
each can respond to certain notifications in the same way (e.g. when new data is received, refresh the data source) but with custom parts also (reload the UITableView vs reload the UICollectionView)
each will present the same controllers via cell selection, though the UITableView will push the new controller and the UICollectionView will use a popover.
I am using a shared parent class to cater to some of this. This approach seems especially well suited to the data requirements - the parent class builds the data and is responsible for maintaining it. I use two subclasses to present the data - one with a UITableView and the other UICollectionView.
The presentation side is a little less clean. To take the simplest example, when the table/collection view needs to know the number of sections, in each case I am relying on a customized method in the parent:
return [super sectionsCount]
This allows me to set many values only once and have both views updated.
Then comes the part that is working poorest. Again, to simplify, consider the header view for the first section. In both cases, this should be identical. I have a custom UIView subclass that I want to use, with a couple of properties that will be set the same. The problem here is that the re-usable header for a table view section expects a UITableViewHeaderFooterView and the counterpart for a collection view expects a UICollectionReusableView. So to accommodate this, I'm having to create subclasses of these simply to hold the header view I want in both. So in summary:
What I want: UITableView and UICollectionView should use the same UIView subclass as the header for section. The custom properties of that view should be set identically in each case.
What I am having to do:
Build the required UIView subclass for the header.
Build a UITableViewHeaderFooterView subclass that holds one such header. It's init does nothing more than add a header view.
Build a UICollectionReusableView subclass that equally does nothing more than add a header view.
When the collection view needs a header, create an instance of the UITableViewHeaderFooterView subclass. Set its properties.
When the table view needs a header, create an instance of the UITableViewHeaderFooterView subclass. Set its properties.
Once I have to do this for footers, and especially cells, things are getting kinda icky. I have three times the classes I should need, and I'm repeating all of my code for setting custom properties of the view.
How can I best re-use this logic between the UICollectionView and UITableView?
You can just create stock UICollectionReusableViews, UITableViewHeaderFooterViews, etc. and add your custom view as a subview. If you need to access the custom view later, you can set its tag property and use [view viewWithTag:].
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.
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.)
I've got an NSTableView that displays (via bindings) data from an NSTreeController. The application frequently appends/changes data to/in the bound array.
The problem is that if the user has selected a row in the table, but has scrolled so that the selected data is no longer visible, when the application updates the array it causes the display to auto-scroll so that the selected line is once again on screen. This is pretty
frustrating to users, especially since new data can arrive at any time.
Is there any way of disabling this feature?
You may have to subclass NSTableView and override -scrollRowToVisible:, temporarily bracketing the call to super. This may also require a custom BOOL ivar in your subclass to keep track of whether you want to scroll.
I would start by setting a breakpoint there to see when exactly the autoscroll is triggered. This should help to find the proper moments to toggle the ivar.
Are you using an NSTreeController with an NSOutlineView or an NSArrayController with an NSTableView? Using an NSTreeController with an NSTableView doesn't make a lot of sense to me?
If you're using an NSTableView you should probably be using an NSArrayController to manage its data and this rearranging of the rows is a feature of the NSArrayController. Try turning off the Auto Rearrange Content option on your controller within IB.
When it's on, the array controller will rearrange its objects on addition, removal and changes to objects that would affect the sort ordering (if any) and cause any table views or outline views to reload their data.
I don't know of a similar feature for NSTreeController mainly because I don't use it since it's never worked well for me. I, sadly, recommend to just use the datasource methods for the NSOutlineView and supply your data the old-fashioned way. In my experience, NSTreeController is only well suited for the most trivial tasks.