I have thousands of sections in TableView,and I use titleForHeaderInsection to give each of them a title.But I find that when the TableView is initialized, this method will be called thousands times to give every sections a title. Is that means I should set several sections each time?
No, you don't have to.
A memory is optimised for such occasions, so if your data source is properly set and contains data regardless its size, UI should handle it safely.
UITableView in iOS app, for example, is rendering just those cells, that are displayed at current time. So for example the common tableview on the iPhone 6 is displaying about 15 rows at a time.
And as a user, when you are scrolling down (or up) the table view, each time before the certain cell is displayed, the method cellForRow is called and takes data from your data source.
This also works for sections.
But, if your data don't have to be stored in the App bundle, the best way would be to get source data asynchronously, so for example you get 30 rows from data from server, after launching the app. Then if you reach (by scrolling) 30th row, your app will request more data from server and updates the table.
So user, that won't scroll your tableView, will not download all data and will not use big data transfer.
As a conclusion I would mention, that for all situations, the smaller data source, the better for performance of your app.
Tableview works on concept of reusability so only few which are visible are created and after that rest all are reused so no need to bother about it .
Rest refer to this link : Apple official link : https://developer.apple.com/library/ios/documentation/UserExperience/Conceptual/TableView_iPhone/TableViewCells/TableViewCells.html
Go through life cycle of Uitableview datasource methods as each and every method will get called for each section and row. So it is completely fine if section method is called thousand times. If you have any issue for it then add a paging like load first 10 sections and then other 10 sections and go on.
Related
As it's clear from the title, I have a scrolling performance issue in a table view.
Since I have read nearly every question that is posted online in this regard, and I assume all of you have much more experience with UITableView and its techniques, I won't bother with general stuff, and I just wanna point out some key things in my code that may help you help me spot where I'm doing wrong.
The UI in each cell is very very basic, so rendering each doesn't take considerable time. No shadows, no rounded corners, no extra effect, nothing. Just a few labels and two images, that's all.
The datasource is an NSArray which is already fetched from CoreData. The data of the labels are set from the content of the array, without much calculations or process required.
The height is each cell is a static integer, so the tableView:HeightForRowAtIndexPath: will immediately return the result as fast as possible. No calculations required.
The tableView:CellForRowAtIndexPath: dequeues and reuses cell with reusable identifiers so any re-creation is avoided.
So far everything is perfectly smooth. The issue is where items in Core Data are fetched from a server (Which is extremely fast) as user scrolls down. Data binding is done inside tableView:willDisplayCell:atIndexPath: to prevent tableView:CellForRowAtIndexPath: from becoming slow, as data needs to be loaded just before the cell goes live on the screen. I also fetch new items from server inside this method whenever there're some cells remaining till the last item fetched. So for example when there are totally 50 cells data fetched and put in the CoreData already and this method is called for cell number let's say 40, I request another 50 cell data from server, so that it will be ready whenever user reaches the end of the table.
As I expect this should only be called for the cells that go live on the screen. But putting some NSLogs shows that it is called multiple times until next 200 cells data are fetched (I guess the amount changes depending on device or simulator and the memory available on them and also OS limits). For example, I'm testing on an iPhone 7+, and I start the app and I go the page in which the table is. It fetches first 50 items and only first 4 items are shown on the screen, But I see that tableView:willDisplayCell:atIndexPath: is also called for cell #25, so another 50 is fetched immediately, and then it is called for cell #75, so another 50 is fetched, and this goes on for like first 200-300 cells, and then when fetching is stopped, scrolling is extremely fast and optimized until next 200-300 cells are fetched.
What can I do? Shouldn't tableView:willDisplayCell:atIndexPath: fire whenever a cell is about to be displayed? Where else should I fetch data as user scrolls?
Any ideas or suggestions is REALLY and GREATLY appreciated.
I already found entries with that topic on this page and also a website that provides a tutorial for that problem. But nothing worked very well.
The tutorial sad I should double the height of my tableView so cells loaded earlier, but with a higher tableView I never reached the last cells.
My problem is, I use a tableView to display my apps mainpage. This mainPage shows every time a topic and if its necessary for that topic it shows for example a cell with a map, one with pictures and sometimes not. Problem now, if I trying to scroll to my view its always lagging because it loads a map or this pictures. And scrolling back again because the loaded cells already deleted. I used a tableView because of the possibility to switch celltypes(mapCell, pictureCell, textCell) on and off.
I understand this feature, because of memory issues but in my case its not that much and it would be better if all my cells be preloaded and stay in memory until I change the topic.
Is there a swifty way to told my tableView to have this behavior?
Thanks a lot and nice greetings
I would suggest a different approach. Set up your table view controller to install placeholder images in your cells, trigger an async download that you cache to disk, and then update the cell with it's downloaded content if it's still visible when the download is finished.
There are various third party frameworks that do all this housekeeping for you.
Declare a cell array.
Follow these steps whenever change in your topic.
Clear you array
Create and configure all cells add to your array.
Return these cells to datasource methods using row index. Don't use tableview dequeue method here.
I'm working on an a game app in swift that currently has a tableView displaying the scores, number of trys etc, downloaded in an array from parse.
However, this table can get pretty long if the user plays the game many times. So I'd like to improve the app by displaying the first, say, 20 objects of the array in a tableview, then, once the user scrolls down to the end of the table it automatically adds more rows and displays the next 20 objects in the array (along with the original 20, making the tableview now 40 rows)
If anybody's familiar with the twitter app, that's exactly what I'd like to go for. There's a set amount of tweets shown initially, then once you scroll down to the end of the table more tweets are loaded, in order to decrease loading times.
Problem is, I really have no clue how to implement this at all. I've never been in the situation where I only need to use part of an array. Any help would be greatly appreciated. Dan
UITableView is a virtual view where it calls you back for the data to create cells for a given row that's in view and destroy's cells that go out of view. You should also re-use cells that have been created.
So, I think the answer to your question about pre-loading portions of the list is ... you shouldn't have to. Just implement the data source and answer the data call backs.
More here in the apple docs on the datasource for a UITableView
This is addressed in How to know when UITableView did scroll to bottom in iPhone in Objective-C. If any help needed translating this to Swift, post as a comment and I'll update answer.
EDIT -- The real question:
The tableView delegate methods allow you to perform arbitrary logic / mapping between your data and the table's viewable data. So when you do detect a scroll to the bottom, increment an internal state variable, such as var rowsToReveal declared as a class-wide stored property. After incrementing, call tableView.reloadData(). Then re-write numberOfRowsInSection delegate method to use rowsToReveal rather than someDataArray.count or whatever hardcoded value you had. Make sure rowsToReveal never exceeds the count, of course, otherwise -- instant crash.
Right now my table view presents 5 cells at the same time. I load them all up into an array so the "flow" of the UITableView is easier. But since there quite a few objects, the initial load can take quite a bit.
So my question is, is there a way to present the initial 5-7 cells while the rest are loading? Or what would be the practice for this?
The idea: for the first few cells to come up as fast possible, even while we are loading a bunch in the background so the user isn't sitting there waiting for 100+ cells to load.
Also, I am loading this cells with parse (I am getting the user's info including an image).
Thanks!
This may not work depending on where your data comes from and when it gets into your app, but this is what I would do. Allow your array to fill up with the first 5-7 items. Then call reloadData on your table view. Assuming your datasource is hooked up to your array properly, it will load the first few items. Then let your array continue to load until it's complete, and call reloadData again. You could even use this strategy repetitively to continually load new data. Good luck!
I have a UITableView that collects data from a database. What I would like to know is if there is some way I can iterate in the UITableView collection and check the values of the cell? The reason I ask is because I would like to update each cell based on the current value that it has (change font, size, color, etc.). I've seen in another SO post regarding this topic, but since the cells are already created and their values are changed it is a bit harder for me. I was thinking of iterating through the UITableView before I call reloadData, but any other suggestions are welcome.
You should not iterate over the cells of UITableView, because some of them (in fact, most of them) may not be present until you request them. UITableView aggressively recycles its cells, so if a cell is not visible, it is very likely that you would be creating it from scratch only to put it back into recycle queue moments later.
Changing your model and calling reloadData the way your post suggests would be the right solution. iOS will ensure that it runs the update in a smallest number of CPU cycles possible, so you do not need to worry about the cells that are already created. This is also the easiest approach in terms of your coding effort.
A table view is for displaying data. The properties of your table cells should only be written to, not read from. The appropriate way of handling this situation would be to update your underlying model objects -- the objects that you use to populate the table view -- as the data changes, and then reload the affected rows.
The issue you'll encounter is that UITableView reuses table cells. Once a table cell scrolls off the screen, it's quite likely that the table view will reuse the same cell to display a different row.
This means it's fundamentally not possible to iterate over the table cells. When you need to refresh a row because its data has changed, you should call reloadRowsAtIndexPaths:withRowAnimation: (or reloadData if all rows have changed) and if the row is visible on screen, UITableView will call your data source methods and give you an opportunity to configure the cell for display.