I want to add about 300 grids to a UIView,It is OK if I use 300 UILabels?
Or,besides UILabel,any better way to deal with it?
Grid means what you can make a UITableView with 300 rows and you can make any number of labels in your UIView
Perhaps start here. Other than that, I don't see a problem with UILabels, with that count, it might get slower though. Imagine how many objects you will be rendering...
If you create a UITableView with reusable cells, only the visible cells will be populated at any one time, so only those UILabels (assuming one or more per cell) will actually exist at any one time. Not a problem.
Related
I was asking here about the option to make a collectionView with multiple cells since our cells have a different appearance for different indexs.
The answer was not sufficient because other then just create multiple cells and pick one for every index, you have all sorts of problems such as :
How can you register multiple classes ? collectionView.register(FlowViewCell.self
Reusable cells system gets crazy because they are different
Every action you do on a cell must be identified with its class and it becomes a mess.
So, I am searching for another way to do so with a single cell.
What would be a good way to set different buttons in the same position of a cell, and show/enable a different button with different indexes ?
So for index 1 I have 2 circle buttons, and for index 2 I have one large wide button? if you just put them on the same spot and hide one you get a strange design.
The answer you linked is what you are looking for.
We use 4 different types of cell in our app and we don't have any problem with it.
You don't have to register multiple classes, you can all create them in your storyboard (inside the collectionview), the system will register the classes for you.
And then you call the cells like explain in the answer.
The hard part is having different sizes, we only have two (large cell and square cell, so two square cells fit on the same level), more than that would be tricky, especially different height.
But apart from that you can have different content on each cell without any problem.
My tableview add blank space to the end of the cells.
I don't know why, how do I fix this problem? (For ex I have 50 cells, two of them you can see here because this is last two cells)
Hard to know without seeing your code, but because your cells have varied heights, you should probably start by implementing tableView:heightForRowAtIndexPath:
If you end up wanting more manual control over the table's height, take a look at its contentSize property.
I'm looking to change the number of columns my tableview has without subclassing it. Any suggestions?
I think you can find your happiness here: http://usxue.is-programmer.com/posts/14176.html
With that you can create a Grid and have multiples columns
If you don't need to select individual columns the you could just subclass UITableViewCell to make it LOOK like it has more than one column.
Doing this without subclassing anything would need to be done as follows:
1) Place a UIScrollView in the view.
2) Put n amount of UITableViews embedded in the UIScrollView where n is the amount of columns desired.
3) Turn scrolling off in all of the UITableViews.
4) Make all of the UITableView frames equal to that UITableView's contentSize.
5) Set the UIScrollView's content size equal to the largest UITableView's frame.
I have not tested this because I would definitely recommend subclassing either UITableView or UITableViewCell, but this would be one way of doing it.
Background - I have a custom UITableViewCell layout. Each cell will have a number of UILabels with a variable number of rows of UILabels. For the sake of argument conside 3 columns of UILabels (different widths), and a variable number of rows depending on the data.
To best allow for content view size changes (e.g. edit mode, change in orientation etc) I was going to manually layout each of the UILabels in the cell in the "layoutSubviews" method, effectively setting up their exact positions. I thought this way they will be laid out appropriately for events such as EDIT mode, orientation change etc.
Question - I'm wondering whether from a performance point this is the best approach? Or should I be looking at somehow predefine the UILabel rows, one predefined set for portrait mode and another set for landscape mode? (not exactly sure of how this would be done, but I'm trying to describe an approach where the layout would not have to be re-calculated when orientation changes etc)
thanks
suggestion by RickMaddy elsewhere was good:
"Why have a variable number of rows of labels in a single table row? Have one row of labels per table row. Then the problem is easier and performance won't be an issue."
I thought I had read that for a UITableView that heightForRowAtIndexPath doesn't get called on all rows, but only on the ones that will be visible. This isn't what I'm seeing however. I'm seeing hundreds of calls to heightForRowAtIndexPath for the simple situation of the orientation being changed of the iPhone for example.
So I'm assuming here therefore that for a UITableView with heightForRowAtIndexPath implemented, it does (i.e. heightForRowAtIndexPath) get called for all rows (not just the visible ones)...let me know if this isn't quite correct.
QUESTION: Given the above, how many rows in a UITableView (where heightForRowAtIndexPath is implemented) can you have before performance issues occur typically?
Is there a way around the performance issues? i.e. set a nominal/standard height for each row and not implement heightForRowAtIndexPath, but then correctly set each row height only when it is displayed and set it correctly here...but which method would one do this in?
Have a look at the discussion section in the tableView:heightForRowAtIndexPath: documentation
The method allows the delegate to specify rows with varying heights. If this method is implemented, the value it returns overrides the value specified for the rowHeight property of UITableView for the given row.
There are performance implications to using tableView:heightForRowAtIndexPath: instead of the rowHeight property. Every time a table view is displayed, it calls tableView:heightForRowAtIndexPath: on the delegate for each of its rows, which can result in a significant performance problem with table views having a large number of rows (approximately 1000 or more).
So you should use the rowHeight property of the UITableView. If you need different heights you are out of luck because you have to use tableView:heightForRowAtIndexPath:.
AFAIK there is no way to change the row height at display.
The tableview has to know the correct size before, otherewise there would be ugly position shifts all the time.
I think I found a solution to that.
In iOS 7 apple introduced some new tableview properties. One of them is the:
tableView:estimatedHeightForRowAtIndexPath:
So if you supply an estimated row height, for example, then when tableView:heightForRowAtIndexPath: is called repeatedly before the table is displayed, it is called only for the visible cells of the table; for the remaining cells, the estimated height is used.
Here is the source for that information: https://books.google.gr/books?id=wLaVBQAAQBAJ&pg=PT521&lpg=PT521&dq=heightforrowatindexpath+only+for+the+visible+cells&source=bl&ots=7tuwaMT5zV&sig=h3q8AaFvoCgcrPu2fQchVkIEjwg&hl=en&sa=X&ved=0CEMQ6AEwBWoVChMInLK0xbPuxwIVCbUaCh3_nQWG#v=onepage&q=heightforrowatindexpath%20only%20for%20the%20visible%20cells&f=false
My goodness, I spent over an hour trying to find the source of my performance problem!
Finally I also found hundreds of calls to heightForRowAtIndexPath and a search
got me this thread. THAT is really annoying.
Performance goes down here already when just displaying 250 items. Thankfully the cells I want to display now all have the same size. But I could imagine someone wanting to display some different cells for a tableView with > 200 items!
FIX THIS APPLE!
Cheers
A way to improve performance in tableViews with a big number of rows and dynamic cell heights is to cache the height of the cells once they are first calculated.
A simplistic approach to achieve this is to keep a NSMutableDictionary in which the key is the id of the record in the cell (or any other identifier you might have), and the value is a NSNumber with the height of the row. Once the height is first calculated, store it the NSMutableDictionary by the record id. In the tableView:heightForRowAtIndexPath and tableView:estimatedHeightForRowAtIndexPath: you check for a cached height in the dictionary and return it if found. If not found, calculate the height, and store in the cache before returning the height.
You might have to be careful with invalidating the cache for the rows that change heights. For example, if you have an expand button in one of your cells, you will need to remove the height of that cell from cache once the expand button is tapped delegate method for height is called.
You might still have a performance hit if you try to display 1000 of cells at once when the table shows, as it will likely call the height method for each row. A work around for that is to first warm the cache, if possible in a background task, before first displaying the cells.