My sport app keeps track of who is on and off the field, and for how long. I normally have 20-30 people to swap around, during training time. I have a timer to reload the visible cells of the collection view every second. The whole collection view reload can cost between 120-150ms.
The scrolling performance is good, however, sometimes the tapping to swap players does not respond. I think that is when the collection view is trying to reload the cells.
I can see there might a couple of ways:
Use UITableView, with each row to have 4 different elements.
Use UIScrollView, and preload all elements there. We used to use KKGridView library here, but it is way outdated. That is why we move to UICollectionView after 6-7 years
Have anyone had the same issue, and which way should provide the acceptable level of efficiency but not too complex to implement (to reduce the number of bugs)
Keep the record of the cell's index that need to update, then get the Cell from collection view, call method ask it to update itself, push the view update to the cell class, it wont mess with your collection view tap/drag...
Reload whole collectionView is only needed when whole dataSource change, yours is simply cell-by-cell update as I notice
Related
I am implementing a chat app using UICollectionView. Initially I fetch only 100 messages. As the user scrolls, I fetch some more messages and then reload the collection view. To maintain the scroll position I set the content offset but scrolling gets stopped. How to maintain the scrolling speed after reloading the UICollectionView so user doesn't feel jerk?
You could try to use the prefetchDataSource that was introduced in iOS10.
UICollectionView Prefetch Data Source in iOS 10?
There're several approaches to handle this.
You don't use reloadData() but rather insertItemsAtIndexPaths:, that way you don't have rebuild the whole table and only build the items you need.
You load additional data when use hits a specific point your collection view. In a willDisplayCell method you can check if indexPath of a cell is getting close to the last index in your data source and load additional rows. In the moment user will scroll to the last item, all the stuff will be already there so you don't have worry.
In my experience the best way is to use both of this approaches combined. Because in general using reloadData() every now and then could be very resourceful depending on your cell layouts.
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.
So this is a rather simple problem that I've had a rather hard time fixing. I'm trying to take advantage of table views for displaying a huge list of cells because it is already optimized for cell reuse and saves me time in that regard. I need this list to smoothly scroll at an accurate duration. If I scroll too fast cells are still loading when they show on screen so I'm only scrolling one cell at a time.
The code I'm currently using is modified from here: https://stackoverflow.com/a/17956396. I've changed it to only add a single animation to the array and to never remove it. Instead I have a counter that checks to see if there is another cell before scrolling.
This is working fine, but my issue is that I can't update the animation duration to be faster or slower to keep an accurate pace. Is there a way for me to chain animations in a way that would allow me to dynamically update the duration so as to keep accurate timing?
I'm new to iOS and MonoTouch, and I have a pretty basic need - I have two vastly different views to display in the same table cell depending on whether it is selected or not. When you load the app I'll present a list of products in a custom UITableView, with all the rows deselected and each row basically just showing the product names in a label. As soon as a user taps one of the rows and selects it, I show a very different view with more of a shopping cart layout. Since the two views are so different they have vastly different sizes. What i need is for the cell itself (or row?) to grow and shrink according to the natural height of whichever view is currently being displayed.
I'm using descendants of UITableViewController, UITableViewSource, and UITableViewCell for the solution. What I do is add both versions to the cell's ContentView, then set the Hidden property as needed when the cell/row is selected/deselected to show the right layout. That works well. I'm in demo mode right now, so I'm not overly worried about efficiency or responsiveness, that will have to come later.
I know that GetHeightForRow is responsible for sizing the rows but it only gets called once, when the cell is first shown. It seems to me that I need to alert the TableView to re-poll the source for a new size as the views are changing, but I can't figure out how to do it.
I tried (rather hopefully) to cause GetHeightForRow to be invoked again manually using Cell.SetNeedsLayout and Cell.SetNeedsDisplay, hoping that would cause the table to re-query the source for new dimensions, but no joy.
I tinkered with the direct approach, trying to size the contentview itself but it didn't seem as if it was leading anywhere. I feel as if the table needs to be told to query for a new row size, but I'm open to any suggestions.
Surely I'm not the first to attempt this? What am I missing?
Try forcing GetHeightForRow to be called again by calling ReloadRows instead.
You may or may not have to specify begin/end updates (this might just be for animation, though?)
tableView.BeginUpdates();
tableView.EndUpdates();
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.