I'm using the sectionIndexTitlesForTableView method for my custom UITableView, to display A-Z on the side of my table. However, the standard view of this doesn't match the style of the table. Is there a way to change this, or at least move the index a little?
Here's how it overlaps:
I too tried the same thing..but not succedded.
but as a workaround we can introduce spaces before the text which we want to display as a section header, so that we can start index with some gap.
Related
How does one implement a NON alphabetical index for a UITableView? An example of this can be seen in Apple's Remote App. When looking at songs, there is a dotted index on the right hand side that allows the user to scroll quickly through the entire table. There are also no section headers.
Thanks
I'd guess that it works by returning an array full of the “middle dot” character (Unicode 00B7), bookended by the “bullet” character (2022). In the Remote app, the index has 23 items in it; therefore, to do this, you need to split up your data into 23 sections of roughly equal length. As occulus says, returning nil or #"" in -tableView:titleForHeaderInSection: will cause no section headers to be shown.
Return the aforementioned array of characters in your data source’s -sectionIndexTitlesForTableView: method, then implement -tableView:sectionForSectionIndexTitle:atIndex: to return the section index it gives you, and you should get identical behavior to Remote’s.
If you specify #"" for a section title, the section header won't be shown, which will give you the effect you desire. To use table indexing (the right hand side tiny list), you should still organise your table in sections so it knows where to jump when a index is touched, you just have to hide the section titles as I described.
To add index items, see UITableViewDelegate's method:
- (NSArray *)sectionIndexTitlesForTableView:(UITableView *)tableView
Thanks to this post I now know how to make a table with different row heights on iPhone. (With UITableView)
How to do this on a Mac?
Should I use NSTableView? How about NSCollectionView? I feel like NSTableView is too complicated - at least much more complicated than UITableView. I mean, I don't need all the headers and stuff.
Here's an example. Imagine a todo list. Some todos can be pretty long and won't fit in one row. What would you do on iPhone, iPad and Mac?
NSTableView is the equivalent object to UITableView, though it is a bit more complicated. If you don't need headers you don't have to display them, anyhow.
Should I use NSTableView?
Yes.
How about NSCollectionView?
Yes.
It depends on what you're doing. If you're displaying a one-dimensional collection of objects, especially in a form similar to the Finder's icon view, then you want NSCollectionView. If you're displaying a table where each column displays an aspect of each row (e.g.: rows = people; columns = name, title, department, etc.), then you want NSTableView.
In an NSCollectionView, you can set the minimum and maximum item size as a property of the view, and you can set the size of each item as a property of the item.
In an NSTableView, you can set the height of a row by being the table view's delegate and responding to tableView:heightOfRow:. If you want to return the usual row height, ask the table view for its rowHeight and return that; if you want to return an unusual height, do so.
Personally, I find NSTableView easier to work with. You can set it up most if not all of the way in IB; about the only time you need to write any code is for custom drawing, double-click actions, or, yes, variable row heights.
For your to-do list example, I would use an NSTableView, with a checkbox button cell in one column for the “done” property.
I'd like to add section headers to my grouped table view's sections but I'd like them to appear seamless (see image). The default, as we're all well aware of, is rounded top corners on the first row of a grouped table view cell so it ends up looking like crap when you merge them.
Any way to specify when indexPath.row = 0 that the UITableViewCell should use row style "middle" or something like that?
If not then what are my options? I guess I could scratch the section header and use Row 0 as a quasi-header then push my array data +1 to fill the rest of the table? I'd rather not roll my own from scratch...if possible.
Sample Table http://img35.imageshack.us/img35/8181/sampletable.png
Edit:
"Crap" looks like this:
alt text http://img25.imageshack.us/img25/9748/crapsection.png
Don't do what you're doing, it's against HIG
Ok, ok, I'll tell you how to do it:
You're going to want to do your own cell background views. The default grouped one is not what you want.
When a tableview asks you for a cell, set its backgroundView and selectedBackgroundView to something that looks appropriate for its place in the tableview.
Usually, this means a UIImageView with the appropriate image, though you can go wild here with a custom view, but there are gotchas.
So in your case, you would do
if (indexPath.row > sectionRowCount - 1) {
//Not the last row
//Put in the middle background
} else {
//Put in the end background
}
Then you'll want a custom table section header, but that's pretty easy.
In your case, you probably won't have to worry about when there's just one row, so that makes things even easier.
Take a look at the tutorial here:
cocoa with love basically what you need is 3 different images. One for the top row, one for the bottom, and a 3rd for the middle rows.
You could also not use the section header, but instead use a custom cell as the first cell of the section. So when ([indexPath row] == 0), return a custom cell that is the "header" and then return the "regular" cells (offset by one row) for the rest. You'll also have to make adjustments to the numberOfRowsInSection function to return +1.
I have my UITableView set up (in the standard way) to allow deletion on swipes. Whenever I have a sectionindex showing, however, the "Delete" button appears /below/ the section index:
Perhaps I'm missing something obvious?
I've tried setting the selected cell to be less wide in willBeginEditingRowAtIndexPath, but this removes the seperator line below the cell too (i.e. the line is part of the cell, so doesn't draw in the area outside the cell's new bounds).
The solution we used is to remove the index when the table is in editing mode (the other option is, obviously, don't use both table features in the same table).
I have a UITableView with some empty sections. I'd like the user to be able to move a row into them using the standard edit mode controls. The only way I can do it so far is to have a dummy row in my "empty" sections and try to hide it by using tableView:heightForRowAtIndexPath: to give the dummy row a height of zero. This seems to leave it as a 1-pixel row. I can probably hide this by making a special type of cell that's just filled with [UIColor groupTableViewBackgroundColor], but is there a better way?
This is all in the grouped mode of UITableView.
UPDATE: Looks like moving rows into empty sections is possible without any tricks, but the "sensitivity" is bad enough that you DO need tricks in order to make it usable for general users (who won't be patient enough to slowly hover the row around the empty section until things click).
I found that in iOS 4.3, the dummy row needs to have a height of at least 1 pixel in order to give the desired effect of allowing a row to be moved into that section.
I also found that the dummy row is only needed in the first and last section; any sections in between don't have this problem.
And it looks like in iOS 5.0, no dummy rows or special tricks are needed at all.
While managing the edit, you can monitor if the table view is in Edit Mode. Use that flag inside of cellForRowAtIndexPath to decide weather or not to display the 'blank' row. While in 'regular' mode, the row will not display, but when the user taps 'edit' cellForRowAtIndexPath should get called again and this time decide to display the row. The details of how to do that depend on your data source and how you are gluing it to the display. If you aren't getting the call again, you can manually inject rows with insertRowsAtIndexPaths / deleteRowsAtIndexPaths and/or call reloadData to force a refresh.
I found that if you return -1.0 from the heightForRowAtIndexPath method it will remove the 1 pixel line.