Could somebody check my thinking here: I'd like to know when a table view is being pulled past the bottom (wish I knew the term for this) ... when the contentInset below the last row is visible and releasing causes a bounce. Here's what I think it is, but I can barely describe it in English, and can't think of a good way to test it....
CGFloat contentBottom = MAX(0, tableView.contentSize.height - tableView.frame.size.height);
BOOL isScrolledToBottom = tableView.contentOffset.y > contentBottom;
It looks right within a few pixels in the debugger, but I feel like I am missing some much simpler way.
Related
I ran into an issue where clipping of subviews is not working consistently (or potentially, the UIView resize isn't working). Here's the scenario:
I have a UIView (section above the line). The actual size is larger to accommodate search bar. I basically resize it on viewDidLoad.
When clicking on the text field, UIView expands and show a search bar
After search, I collapse the UIView, but found that the UIView is not collapsed in certain case (see first image). If I were to not hide the search bar, it will remain also.
Is there any reason why this issue occurs? I'm still trying to debug and see if there is anything that could have caused this issue (as something may reset to original size). It definitely does seem like everything is resized correctly since even the result table is moved correctly also. Something else must have triggered it after the expected resize. Any pointer is appreciated. I've only done iOS development for 5 days so I'm still not aware of a lot of things.
- (void)showAddressField
{
CGRect headerFrame = self.searchHeaderView.frame;
headerFrame.size.height = headerHeight + adjustmentSize;
self.searchHeaderView.frame = headerFrame;
CGRect tableFrame = resultTableView.frame;
tableFrame.size.height = tableHeight - adjustmentSize;
tableFrame.origin.y = headerFrame.size.height + statusBarHeight;
resultTableView.frame = tableFrame;
[self renderHeaderBorder:headerFrame.size.height - 1];
}
- (void)hideAddressField
{
CGRect headerFrame = self.searchHeaderView.frame;
headerFrame.size.height = headerHeight;
self.searchHeaderView.frame = headerFrame;
CGRect tableFrame = resultTableView.frame;
tableFrame.size.height = tableHeight;
tableFrame.origin.y = headerHeight + statusBarHeight;
resultTableView.frame = tableFrame;
[self renderHeaderBorder:headerHeight - 1];
}
EDITED
SearchHeaderView is just a UIView that is a subview of the main view. It's not a table header. I found that if I put a search bar in the table header, it behaves very unpredictably so I have a UIView containing the search portion and have a UITableView right below it.
Sorry, since I only have just over a week to get a rather massive app out from scratch, I didn't have time to wait. I already changed my approach a little bit, but I will still award the points even after the bounty has expired. I'm trying to understand everything to do with layout since that's pretty much the only thing that I can't quite figure out with iOS app development.
If the search bar is in the table view header, try reassigning the header view to the table view:
[tableView setTableHeaderView:self.searchHeaderView];
If it is a section header, be sure to update the value for the delegate's
– tableView:heightForHeaderInSection:
– tableView:viewForHeaderInSection:
Otherwise, please post more code on how the searchHeaderView is initialized and added to the table.
Hope this helps!
Firstly, frames are already relative to the enclosing window. You should not be taking into account the height of the status bar (assuming that refers to the 20px area at the top of the screen).
I have found in the past that you may need to implement "layoutSubviews" in your view controller and compute the frames of the views there. It depends on your resizing mask / if you auto-layout enabled.
As the others have stated, more code would be helpful... or at least the relevant portions of the nib/xib.
I subclassed UICollectionViewLayout. So far, so good.
However, I have some cells that are wider than the screen, and sometimes these disappear while scrolling. When you scroll some more, they magically reappear where they should be. I can show you my code, however I think there's nothing wrong with it since it works in 90% of the cases.. However, really large cells (more than two times the screen size) disappear sometimes.
NSMutableArray* attributes = [NSMutableArray array];
for (int section=0; section < [[self collectionView] numberOfSections]; section++) {
[attributes addObject:[self layoutAttributesForSupplementaryViewOfKind:UICollectionElementKindSectionHeader atIndexPath:[NSIndexPath indexPathForItem:0 inSection:section]]];
for (int row=0; row < [[self collectionView] numberOfItemsInSection:section]; row++) {
NSIndexPath* indexPath = [NSIndexPath indexPathForItem:row inSection:section];
[attributes addObject:[self layoutAttributesForItemAtIndexPath:indexPath]];
}
}
return attributes;
I've also these posts: UICollectionView's cell disappearing and Large cells in a UICollectionView getting removed while the cell is still displayed
However, a solution isn't mentioned. Can anybody help me with this? Could it be the problem is on Apple's side? And if it is, is there anything I can do to solve it myself?
Sorry to tell you: I'm pretty sure this a real bug in UICollectionView; I've run into this exact same thing a few weeks ago. I've made a small program to demonstrate the bug and filed a RADAR with Apple, but haven't heard back on whether or if they plan on fixing it. The best workaround I can think of (Warning: I haven't yet implemented this workaround) is to notice that the layout attributes are very far off the edges of the screen, intentionally change the bounds of the cell attributes so it only slightly goes off screen, and possibly store that offset (the amount that you trimmed off of what the real bounds should be) as an additional custom field in the layoutAttributes, so your cell knows to draw it's content correctly. Which feels like a gross hack, but it ought to work.
Are you sure you return the right attribute object for this cell when method -(NSArray*)layoutAttributesForElementsInRect:(CGRect)rect is called and when the rect is just a part of your cell ?
I'm trying to work with a scroll view controller that needs to adjust it's contents based on user interaction -- specifically, by adding a 'done' button while the user is working with a UITextView, then removing it when they are done. The problem is making room for the button in question. What I'd like to do is...
control.layer.position.x-=50;
for every single control that is 'below' the one I'm working with. Unfortunately, that doesn't work. As far as I can tell, I'm going to have to do something more like...
control.layer.position=CGPointMake(newX, newY);
This creates a maintainability nightmare; instead of being able to rearrange buttons inside UIBuilder at will, I'm going to have to change their positions in the code as well. Unfortunately, no matter what variant of the first type of code I use, the result doesn't work; I'm informed that I need an lvalue to the left of the assign or that I'm trying to manipulate incompatible types.
It'll be more verbose than the -= solution, but why don't you just calculate newX and newY based on their old values?
e.g.
CGPoint oldPosition = control.layer.position;
control.layer.position = CGPointMake(oldPosition.x - 50, oldPosition.y);
The button comes with a center property, so:
button.center = CGPointMake(button.center.x - 50, button.center.y);
should do the trick
Here is my problematique: I design my cell in my UItableView, so I added a title, a little description and an image.
All thoses element are store in my database, so in my UIViewController I calculate every position to have a nice cell, if there is no image in a cell I change the position of the title and the little description.
To check if the image is present or not I do something like that:
if ([fiche linkImg]!=#"") { //draw position of element }
or
if ([fiche.linkImg length] > 0 ) { //draw position of element }
My problem is when I begin to slide in my tableview its very slow and often very often crash, and the error are sometimes:
[CALayerArray listImg]
or
[NSCFArray listImg]:
Any idea?
Your description is a tiny bit confusing to see what is the problem.
I would suggest having a look at how to accomplish adding custom stuff to cell.
Have a read of apple's doc on UITableView especially a closer look at Table-View cells, if you scroll down in that section you will find examples of exactly the type of cells you are trying to create (text with pictures).
Try adding like this
if([fiche linkImg]!=nil)
I tried and succeeded
I am apparently in some swirling UIView hell zone at the moment where up is down sibling is parent and my brain is completely fried.
Here's the deal. Really, really simple. I have a container view with N leaf node sibling subviews. No tricks here, dead simple. I do the following:
// occludedPageSet is the set of view tags corresponding to views that are off screen and // thus fully occluded. This was determined geometrically.
for (NSNumber *n in occludedPageSet) {
// Point to a view corresponding to this tage
UIView *v = [self.containerView viewWithTag:[n integerValue]];
// Hide this view
if (v.hidden == NO) {
NSLog(#"View %d is occluded. Hide it.", [n integerValue]);
v.hidden = YES;
} // if (v.hidden == NO)
} // for (occludedPageSet)
Pretty tame stuff. Unfortunately ALL sibling views vanish! What the?!? How is this possible?
Do I need a [retain]/[release] for v here. I'm stumped.
Baffled,
Doug
Am I missing something about the problem here? It's only natural that if you hide a view, any view it holds as a subview would be hidden as well. After all, you can't see the container view...
If you put ten things in a box and make the box invisible, wouldn't you expect that to mean you couldn't see the things in the box? Similarly an invisibility cloak would be of little use if only the cloak were invisible and not the person beneath...
If you need some things visible and some not, work on the specific items and not the container.
Apparently, all of your views are included in occludedPageSet, or all of your tags are the same n.
NSNumber *n in occludedPageSet
Or, one of the v views is the parent of the rest, so when you hide it, you hide them all.
Make sure self.containerView's tag is something completely different from any of the children's tags. Calling viewWithTag will return the receiver if it is the given tag, which will in turn hide all of your views. Either step through the iteration or print out the address that v points to so that you know you're occluding what you should be occluding.