I would like know the limit of maximum number of rows that can be shown in the UItableView. Thanks in advance.
This Cocoa with Love blog post is very informative - it looks at the performance of a table view with thousands of cells.
The question is whether it has some internal hard limit - it's seemingly enough for most needs - the above post concludes:
The iPhone can handle tables with 100,000 rows — and it continues to scroll as smoothly as though it were only 100 rows.
There seems to be no maximum. You don't insert actively anyway, you just implement the delegate methods to serve the cells - they are not loaded all at once if done properly.
Just having tried it with one thousand custom cells, it worked without a problem. But with 3k even with index it is a lot to scroll, I'd consider putting them into a navigation hierarchy (but this heavily depends on your use).
One more thing: Make sure to be efficient when drawing the cells, i.e. implement drawRect: instead of cluttering the cells with labels, views etc., this will make scrolling much faster.
You will ultimately be limited by the fact that all the methods such as numberOfRowsInSectiin take integer arguments but hopefully you won't need to approach those limits :)
In numberofRawInSection delegate method we are generally return count of array which is Int type, so maximum number of rows that can be shown on tableview's section = Int.max
So let say capacity "C"
C = (maximum number of section) X (maximum number of item in section)
Related
My table cells consist of a UIView on the left side, a label in the center, and a label on the right.
I add new rows with
insertRowsAtIndexPaths:withRowAnimation:
The rows I add look just fine. But when each is added, an existing cell loses its UIView, but keeps both labels.
What could be causing this? The views keep a positive retain count the entire time, and the cell identifiers are all unique. Also, when I scroll down and then up, so that the cells have to be redrawn, the UIViews are again visible. When the row is added, cellForRowAtIndexPath is definitely only called on the new row.
I would really check the memory/retain logic. By the way, how are you sure that your retain count is correct? DO NOT RELY in retain count since it does not do as you expect it. I tried many times before and it is not reliable and therefore even often missleading.
Do you use ARC already?
Are you by any chance reusing the same variables (directly or indirectly) to create your UIiew?
Just for testing purposes make sure you really retain the views (for example add them to an mutablearray or so) and see what happens.
Also if you post some code, it will be much easier for us to help!
This may be a very basic question. But I am finding it confusing with my tableView acting weird when I scroll up and down.
So UITableViewCells are Reusable !! So each row in my tableViewCell is reusable, and so, if I scroll down, I tend to use the same cells for different purposes (as programmed). My assumption is that 'a cell is a row'
Are sections reusable as well ?
So if I have 6 sections with 2 displayed on the screen at the moment, and I scroll down.... Do I effectively have 2 sections being reused thrice or do I have 6 sections ?
A Section is just visual appearance of groups of UITableViewCells in a UITableView. It is not a object or something that one can reuse.
Another reason why sections can not be made reusable is that, its rare that two sections contain same number of rows of same kinds of cells.
The only reusable elements in a table view are UITableViewCells.
As I understand it a section is not an object where a cell is. Therefore you do not need to give a section any memory as you do when you allocate a cell so do not need to recycle the sections in order to save memory. They are just indices for which section you are in. So "no" I think is the answer.
Perhaps if you posted your code we could be more help.
Martin
Cells are rows, yes. Sections themselves aren't reusable, but you can dictate which kind of cell gets reused for each section using the reuseIdentifier. That may give you the behavior you're looking for.
I have about 20,000 records (coming from an SQLite db) that I need to present to the user for possible choices, so conventional picker control is out of question.
Another possibility could be an indexed UITableView where user could check the desired value, however keeping all the 20K records in the memory doesn’t seem like a good idea.
how should I go about implementing UI for it? EDIT: is it possible to do something like auto-complete combo-box?
I'd look at some sort of nested UI i.e. a UITableView that has just A, B, C etc to start with and when the user presses on a row show another table view with all the results starting with A.
There would need to be a query that got the number of results that started with A, B, C etc so you only showed letters in the first table that actually has results but then each query in the second table would be very simple - all results starting with 'A' etc.
You'd never have to load all 20,000 results into memory at the same time :)
However, you should probably make sure that you have an index on the field that you're querying, otherwise your queries are all going to be rather slow :(
The other solution is to use a search box at the top of a table view - the user types in letters and each time the list is reduced to only results starting with that letter. That's a pretty simple query to implement :)
However, you would then still have the problem of what to do if the user hasnt typed anything in - do you show a message asking them to type or do you show all 20,000 results in an enormous list?
Are you aware of UIPickerView's "components"? 20,000 choices might be pushing it, but it is certainly one way (that is familiar to users) to narrow down choices by an order of magnitude with each spin.
If you find yourself constrained in one dimension, you could implement master-slave picker views.
Normally to use UITableView, the number of sections and rows per section are known. But what if they aren't? I want to implement a lazy search, so that I actually search for the next match when new data needs to be displayed. Something on the lines of: db.prepareSearch(query) and then call something like db.nextSearchResult() when it is time to display a new cell. The search result determines if a new section is required or not (search results are inherently sorted).
Not sure why it wasn't done this way to begin with, so that it asks for a section until no more are available or needed, and for cells in the section until no more are available or needed, instead of having to specify the totals, which implies having to finish the whole search before starting to display the first few results.
To get the number of sections and rows, it's easy -- ask your data source. If your data source has no way of telling you this, make a way.
For instance, if you have to query a table and ask how many rows there are for your sections, do that. Then, for each section, ask how many rows there are which match that section.
What it also sounds like is you want to paginate your data. Meaning when you get to a certain point, have a "load more data" cell or some-such. This is fine too, just add a sentinel node to your data source, and whenever that particular item comes up, display your alternate cell while you load your data, then remove it after your next data is fetched. I do this in a few of my apps.
If I'm understanding this correctly, at the point of drawing/populating, you will know how many rows/sections you have.
If your changing the underlying data using db.nextSearchResult() then you must be calling [tableView reloadData] to trigger a UI update, at this point you should know how many sections and rows you have.
I have to admit I'm a little confused to the exact issue here.
I am having trouble grasping the concept of multi component uipickerviews. I really would like to just OWN this subject. I would like to make a 4 component pickerview with components that are dependent on one another.
The first component is being populated from an array from my db, and that is showing up fine. I have all of the other info available in arrays, but I am just getting hung up on the dependent aspect of my pickerview. I figure the best way to make component 2's data depend on comp 1 is to link them somehow within the didSelectRow section. But I don't know the syntax.
I have been working at this for hours now and feel like I am really close, but I just need some help with a few issues. What is the syntax for connecting components so they depend on each other? Something like this? (Which is awful I know, but I am thinking that is the direction I need to get) :
if(picker = pickerComponent1)
//set number of rows for comp2 and also the content etc...
Another issue is determining the numberOfRowsInComponent bit because they aren't in the same method...
If anyone knows about (or wants to give :) a tutorial on this subject, it would be so helpful! Or if you are knowledgeable on the topic and would like to share some of what you know, that would be perfect too. I would really like to see this seemingly simple task completed.
It's quite simple. In the pickerView:didSelectRow:inComponent: method, just call [myPicker reloadComponent:] for all components coming after the one where the selection changed. The picker will then automatically ask its datasource (your view controller, presumably) for the number of rows and the rows' values.
Then, in pickerView:numberOfRowsInComponent: and pickerView:titleForRow:forComponent:, return the appropriate values (the count and contents of the corresponding array) depending on the values of the parent components' selected rows.