Different custom cells in a single UITableView? Sensible?
Hi all!
I'm writing a little app to display news. I have a UITableView with a single type of custom cell inside. But for the top news item I want to make it stand out.
I want this cell to scroll as normal with the rest of the content - but I only want the styling to apply to a single item of data.
I'm thinking I could achieve this by having 2 custom cells. So in -tableView:cellForRowAtIndexPath and -tableView:heightForRowAtIndexPath I would just have some kind of if statement to decide the size and which cell class to render.
I'm just wondering is this sensible? How might others go about this?
Depending on how many rows you have in your table, having different cell heights may or may not work. If you have a lot of rows (several hundred) you could run into issues... because your heightForRowAtIndexPath method will be called for each one, and you don't have much time at startup to handle all these calls before the OS will decide to kill your app.
What would scale better would be to figure out a way to just have a single row height, and then just draw the cell differently for the first row (bolded font, or different colors, or something, while keeping the same row height).
__________________ Recall It!Tag your notes. Tag your photos. Tag your thoughts. Tag your life.
Really depends on how good you are at managing your cells. We have custom cells, but don't go to the extent of changing the heights. We found it is easier to manage the more things you can "keep constant". We of course override the drawRect routine to custom draw everything in the cells. Everything but the background color that is.
Thanks for all the responses guys - really interesting.
Yeah - I didn't know if there was a better way, I'm all very new to this so it's great to hear from all the experts. I guess the more rows the more expensive drawing custom cell heights can become. I imagine in my case there won't be more than 50 items so that should be manageable. I actually implemented it and it seems to work very nicely.
I've been looking at different news apps - and they take different approaches. FT.com, Tweetie (if you can call it news) - have variable size rows, whereas Byline, Telegraph, ITN and NYTimes have fixed heights. I honestly think a mobile user wants more information upfront with as little clicks as possible, so cutting-off sentences mid-flow doesn't quite work for me...
It's not so much the expense of drawing cells at different heights... it's just that if you have variable row heights, the OS will ask you the height for each row in your table up front (presumably so it knows how to properly draw the scroll indicator while the user is scrolling through the table).
But if you are only going to have 50 rows... or even a couple hundred... you should be fine. Although if you have to actually calculate different row heights for each row (like to figure out how much room you need to fully display snippets of text on a row-by-row basis), you might still run into performance issues that could cause your app to get killed.
__________________ Recall It!Tag your notes. Tag your photos. Tag your thoughts. Tag your life.