I'm trying to get a UIScrollView to work correctly inside of a UICollectionViewCell.
The custom cell is being loaded in via a xib file and is a subclass of UICollectionViewCell. I had problems getting other controls working, such as a button and a gesture recognizer since the UICollecitonView doesn't seem to be passing any touches to the cells, but I got around those with gesture recognizers on the UICollectionView itself. The one remaining issue I have is the UIScrollViews...
The UICollectionView scrolls horizontally, and the UIScrollView in the cells scroll vertically. I've tried using a UIPanGestureRecognizer to scroll them, but that seems to disable the UICollectionView's ability to scroll.
Anybody have any thoughts?
EDIT: Got it!
So I had converted to a collection view from a previous third party library we were using before iOS6. Turns out the problem was with the xib files we were using for the cells. With the library before, the cells were just subclasses of UIViews. I changed the classes to subclass UICollectionViewCell, and updated the Custom Class. Turns out this was not enough. In order for touches to get passed to the cells I needed to actually had to drag in a new UICollectionViewCell from the Object library, copy over all the subviews and reconnect the IBOutlets. After this, it worked!
I fixed this in my code by making sure resizing of the scroll view happens on main thread.
My collection view is using nsfetchedresultscontroller that is using block calls to refresh selected cells. On the first time a cell was selected the scrollview would not scroll. However if you clicked on another cell and clicked back it would work fine. The initial load of the cell seemed like size calc might not be where it needed to be on main thread to affect behavior.
-(UICollectionViewCell *) collectionView:(UICollectionView *)collectionView cellForItemAtIndexPath:(NSIndexPath *)indexPath {
UICollectionViewCell *cell = [collectionView dequeueReusableCellWithReuseIdentifier:#"CustomCell" forIndexPath:indexPath];
dispatch_async(dispatch_get_main_queue(), ^{
// resizeScrollViewMethod should be where scrollview content size > scroll view frame.
[cell resizeScrollViewMethod];
});
return cell;
}
- (void) resizeScrollViewMethod {
//Do your scrollview size calculation here
}
No problem with UISCrollView in UICollectionViewCell. Use StoryBoard and you'll scroll OK.
UIScrollView overlay UICollectionViewCell, so that didSelect work only when tap outside ScrollView and inside Cell (scrollView.frame < cell.frame).
If you want to implement tap or other gesture, just add it to UIScrollView in awakeFromNib
Refer code:
https://github.com/lequysang/github_zip/blob/master/CollectionViewWithCellScrollViewStoryBoard.zip
Related
I have used this tutorial to put a collectionView inside a UITableView. https://ashfurrow.com/blog/putting-a-uicollectionview-in-a-uitableviewcell-in-swift/
The UITableViewController is the dataSource & delegate for both the UITableView & the different collection views in each cell.
The problem is that I want to dynamically hide the CollectionView and to change its height to 0 whenever the collectionview is empty.
To do so, I have this code in CellForRowAtIndexPath
if (patients.paraclinicImage.count == 0){
[cell.collectionView setHidden:true];
cell.collectionViewHeight.constant = 0;
} else {
[cell.collectionView setHidden:false];
cell.collectionViewHeight.constant = 80;
}
By having this code, the collectionView shows up correctly initially. However, when scrolling fast, I will sometime have the cell load with the correct cell height, however the collection view will be empty. Refreshing the cell fixes this issue. Removing the above line of codes also fixes the issue.
Here are two images showing how the cell looks when first rendered, and after multiple scrollings (and re-renderings of the cell).
Before scrolling issue looks like below image
But After scrolling issue seems to like below one
I would appreciate any ideas you guys might have.
Debug view hierarchy showing an empty collectionView with an appropriate cell height
It is because your cell height is not updated on fast scrolling. UITableView caches the row height of indexPath just to calculate the scroll area. You need to set constraints properly and adjust the height of cell in heightForRowAtIndexPath: method.
Apply the logic inside heightForRowAtIndexPath: and your problem will be solved.
Happy Coding!!
I had the same issue. Sometimes, my collection view inside a tableviewcell wouldn't show the collectionview cells. I solved it by calling collectionView reload on main thread. I don't exactly know the reason, as I have many background calls on each cell and was reloading the tableview on main thread itself. Still, had to reload collectionview on main thread.
DispatchQueue.main.async {
cell.colViewProperties.reloadData()
}
Given the following scenario:
There is a UICollectionView containing UICollectionViewCells (naturally). Each UICollectionViewCell contains a UIButton with a target action associated with it.
Problem:
The UICollectionView does not scroll upon swipe/drag. The UIButtons instead intercept touches, and make it difficult to drag the UICollectionView.
Additionally:
The UIButtons are set to UIControlEventTouchUpInside
The UICollectionView is set to canCancelTouches = YES
**Why are the UIButtons inside UICollectionViewCells preventing the UICollectionView from responding to drag/swipe gestures? **
The reason that the UICollectionView doesn't scroll properly is because the UIButtons are intercepting and rerouting the responder chain.
Solution:
Remove the UIButtons from the UICollectionViewCell.
Instead use the delegate method for UICollectionViewDelegate :
- (void)collectionView:(UICollectionView *)collectionView didSelectItemAtIndexPath:(NSIndexPath *)indexPath
Explanation:
When we added a UIButton to the UICollectionViewCell, we were thinking that the best way to capture a tap was to add a button to the cell. However, by adding the UIButton, we broke the responder chain.
We don't need the button inside the UICollectionViewCell, because the UICollectionViewCell already detects tap events with it's delegate method :
- (void)collectionView:(UICollectionView *)collectionView didSelectItemAtIndexPath:(NSIndexPath *)indexPath
Use the provided method to detect taps on a collection cell, and replace the UIButtons with UIImageView-s or similar.
We don't need the event handing of a button when working with collection cells.
Consider an standard, vertically scrolling flow layout populated with enough cells to cause scrolling. When scrolled to the bottom, if you delete an item such that the content size of the collection view must shrink to accommodate the new number of items (i.e. delete the last item on the bottom row), the row of cells that scroll in from the top are hidden. At the end of the deletion animation, the top row appears without animation - it's a very unpleasant effect.
In slow motion:
It's really simple to reproduce:
Create a new single view project and change the default ViewController to be a subclass of UICollectionViewController
Add a UICollectionViewController to the storyboard that uses a standard flow layout, and change its class to ViewController. Give the cell prototype the identifier "Cell" and a size of 200x200.
Add the following code to ViewController.m:
#interface ViewController ()
#property(nonatomic, assign) NSInteger numberOfItems;
#end
#implementation ViewController
- (void)viewDidLoad
{
[super viewDidLoad];
self.numberOfItems = 19;
}
- (NSInteger)collectionView:(UICollectionView *)collectionView numberOfItemsInSection:(NSInteger)section
{
return self.numberOfItems;
}
- (UICollectionViewCell *)collectionView:(UICollectionView *)collectionView cellForItemAtIndexPath:(NSIndexPath *)indexPath
{
return [collectionView dequeueReusableCellWithReuseIdentifier:#"Cell" forIndexPath:indexPath];
}
- (void)collectionView:(UICollectionView *)collectionView didSelectItemAtIndexPath:(NSIndexPath *)indexPath
{
self.numberOfItems--;
[collectionView deleteItemsAtIndexPaths:#[indexPath]];
}
#end
Additional Info
I've seen other manifestations of this problem when dealing with collection views, it's just that the above example seems the simplest to demonstrate the issue. UICollectionView seems to go into some kind of paralysed state of panic during the default animations, and refuses to unhide certain cells until after the animation completes. It even prevents manual calls to cell.hidden = NO on hidden cells from having an effect (hidden is still YES afterwards). Dropping down to the underlying layer and setting hidden there works, provided you can get a reference to the cell you want to unhide, which is non-trivial when dealing with cells that haven't been displayed yet.
-initialLayoutAttributesForAppearingItemAtIndexPath is being called for every item visible at the time of the call to deleteItemsAtIndexPaths:, but not for the ones that are scrolled into view. It is possible work around the issue by calling reloadData inside a batch update block immediately afterwards, which appears to make the collection view realise that the top row is about to appear:
[collectionView deleteItemsAtIndexPaths:#[indexPath]];
[collectionView performBatchUpdates:^{
[collectionView reloadData];
} completion:nil];
But unfortunately this is not an option for me. I am trying to implement some custom animation timing by manipulating the cell layers & animations, and calling reloadData really throws things out of whack by causing unnecessary layout callbacks.
Update: A bit of investigation
I added log statements to a lot of layout methods and looked through some stack frames to try and find out what's going wrong. Crucially, I'm checking when layoutSubviews is called, when the collection view asks for layout attributes from the layout object (layoutAttributesForElementsInRect:) and when applyLayoutAttributes: is called on the cells.
I would expect to see a sequence of methods like this:
// user taps cell (to delete it)
-deleteItemsAtIndexPaths:
-layoutAttributesForElementsInRect:
-finalLayoutAttributes...: // Called for the item being deleted
-finalLayoutAttributes...: // \__ Called for each index path visible
-initialLayoutAttributes...: // / when deletion started
-applyLayoutAttributes: // Called for the item being deleted, to apply final layout attributes
// collection view begins scrolling up
-layoutSubviews: // Called multiple times as the
-layoutAttributesForElementsInRect: // collection view scrolls
// ... for any new set of
// ... attributes returned:
-collectionView:cellForItemAtIndexPath:
-applyLayoutAttributes: // Sets the standard attributes for the new cell
// collection view finishes scrolling
Most of this is happening; layout is correctly triggered as the view scrolls, and the collection view properly queries the layout for the attributes of cells to be displayed. However, collectionView:cellForItemAtIndexPath: and the corresponding applyLayoutAttributes: methods are not being called until after the deletion, when layout is invoked one last time causing the hidden cells to be assigned their layout attributes (sets hidden = NO).
So it seems that despite receiving all the correct responses from the layout object, the collection view has some kind of flag set to not update the cells during the update. There is a private method on UICollectionView called from within layoutSubviews that seems responsible for refreshing the cells' appearance: _updateVisibleCellsNow:. This is from where the data source eventually gets asked for a new cell before applying the cells starting attributes, and it seems this is the point of failure, as it is not being called when it should be.
Additionally, this does seem to be related to the update animation, or at least cells are not updated for the duration of the insertion/deletion. For example the following works without glitches:
- (void)addCell
{
NSIndexPath *indexPathToInsert = [NSIndexPath indexPathForItem:self.numberOfItems
inSection:0];
self.numberOfItems++;
[self.collectionView insertItemsAtIndexPaths:#[indexPathToInsert]];
[self.collectionView scrollToItemAtIndexPath:indexPathToInsert
atScrollPosition:UICollectionViewScrollPositionCenteredVertically
animated:YES];
}
If the above method is called to insert a cell while the inserted cell is outside the current visible bounds, the item is inserted without animation and the collection view scrolls to it, properly dequeuing and displaying cells on the way.
Problem occurs in iOS 7 & iOS 8 beta 5.
Adjust your content insets so that they go beyond the bounds of the device's screen size slightly.
collectionView.contentInsets = UIEdgeInsetsMake(-5,0,0,0); //Adjust this value until it looks ok
Problem:
I used custom UITalbeViewCell that contains two buttons, they work fine in the portrait orientation. After the rotation, they all stop responding to the button touch up inside function. Some people having problems that their buttons couldn't drew correctly after rotation. Mine looked fine since the buttons are showing in the right places after rotation, but they do not respond to the button press anymore.
For this specific view in my app, I used a UIPageController to implement multi pages in a view, and for the view (name it EmbeddedView for now) embedded in the page's scroll controller, there is a UITableView that contains custom UITableViewCell. Custom table view cell only has a nib, the file's owner is EmbeddedView.
in EmbeddedView:
- (UITableViewCell *)tableView:(UITableView *)tableView cellForRowAtIndexPath:(NSIndexPath *)indexPath
{
/*===== This is the most memory efficient way of creating table view cells =====*/
static NSString *CellIdentifier = #"CellIdentifier";
CustomTableViewCell *cell = (CustomTableViewCell *)[tableView dequeueReusableCellWithIdentifier:CellIdentifier];
if (cell == nil)
{
[[self customTableCellNib] instantiateWithOwner:self options:nil];
cell = [self customTableCell];
[self setCustomTableCell:nil];
}
}
What I tried:
I created another nib file for the custom table view cell and used it in -cellForRowAtIndexPath(), I checked the orientation and dynamically create the cell by using different nib, no luck.
I added [tableview reloadData] in -didRotateFromInterfaceOrientation(), didn't do anything.
Would someone point me to the right direction please? Any help is appreciated.
This is the table view Autosizing in IB:
It looks right but the buttons are not working
Update: I tried to specify different Autosizing masks in IB for the table view, and the results are showing below:
<1>
<2>
<3>
<4>
Have you checked how the superview is being resized?
Check if the superview has 'clip to bounds' checked. If it is not check it. That will make the view clip its contents so you see if it is resizing ok.
I'd say the superview is not sizing correctly and because of that the touch events are not well delivered also.
EDIT - So this was the tip that could let the OP reach the solution:
What I normally do in cases like of unexpected behavior in resizing and such is to change every view in the hierarchy to a different, well recognizable, color. Right now you have view A and view B with the same background color (or clear) and you don't see if view B is resizing well. Good luck.
I've subclassed UITableViewCell to display a UIImage and two UILabel subviews. In the view controller for the table view, in the method cellForRowAtIndexPath: I've enabled an accessory view via setAccessoryType:UITableViewCellAccessoryDetailDisclosureButton.
Cells display correctly.
When I tap on the accessory disclosure button I want to replace the two label subviews with two different label subviews. My approach was the following:
In the subclassed UITableViewCell, inside layoutSubviews, create the
CGRects for the "alternate" labels, position them in the same
places as the two "original" label and hide them via setAlpha:;
When the disclosure button is tapped swap out the set of two
label by adjusting their respective alphas.
The problem is I can't figure out what logic in layoutSubviews I'd use to know whether the accessory button has been tapped. I see that in the view controller accessoryButtonTappedForRowWithIndexPath: is called when that button is tapped and from there it seems like I would call layoutSubviews but can't figure out how to use that fact to accomplish what I'm trying to do.
Am I going about this all wrong? Instead of hiding/showing CGRects with alpha should I simply be creating another subclass of UITableViewCell?
When I tap on the accessory disclosure button I want to replace the two UILabel subviews with two different UILabel subviews.
I'll do the following. Create a public method in your UITableViewCell subclass like the following:
- (void)changeContentForCell;
In this method you could set the contentView as you prefer.
Then in your view controller implement
- (void)tableView:(UITableView *)tableView accessoryButtonTappedForRowWithIndexPath:(NSIndexPath *)indexPath
{
CustomCell* cCell = (CustomCell*)[tableView cellForRowAtIndexPath:indexPath];
[cCell changeContentForCell];
}
This is a simple example for change the content. In my opinion you don't have to use layoutSubviews to add views.
Leave this logic in changeContentForCell and then call setNeedsLayout to change your layout. Maybe you could have a variable that tracks the state for your cell: normal state or modified state.
Hope it helps.