For performance reasons, I draw the strings for my UITableViewCell in a custom view that overrides its drawRect method to draw strings directly in the view rectangle using NSString:drawInRect. This is similar to Apple's TableViewSuite Example 5-CustomTableViewCell.
However, when I invoke setEditing on the cell to bring up the delete button, the view ends up with a squeezed appearance after the animation completes. To demonstrate this, invoke setEditing:YES on the CustomTableViewCell example mentioned above and observe the distortion. Is there any way around this or should I just revert back to using UILabels for my text?
I had a similar problem with a UIView inside a UITableViewCell. I solved it by changing the UIView's contentMode to UIViewContentModeLeft. (I wrote it up here, with screenshots.)
I had this problem too, and in my case I fixed it by handling the 2 states in my drawRect method, one while editting, the other while not. In other words I accounted for the size of the delete button, and got my UI to repaint the cell differently. I'm not sure if it's the most efficient way to go, but here is the code that I used to force a repaint:
-(void)_refreshTableAndCells{
//refresh the table
[myCustomTableView reloadData];
//refresh all the visible cells
for (UITableViewCell *cell in myCustomTableView.visibleCells){
LocationCellView *locationCell = [cell.contentView.subviews objectAtIndex:0];
[locationCell setNeedsDisplay];
}
}
I'm an Objective-C n00b though, so I'd be more than happy for someone to suggest a better way than this.
I usually just modify the x and width values (or whatever else) of whatever I want to be different when editing or not. UITableView automatically calls layoutSubviews when you begin editing, so you don't have to loop through your cells and do it yourself.
- (void)layoutSubviews {
[super layoutSubviews];
CGFloat editingPadding = 5.0;
self.textLabel = CGRectMake((self.editing ? self.textLabel.frame.origin.x + editingPadding : self.textLabel.frame.origin.x), self.textLabel.origin.y, (self.editing ? self.textLabel.frame.size.width - editingPadding : self.textLabel.frame.size.width), self.textLabel.frame.size.height);
}
Try setting the contentMode of your own custom view (which resides inside the cell's contentView) to UIViewContentModeLeft. The "squeezing" is due to the fact that the default contentMode is UIViewContentModeScaleToFill.
Related
I'm trying to use Autolayout and Interface Builder to create a custom TableViewCell. I setup my cell in viewDidLoad like this:
[tableView registerNib:[UINib nibWithNibName:#"BChatCell" bundle:Nil] forCellReuseIdentifier:#"ChatCell"];
Then I dequeue the cell like this:
- (UITableViewCell *)tableView:(UITableView *)tableView_ cellForRowAtIndexPath: (NSIndexPath *)indexPath {
BChatCell * cell = [tableView_ dequeueReusableCellWithIdentifier:#"ChatCell"];
return cell;
}
When the table view first loads it loads correctly:
However, after the table scrolls, Autolayout breaks:
Here are the constraints:
Any help would be greatly appreciated.
I had the exact same issue. Drove me crazy because everything looks great until the cells get reused.
I discovered that the view that was getting resized was not the cell itself (which is always screen width), but an inner content view I had. You're able to print all the constraints on any view with NSLog(#"%#", [theView constraints]); which helped with debugging
Also tried to no avail:
setting all the important views and subviews to translatesAutoresizingMaskIntoConstraints=NO
manually setting bounds inside -(void)prepareForReuse
calling setNeedsUpdateConstraints
The issue was that I had named my inner card view "contentView" which is already a named view in UITableViewCell. Changing it fixed the resizing issue.
The problem with your approach is the static leading and trailing. Your trailing constant is 200 and when you rotate it you want it to become more than that 200 (because of the width of the screen). This breaks the constraint and probably in the console is saying that you have ambiguity in your constraints and it did the automatically add a new one (which results in weird behavior).
So what I suggest is that to try making the trailing constraint Greater than or equal 200 and see if it works.
Another solution would be adding a width constraint for that blue view and removing the trailing constraint.
I hope this helps!
I have an iPhone app in which I'm using a UITableView to format a set of text responses, one per row. I've set up the cell in the storyboard to have a label inside it, and set up a constraint saying that the label should be 10 points from the edge of the cell. I then set up a custom subclass of UITableViewCell, set the cell in the storyboard to be of that class, and connected the outlet.
However, when I load the table, I see the text in the cell moving slightly to the right under some circumstances: when I select the cell, or when I load additional cells into the table. In fact, in the latter case, sometimes everything gets shifted to the right, even cells which were already there!
What the heck is going on here? The only changes I'm making in tableView:cellForRowAtIndexPath: are to the text in the label, and I'm always setting it. And I've unset "Indent While Editing" on the cell in the storyboard.
Answering some of the questions: I'm setting the view up using the storyboard. Xcode isn't reporting any ambiguity with the constraints. Also, here are the screenshots, before and after:
My guess is that the constraints for the label are ambiguous. Ambiguity can make UI components jump around for inexplicable reasons. You probably need to set more constraints for the label to define its position on both axes.
Or, maybe all you need to do is set the label to the "size that fits content" (intrinsic content size) under the Editor menu in IB.
Did you add a new label to the UITableViewCell, or are you working with the textLabel that already exists in it? If you added a new one, consider removing it and using the cell's existing textLabel property instead. If that's not an option for some reason, double-check that the label you've added is in the contentView of the cell, and that all the constraints are relative to the parent view, not to the cell itself.
Also, for debugging, you could set the cell's contentView background color to red (cell.contentView.backgroundColor = [UIColor redColor];) - this might give you a better sense of what's moving, the label or the whole view.
This is just a guess without seeing your code. I had a similar problem once, when the app reused an existing cell, the dimensions of the label were not correct. So, I had to remove the old label in my cellForRowAtIndexPath method, before adding a new label. Here's how I removed the old one:
UIView *oldLabel = [cell viewWithTag:3];
if (oldLabel != nil)
{
[oldLabel removeFromSuperview];
}
Then I added a new label like this:
[cell.contentView addSubview:newLabelOrWhatever];
It might be worth checking to see that your string content doesn't have a space prefixed on it. Also, you could verify the actual position of the label by setting the background color.
I had a similar issue when the label would move when the cell was selected. It was a custom cell that I was loading from a custom Nib.
In the Nib I had not set the backgroundView of the UITableViewCell (superclass) to any view. Once I set it (I set it to the ContentView) the issue stopped.
My auto-layout constrains seems fine and had no issues, so I'm assuming it was the above that fixed it.
If you have a custom subclass of UITableViewCell, try implementing layoutSubviews. Let me try from the top of my head:
static CGFloat const kLeftMargin = 10.0f;
- (void) layoutSubviews
{
[super layoutSubviews];
/* Prepare for processing */
CGSize cellSize = self.bounds.size;
/* Change the textLabel frame */
{
/* Compute the new label frame */
CGSize labelSize = self.textLabel.bounds.size;
CGFloat xCoor = kLeftMargin;
CGFloat yCoor = roundf((cellSize.height - labelSize.height) / 2.0f);
CGRect labelFrame = CGRectMake(xCoor, yCoor,
labelSize.width, labelSize.height);
/* Set the new label frame */
self.textLabel.frame = labelFrame;
}
}
Now, this isn't what is usually recommended (since a lot of people use Storyboards and NIBs), but from experience, if you want some correct layouting done, implement layoutSubviews.
Is there any message I can override called when a Table Cell goes away (on scrolling the table)?
I think it should be something like dealoc.
I'm asking this because I have below situation:
I have a table with many cells (100+) and each of this cell contains a ImageView. For loading the image (from a URL) I'm using NSOperationQueue/NSInvocationOperation. The problem appears when user is scrolling the table before the image is completely loaded: because I'm reusing the cells the image is displayed in wrong cell.
To avoid this I'm thinking to use "cancelAllOperations" of NSOperationQueue object when the cell goes away.
Note: I've tried but is not working if I call this message on "prepareForReuse".
iOS 6:
- (void)tableView:(UITableView *)tableView didEndDisplayingCell:(UITableViewCell *)cell forRowAtIndexPath:(NSIndexPath *)indexPath {
// Cancel operation here for cell at indexPath
}
Why not keeping the images in your table data source - the array that holds all the data for the table?
This way you won't have to load these images once again when scrolling back and it will solve your problem...
You can subclass UITableViewCell (or any UIView) and override willMoveToWindow:. It is called whenever the cell appears (or scrolls off screen).
When it goes out of the window the parameter will be nil:
- (void)willMoveToWindow:(UIWindow *)newWindow
{
[super willMoveToWindow:newWindow];
if (newWindow==nil) {
// Cell is no longer in window
}
}
If there were, it would be in the UITableViewDelegate class reference: http://developer.apple.com/iphone/library/documentation/UIKit/Reference/UITableViewDelegate_Protocol/Reference/Reference.html#//apple_ref/occ/intf/UITableViewDelegate
The only thing they have is willDisplayCell which lets you do last minute adjustments BEFORE the cell appears. They don't have anything for when it disappears, but you could probably figure that out since there are only a certain number of cells on the screen at a time for a given cell height.
So if one is appearing and for a cell height of 80 for instance (in portrait mode so 480px screen height), then you can say that the one 6 cells away is about to disappear (6 cells * 80 pixels = 480). There are a couple other things to consider like which way you are scrolling, but you get the general idea.
Example Code: You should also look at lazy table loading via Apple's sample code http://developer.apple.com/iphone/library/samplecode/LazyTableImages/Introduction/Intro.html
I had the same issue and got some nice feedback in the developer forum. Quinn - The Eskimo from Apple:
As an aside, cancelling a network
small transfer because something has
scrolled off the screen is probably a
performance negative. For small
transfers, it's usually more efficient
to let it run to completion (and cache
the results in case they're needed in
the future). This is because of the
way that NSURLConnection manages HTTP
connection reuse. If you cancel a
transfer, NSURLConnection has to
either a) drop the underlying HTTP
connection on the floor, which means
it can't be reused, or b) continue
reading and just junk the data.
Neither of this is the best use of
resources.
Share and Enjoy
-- Quinn "The Eskimo!"
So, I'm not cancelling all the ImageDownload Operation, but rather only start them, when the user stops scrolling. Up to then only a placeholder is shown:
- (void)scrollViewWillBeginDragging:(UITableView *) tableView
{
self.dragging = TRUE;
}
- (void) scrollViewDidEndDragging: (UITableView *) tableView willDecelerate: (BOOL) decelerate
{
if(!decelerate && self.dragging)
[self loadThumbsForVisibleCells];
else
self.dragging = FALSE;
}
- (void) scrollViewDidEndDecelerating: (UITableView *) tableView
{
[self loadThumbsForVisibleCells];
}
Hope this helps!
This question already has answers here:
Closed 10 years ago.
Possible Duplicate:
Can you animate a height change on a UITableViewCell when selected?
I've been doing a lot of Googling to try to figure out the correct way of doing this, and so far I am at a loss.
I have subclassed UITableViewCell with my own view and I am trying to animate the height of a UITableViewCell to expand when it is selected, and to contract when it is selected again. This table has the potential to contain thousands of rows, so I don't want to override the tableView's heightForRowAtIndexPath. Ideally I'd like to be able to have more than one cell expanded at a time, but that isn't as critical. What is the best way to do this?
Thank you,
Justin
There is no other mechanism for specifying cell height than heightForRowAtIndexPath. Unless you're properly accounting for the expanded cell in that method you're going to find your other cells either running over it or hidden under it. From boneheaded code where I forgot to set up heightForRowAtIndexPath, I'm pretty sure your other cells will be displayed over it.
Since you're talking thousands of rows, we'll assume the user can't rearrange the cells.
What you could do is store the expanded cell's index path when the user taps a given cell. Then, heightForRowAtIndexPath might look like this:
- (CGFloat)tableView:(UITableView *)tableView heightForRowAtIndexPath:(NSIndexPath*)indexPath
{
if ([indexPath isEqual:lastSelectedIndexPath])
{
return 80;
}
else {
return 44;
}
}
If you really want multiple selections, you could store the appropriate index paths to an array and check for them like this:
- (CGFloat)tableView:(UITableView *)tableView heightForRowAtIndexPath:(NSIndexPath*)indexPath
{
CGFloat cellHeight = 44;
for (NSIndexPath *expandedIndexPath in expandedIndexPathsArray)
{
if ([indexPath compare:expandedIndexPath] == NSOrderedSame)
{
cellHeight = 80;
break;
}
}
return cellHeight;
}
Getting the animation to look right will take some work. I've toyed with this particular UI idea for awhile now and could never bring myself to sit down and really make it happen. One thing you could do is display a dummy view that animates while you're updating the tableview behind it.
- (void)reloadRowsAtIndexPaths:(NSArray *)indexPathswithRowAnimation:(UITableViewRowAnimation)animation
could be of interest for this as you might be able to use the cell animations to simulate movement of the cells below to accommodate your expansion.
If you can forgo animating the cell's frame altogether, you could do an opacity animation of the expanded data once the new height has been set.
It's a toughie but if you make it work I bet it'll be pretty cool. Good luck.
In my app, I would like to resize the tableview's height when it's in edit mode vs when it's not (in order to make room for editing controls below the table view)
How should this be done?
I found that manipulating the "bounds" property can result in some unexpected behavior when you have a floating table inside another view. Sometimes the table expands upward when increasing the height, even though the origin is still 0,0.
The "frame" property might be more effective:
CGRect tvframe = [tableView frame];
[tableView setFrame:CGRectMake(tvframe.origin.x,
tvframe.origin.y,
tvframe.size.width,
tvframe.size.height + 20)];
You need to set the bounds of the tableview:
CGRect tvbounds = [tableView bounds];
[tableView setBounds:CGRectMake(tvbounds.origin.x,
tvbounds.origin.y,
tvbounds.size.width,
tvbounds.size.height + 20)];
You can implement the table view delegate's tableView:willBeginEditingRowAtIndexPath: and tableView:didEndEditingRowAtIndexPath: to figure out when a given row (and thus the table) goes into and out of editing mode, respectively.
From there, you can just tweak the value of the frame.size.height property of the table view (optionally inside a UIView animations block) as appropriate. It may also be helpful to check the editing property of the table view as a whole inside the delegate methods, in case you receive multiple calls to either delegate method before receiving any calls to their complementary methods.
More info:
UITableView: editing property
UITableViewDelegate: tableView:willBeginEditingRowAtIndexPath: method (didEndEditing is also in this document)