Hello all – I'm getting into iPhone development and have hit my first confusing UI point. Here's the situation:
My app is tab-based, and the view that I'm confused about has a static featured content image at the top, then a dynamic list below into which X headlines are loaded. My goal is to have the height of the headline table grow as elements are added to it, and then to have the whole view scroll (both featured image on top and headline list below). So, I guess my question comes in two parts:
1) First, how do you set up a dynamic-height table view that will grow as cells are added to it. So far I've only been able to have my tables handle their own scrolling.
2) Then, what is the root NIB view that the featured image and the table should live in to enabled scrolling? I've dropped oversized content into a UIScrollView now, although did seem to have any success with having it automatically scroll.
Thanks in advance for any help on this subject!
To the first:
As i understand your situation:
You want to add a image to the top of the UITableView and the image should scroll with the UITableView, shouldn't?
The UITabeView has a property called tableHeaderView. It's just a view, so you can set a UIImageView to it.
(I have no xCode at the current time, you need to edit the code)
UIImage *image = [UIImage imageNamed:#"myCoolPic.png"];
UIImageView *imageView = [[UIImageView alloc] initWithImage:image];
imageView.frame =CGRectMake(0,0,width,height);
tableView.tableHeaderView = imageView;
[imageView release];
What you're asking is probably doable with Interface Builder (or not, I don't know) but I know the code way to do it.
To change the height of the table all you do is set the frame of the UITableView object. The default height of a UITableViewCell is 44 I believe, so set it to multiples of that depending on how many cells you have. Of course your cells can be any height so you will need to keep track of what you report in heightForRowAtIndexPath and set the table frame accordingly.
UITableView will certainly live in a UIScrollView and both components can scroll. The table view needs to become a subview of the scroll view, so does the image. Then you will scroll the table if you drag on it directly or scroll the scroll view if you drag the image or the scroll view.
For the first question, I'm a little confused by the way you ask it: "how do you set up a dynamic-height table view that will grow as cells are added to it." Table views have a function that it calls before the table is fully loaded with data called "numberOfRowsInSection." So the number of cells is based on that function, and should you update the variable used to determine the return value of that function (usually [myArray count]) it should automatically find the right size for the whole table.
However, variable height cells are something that I found kinda tricky and I've solved it using the following:
There are some UIKit NSString additions that you might find useful.
http://developer.apple.com/iphone/library/documentation/uikit/reference/NSString_UIKit_Additions/Reference/Reference.html
Particularly the sizeWithFont: functions.
Table views also have a 'heightForRowAtIndexPath:' function that is called 'numberOfRowsInSection' amount of times. Each call determines the height of the cell at the indexpath.
So, for example: (assuming myArray is an array of NSStrings)
-(CGFloat)tableView:(UITableView *)tableView heightForRowAtIndexPath:(NSIndexPath *)indexPath { return [[myArray objectAtIndex:indexPath.row] sizeWithFont:myFont];}
This will return a height based off of your actual data, piece by piece. There are other functions to specify how the text wraps and truncates, etc. as well.
It doesn't feel like a great solution because you end up fetching your data twice, once to determine the height, and then again when you configure the cell in 'cellForRowAtIndexPath:' However, it does work!
I've learned a lot in the past few weeks and have gone through a few iterations of addressing this problem. My first solution was to manually measure the table height, then set the table rect to display at that height, and finally to set the scrollView's content rect to encompass the the table and top feature. What that solution did basically work, I started encountering some display issues when branching out into new views with different toolbar configurations. It seemed that my manual frame size was interfering with iPhone's native content scaling.
So, I scrapped the manual sizing and went to just making that top feature block be a custom table cell that displayed within its own section at the top of the table. I made a hard logic definition that section 0 only had one table cell, and that cell was my custom layout that I linked in through Interface Builder. I was then able to get rid of ALL my messy custom scaling logic, and the whole system is cleaner, smoother, and works reliably.
Related
I've been struggling with this now for a little while, and I want to make sure I'm doing this the right way. For reference, I am using AutoLayout with Storyboards, and it's an iOS7-only app.
I have a UITableView with a header-view, and the UI for the HeaderView is hooked up in the storyboard. I've left the header in the storyboard, and it contains a few elements, one of which is a non-scrollable UITextView.
Here is a screenshot of how it basically looks in the storyboard:
I darkened the header-view's background to a darker grey so it stands out.
The UITextView's text can be dynamic, so its height needs to change depending on the size of the text. But the tricky part is that the table's header-view needs to adjust its height as well, depending on this text's size. I've tried a few different things with constraints, but it's not really working correctly (unless I disable AutoLayout and re-size things programatically, which I really would like to avoid).
I want this to be as clean as possible with as little code as necessary, of course. I am not tied to using the table-view header, although it works well with my needs, since I want it and its containing textview to scroll with the actual details below. But that all being said, if there is a more simple approach to accomplishing this (i.e. with a uilabel), I will gladly change the underlying structure.
Any thoughts as to an approach? Not looking for someone to hold my hand through an answer; just looking mainly for some good starting points if possible. Thanks in advance!
Some time ago I found new solution, maybe it needs tweaking for animations and is experimental, but, for some range of cases it's fine, so give it a try:
Add a headerView to a UITableView.
Add a subview to headerView, let's call it wrapper.
Make wrapper's height be adjusted with it's subviews (via Auto
Layout).
When autolayout had finished layout, set headerView's height to
wrapper's height. (see -updateTableViewHeaderViewHeight)
Re-set headerView. (see -resetTableViewHeaderView)
Here's some code:
- (void)viewDidLayoutSubviews
{
[super viewDidLayoutSubviews];
[self updateTableViewHeaderViewHeight];
}
/**
tableView's tableViewHeaderView contains wrapper view, which height is evaluated
with Auto Layout. Here I use evaluated height and update tableView's
tableViewHeaderView's frame.
New height for tableViewHeaderView is applied not without magic, that's why
I call -resetTableViewHeaderView.
And again, this doesn't work due to some internals of UITableView,
so -resetTableViewHeaderView call is scheduled in the main run loop.
*/
- (void)updateTableViewHeaderViewHeight
{
// get height of the wrapper and apply it to a header
CGRect Frame = self.tableView.tableHeaderView.frame;
Frame.size.height = self.tableHeaderViewWrapper.frame.size.height;
self.tableView.tableHeaderView.frame = Frame;
// this magic applies the above changes
// note, that if you won't schedule this call to the next run loop iteration
// you'll get and error
// so, I guess that's not a clean solution and could be wrapped in #try#catch block
[self performSelector:#selector(resetTableViewHeaderView) withObject:self afterDelay:0];
}
// yeah, guess there's something special in the setter
- (void)resetTableViewHeaderView
{
// whew, this could be animated!
[UIView beginAnimations:#"tableHeaderView" context:nil];
self.tableView.tableHeaderView = self.tableView.tableHeaderView;
[UIView commitAnimations];
}
All this works seamlessly after the initial autolayout pass. Later, if you change wrapper's contents so that it gains different height, it wont work for some reason (guess laying out UILabel requires several autolayout passes or something). I solved this with scheduling setNeedsLayout for the ViewController's view in the next run loop iteration.
I've created sample project for that: TableHeaderView+Autolayout.
I would suggest setting the height programatically.
You can calculate the hight of the textview with boundingRectWithSize:options:context
Then you just set the frame of the tableViewHeader.
As said above, in UITableView the height for the header is not controlled by auto layout but by
-(CGFloat)tableView:(UITableView *)tableView heightForHeaderInSection:(NSInteger)section
Footer height is set by
-(CGFloat)tableView:(UITableView *)tableView heightForFooterInSection:(NSInteger)section
And finally cell height is set by
-(CGFloat)tableView:(UITableView *)tableView heightForRowAtIndexPath:(NSIndexPath *)indexPath{
The tableview loads the cells from storyboards, XIB files or code. It uses the above methods to set the size of the frame for the headers, footers and cells, and sizes their views to fit in that space.
It's important to understand that auto layout will not change those sizes, it only handles the rules used to layout the views inside their containers.
If your cells/headers/footers are using static sizes, then it's very easy. You just lock the heights of all your subviews, set up your cell to be the same size you return in heightFor... and everything looks how it should.
Dynamic cells/headers/footers take a bit more work.
Essentially you're asked to tell the tableview the size of your cell/header/footer BEFORE you have actually made it and sized out all the subviews.
You can quickly test this out by setting a breakpoint at the cellForRowAtIndexPath and the heightForRowAtIndexPath methods, the height is called first.
For dynamic tableviewcell heights, a common trick is to create a single cell in viewDidLoad and save it for calculating the heights. Then when you reach heightForRowAtIndexPath or heightForHeaderInSection use the pre made cell to put in the values you will be using in the final cell, for UILabels use sizeWithFont (pre iOS 7) or boundingRectWithSize (iOS 7.0+), and sizeThatFits for UITextViews. (For anybody reading this in the future, check that those methods have not been replaced by something newer)
So get the text you want into the dummy cell, get the heights of the labels and textviews, add the spaces between them and return the final size when you're done.
Then in cellForRowAtIndexPath or headerForSection redo the setting of values but on the actual cell that will show.
If your height calculations match your auto layout settings, then everything will fit perfectly in the space that's made for it.
If you want to change the height of a cell or header after it's already drawn, then you'll want to update the tableview by doing something like:
[self.tableView beginUpdates];
// change the data that will cause cell height to be different in heightForCellAtIndexPath or which will change a header or footer height calculation
[self.tableView endUpdates];
This will cause the tableview to check the sizes it has and only update the cells or header/footer if changed.
A table view header view is given to a table view via the tableView:viewForHeaderInSection: delegate method.
- (UIView *)tableView:(UITableView *)tableView viewForHeaderInSection:(NSInteger)section
{
// create your header view here (read the docs on this method, there are some specific requirements)...
}
I don't know if it's possible to design the header view in storyboard; I guess you'd have to use an individual XIB file or do so programmatically.
In other words, I think you're headed towards creating constraints in code if you need to provide table view header views.
On the other hand, maybe you don't really need a table view header view. Maybe, what you're after is just a subview above the table view that doesn't move when the user scrolls the table. To do that, you need to re-work your view hierarchy in IB. Right now your so-called header view is inside the table view. You don't want that.
Or, since it looks like you're using static cells, you could make the top static cell take on the appearance of your so-called header view.
I have a scrollView and on that scrollView, i have many labels and textView along with one tableView. scrollView is working perfectly fine when the no. of rows are less in tablView but if tableView have more number of rows then i am not able to full content and even i am loosing lots of information in tableView because the tableView isn't scrollable. i have added all the lables, textView and tableView as a subview of scrollview. Can anyone help me in that so i can get full tableView and make it proper scrollable.
Here is my code to set the content size of scrollView.
float maxHeight = 0;
for(UIView *v in [self.scrollView subviews]){
if(v.frame.origin.x + v.frame.size.height > maxHeight)
maxHeight = v.frame.origin.x + v.frame.size.height;
}
self.scrollView.contentSize = CGSizeMake(_scrollView.frame.size.width, maxHeight+100);
First you'll need to resize your table, so that it fits all the rows (since as you said, it's not scrollable). I believe that doing so will make all your rows to not be reusable, so if it's a big table you may get performance issues. Also be aware of #David H's answer, so if you really want to do this, you might be better of using another UIScrollView instead of the UITableView (it won't bring much benefit either way).
Second, you'll need to move all the views beneath the tableview, so that they won't overlap. An easy way to do this is to have those views put together in a different view, so that you only need to move one view instead (in this case however, you'll also need to resize that view accordingly).
Finally, instead of looping through all the scrollview's subviews, it should be easy enough to keep track of the view that is closest to the bottom (this depends on how you generate and add the views to the scroll view).
A tableview is a scroll view subclass, and generally Apple says adding it to another scroll view will cause problems. That said there are ways to make it work. Search here or on google for terms like "how to put a uitableview in a uiscrollview".
EDIT: to make it not scrollable you could put a transparent view over the table view that stops or eats touch events.
self.scrollingView.contentSize=CGSizeMake(320,372);
Try this.
Currently I have UITableViewCell's that hold sometimes really long text (up to 50,000 pixels in height after drawing). However the UITableView delegate documentation says that cells shouldn't be higher than 2009 pixels in height (any ideas why?).
It's only the first section in my table view that has the really long cell, so instead of using a cell for the first section, I thought I'd create a UIScrollView, put a UITextView as the first "cell" and add it to the scrollView, and then add the tableView to the scroll view as well (under the textView). However, having a 50,000 px high UITextView is causing huge memory problems.
What are my options? I know I could use a UITextView that scrolls, but to have a scrollable UITextView with a tableView just causes complicated scrolling behavior. I want to mimic the scrolling of a tableView.
I didn't know it would be an issue to have a 50,000 px high view in a UIScrollView. I thought that's what UIScrollView's are for? Do I have any alternatives?
I would seriously question the UI design where you must render text that large as part of a table cell. The best option would be to put a reasonably-sized summary in a cell with cell.accessoryType = UITableViewCellAccessoryDisclosureIndicator;, build a separate view for the long text, and let the user navigate to that view by clicking the disclosure indicator.
As a side note, you could also put a scroll view inside the initial table cell (not all cells must be of the same type; you can make one with a scroll view in it, and use it for the cell at index zero). It's not going to be as usable as the regular cell with a disclosure indicator, though.
On an iPhone, how do you figure out the width of a table view cell's content view when it is showing a certain accessory view (disclosure indicator, etc)?
I need this in order to calculate the correct cell height for cells that contain wrapping, variable-length text. But when the table view delegate is asked for a cell height, it doesn't actually have the actual cell instance, so it can't just query the content view bounds directly.
I can easily hard-code a 20-pixel margin on the right which appears to be accurate for a plain style table view in portrait orientation with a disclosure indicator, but would prefer to do it the Right Way so that it keeps working if Apple decides to tweak the margin.
(This is related to this question.)
Personally, I would just hard code the values -- simpler and things will break in a predictable way.
But were I to do this programmatically, I would create a UITableViewCell, set up the editing properties / accessory views you need to measure, and then ask it how big its contentView is.
Of course I would probably heavily cache this -- doing allocations when asking UITableView asks you for height information sounds to me like it would be slow (check with a profiler first though, as always).
I would have a subclass of UITableViewCell that holds all its subelements. You can cange the frame of certain elements when the cell enters and exists editing mode. There is a good example of this in Apple's Table View Programming guide under the section on creating a custom table view cell.
I believe the UITableViewCell's contentView property is the view that contains your labels etc., so the width of that should be your available size to use.
I want to resize my table view cells from inside the cell instead of from the UITableViewDelegate. I am resizing them based on asynchronous content, so I can't size them in the delegate.
I tried setting self.frame inside the cell, but the table view was really unhappy about that. Cells were overlapping and all kinds of craziness was going on.
You simply have to use the table view to control height. You can tell the table a cell has altered by using the calls to remove and then re-add specific cells, so you don't have to reload the whole table - but the height has to be fetched using the delegate callback tableView:heightForRow:atIndexPath:
I don't see why this is not practical though. You can have any number of asynch systems running that update a central height cache held by the table view delegate - every time you create a cell you can assign it the delegate as a reference so it has a way to talk back to the table and let it know cells need reloading and what the new heights are.
If you think about it, the poor table view is a scroll view that has to manage all these separate cells and keep them together visually - so it's really unkind of a cell to go rogue and start altering frames without letting the table view know what is going on anyway. It's best to let the table drive and tell it what to do.
No you can not set the cell's size without using the UITableViewDelegate. Changing the size of the cell with actually change the size of the cell, but it will not change the offsets that the UITableView draws the cells with. Which will result in overlaps, and gaps all over the place.
Your friend is tableView:heightForRowAtIndexPath:, and it should be fast. If you override it, then the table view can no longer make the assumption that all rows are of the same height. And thus it must query all rows for their height each time it fetches cells to draw.
You should try to manage the cells contentView propertys frame, instead of the cells frame itself
heres a reference http://developer.apple.com/iphone/library/documentation/UIKit/Reference/UITableViewCell_Class/Reference/Reference.html#//apple_ref/occ/instp/UITableViewCell/contentView