Is there a way to draw lines between the cells in a UICollectionView? I'm not looking to add a border to each cell, that will result in drawing the lines only if there are any cells in the collection. What I'm looking for is something like UITableView's lines: they are there even if the table view has 0 cells.
I solved this by adding views to the collectionView.
I used the cell frames coordinates to determine where I wanted to draw.
However, there is probably a better way of doing this?
You can create a proper background for UITableView if your cells are of the same height. Draw the pattern image and apply it as a backgroundColor property:
UIImage *patternImage = [UIImage imageNamed:#"pattern.png"];
tableView.backgroundColor = [UIColor colorWithPatternImage:patternImage];
UPD:
Comment to this answer in incorrect. Background will scroll with tableView (or scrollView) content.
Related
I would like to add a border to UICollectionView content so it can move with scroll and fit collection conent. Anyone has any idea how to achieve it? So far I am able to add a border to the whole collection but it is not what I'm looking for (pic).
Here, you have put a border to your collectionView.
If you wanna add a border to your cells, try this:
cell.layer.borderWidth = 1.0;
cell.layer.borderColor = UIColor.grayColor().CGColor;
Before this, make sure your cells are configured.
Is it possible to add a static background to a collectionview because at the moment the background scrolls with the cells and the image looks quite bad.
my code at the moment
collectionView.backgroundView = [[UIImageView alloc] initWithImage:[UIImage imageNamed:#"bg.png"]];
There are 2 ways to do what you're asking.
add the background to the UICollectionView as a subview like you're doing now and implement the scrollViewDidScroll: delegate method. Inside that method, set the frame of the background view based on the contentOffset of the collection view which will make it appear to be static on the screen. You will just need to set the frame's Y origin to be the contentOffset.y and it should work. (If there is a non-zero contentInset you may need to do a bit of additional math to get it right.)
add the background to the superview of your collection view, underneath the collection view. This is an easier and probably more efficient solution since you don't need to mess with the contentOffset at all since the background will not be in the scroll view itself.
if I understand your requirement correctly, here's how you can do it:
1) Add your static image as a subview to the parentView.
2) Set the backgroundColor of collectionView to [UIColor clearColor]
3) Add collection view as a subview to the parentView.
I want to show links between two cells of uiTableView.
For Ex:
To show links between cells 1 and 5, it could be shown like:
Does any one has any idea how this can be achieved. Also when table scrolls, these links should be scrolled with it.
This looks like you want to build hierarchical view. Your implementation might be rejected by Apple due to not taking HIG into account.
Also what will be in case when lower part is not seen to user? Arrow with no end and need to scroll down for the user?
You might want to do a tree like structure (anything hierarchical) instead of ugly (sorry for that) arrows.
If you want arrow between two cell then make a separate UIView class for the Tablecell, in that UIView add one UILabel for text and one UIImageView for arrow, adjust there position as per your requirement.
Now pass this UIView to cell.
Hope this will help you.
UITableViewCell is just a subclass of UIView and UITableView is a subclass of UIScrollView. The only fanciness that UITableView provides is creating/reusing the cells and laying them out in the scroll view. (That's a gross over-simplification but for this It'll do the trick.)
So if I have a UIView subclass that draws an arrow, then it's just a matter of getting the frame for the cells I want to point to. CGRect frame1 = [[self.tableView cellForRowAtIndexPath:indexPath] frame];
Some pseudocode...
topCellFrame = get top cell frame;
bottomCellFrame = get bottom cell frame;
arrow = new arrow view;
arrow set frame = frame with origin of top cell frame origin, and height of distance from topCellFrame to bottomCellFrame;
tableView add subview = arrow;
There are edge cases to think about, If the top cell or bottom cell are offscreen the cellForRowAtIndexPath: will return nil and frame will be CGRectZero.
But I'll leave that as an exercise for you.
Edit: (I haven't done this exact thing, but I have done some similar things with the frames of cells)
I have a grouped tableView in my iPad-app, and I've been trying to set cell.imageView.center = cell.center to center the image instead of putting it to the leftmost position. This is apparently not possible without a subclass of the UITableviewCell(If someone could explain why, that'd also be appreciated.. For now I just assume they are 'private' variables as a Java-developer would call them).
So, I created a custom tableViewCell, but I only want to use this cell in ONE of the rows in this tableView. So in cellForRowAtIndexPath I basically write
cell = [[UITableViewCell alloc]initWith//blahblah
if(indexPath.row == 0)
cell = [[CustomCell alloc]initWith//blahblah
This is of course not exactly what I'm writing, but that's the idea of it.
Now, when I do this, it works, but the first cell in this GROUPED tableView turns out wider than the rest of them without me doing anything in the custom cell. The customCell class hasn't been altered yet. It still has rounded corners though, so it seems it knows it's a grouped tableView.
Also, I've been struggling with programmatically getting the size of a cell, in cellForRowAtIndexPath, I've tried logging out cell.frame.size.width and cell.contentView.frame.size.width, both of them returning 320, when I know they are a lot wider.. Like, all the rows are about 400 wide, and the first cell is 420 or something. It still writes out 320 for all the cells..
This code will not work for a couple of reasons:
cell.imageView.center = cell.center;
Firstly, the center is relative to its superview. I believe the cells superview is the tableView. The imageView's superview will be the content view of the cell. Therefore the coordinate systems are different so the centens will be offset. E.g. the 3rd cell down will have a center of 0.5 widths + 3.5 heights. You should be able to ge around this issue by doing:
cell.imageView.center = CGPointMake( width / 2 , height / 2 );
The second issue is related to how the table view works. The table view manages its cells view's. The width of a cell is defined by the table view's width and the height is defined by the table view's row height property. This means the cell itself has no control over its size.
You can however size its subviews, but you must do this after the cells size has been set (otherwise you can get strange results). You can do this in layout subviews (of the custom UITableViewCell class). See this answer.
- (void)layoutSubviews {
[super layoutSubviews];
self.imageView.frame = ....
}
When layoutSubviews is called the cells frame has been set, so do your view logging here instead of cellForRowAtIndexpath.
As for the GROUPED style. Im not sure if this is designed to work with custom views. I suspect it sets the size of its cells to its own width minus a 20 pixel margin on each size, then applies a mask to the top and bottom cells in a section to get the rounded effect. If you are using custom view try to stick with a standard table view style.
I'm working on an iOS 5 project with storyboards, and thus using dynamic table cell prototypes in IB. In one of the views, I've got a table view with variable-height cells, with the cell height calculated from the height of the contents.
tableView:heightForRowAtIndexPath: returns correct values for all cells when the table view is first displayed. All is well when scrolling down for a few items, but then something goes amiss: the actual cells seem to be correct height, including their touch areas, but their separators are rendered in the wrong places (inside cells instead of between them).
From measuring the separator placement, it appears as if cell reuse might have something to do with this. The separators for the first three cells are rendered correctly, but not the fourth one. heightForRowAtIndexPath: returns the correct height for it (125 pixels in this case), and its contained subviews are all in their right places. However, the separator is rendered only 108 pixels from the previous separator, placing it inside the 125 pixel high area of the cell.
Here's the kicker: 108px is the height of the first table cell, now out of sight and probably reused. I don't have definite proof of this, but it appears that the table view is ignoring heightForRowAtIndexPath: for these cells and is just rendering the separator according to the reused cell height.
This doesn't explain why a bunch of later, shorter cells are not rendered separators at all. But this is all I've got to go on.
Is there a workaround, an IB setting or something else that might help?
I had the same problem where the separators were showing at seemingly random positions.
It turned out the problem was that I was overriding layoutSubviews but forgot to call [super layoutSubviews]. Adding that call fixed the issue for me.
I also met this weird problem. For a custom table cell, add a layer as a separator may be a better choice.
in initWith*** method of the custom table cell class:
separator = [CALayer layer];
separator.backgroundColor = [UIColor colorWithWhite:0.8f alpha:1.0f].CGColor;
[self.layer addSublayer:separator];
update separator's frame in layoutSubviews method:
- (void)layoutSubviews {
CGFloat height = 1.0f;
separator.frame = CGRectMake(0.0f, self.frame.size.height - height, self.frame.size.width, height);
[super layoutSubviews];
}