I have this portion of code
func tableView(tableView: UITableView, didSelectRowAtIndexPath indexPath: NSIndexPath) {
let itemID:NSManagedObjectID = self.frc!.objectAtIndexPath(indexPath).objectID!
let entity:Entity = self.frc?.managedObjectContext.existingObjectWithID(itemID, error: nil) as Entity
if entity.completed {
entity.completed = false
} else {
entity.completed = true
}
println(entity.completed)
}
when the event occurs tableView performs scroll to top animation any ideas?
You are probably updating your managed object array somehow (not shown), perhaps via some delegate method. Most likely, you are calling tableView.reloadData() somewhere to update the displayed data. That automatically reloads the entire table view and will scroll to the top.
Instead, just update the cell in question with tableView.reloadRowsAtIndexPaths(rowAnimation:) documented here.
Maybe you sorting routine (not shown) is sorting by the completed attribute. Then the scrolling might be expected behavior.
NB: It seems odd that you keep an array of IDs as the dataSource. It would be just as efficient to just have an array of objects, due to the faulting behavior of Core Data. Better even, you should be using a NSFetchedResultsController with a table view - you get lots of cool behavior for free and are guaranteed to have the best solution for performance and memory management.
Related
How can I stop a diffable data source scrolling the view to the top after applying the snapshot. I currently have this...
fileprivate func configureDataSource() {
self.datasource = UICollectionViewDiffableDataSource<Section, PostDetail>(collectionView: self.collectionView) {
(collectionView: UICollectionView, indexPath: IndexPath, userComment: PostDetail) -> UICollectionViewCell? in
guard let cell = collectionView.dequeueReusableCell(withReuseIdentifier: PostDetailCell.reuseIdentifier, for: indexPath) as? PostDetailCell else { fatalError("Cannot create cell")}
cell.user = self.user
cell.postDetail = userComment
cell.likeCommentDelegate = self
return cell
}
var snapshot = NSDiffableDataSourceSnapshot<Section, PostDetail>()
snapshot.appendSections([.main])
snapshot.appendItems(self.userComments)
self.datasource.apply(snapshot, animatingDifferences: true)
}
fileprivate func applySnapshot() {
//let contentOffset = self.collectionView.contentOffset
var snapshot = NSDiffableDataSourceSnapshot<Section, PostDetail>()
snapshot.appendSections([.main])
snapshot.appendItems(self.userComments)
self.datasource.apply(snapshot, animatingDifferences: false)
//self.collectionView.contentOffset = contentOffset
}
store the offset, then reapply it. Sometimes it works perfectly and sometimes the view jumps. Is there a better way of doing this?
The source of this problem is probably your Item identifier type - the UserComment.
Diffable data source uses the hash of your item identifier type to detect if it is a new instance or an old one which is represented currently.
If you implement Hashable protocol manually, and you use a UUID which is generated whenever a new instance of the type is initialized, this misguides the Diffable data source and tells it this is a new instance of item identifier. So the previous ones must be deleted and the new ones should be represented. This causes the table or collection view to scroll after applying snapshot.
To solve that replace the uuid with one of the properties of the type that you know is unique or more generally use a technique to generate the same hash value for identical instances.
So to summarize, the general idea is to pass instances of the item identifiers with the same hash values to the snapshot to tell the Diffable data source that these items are not new and there is no need to delete previous ones and insert these ones. In this case you will not encounter unnecessary scrolls.
Starting from iOS 15
dataSource.applySnapshotUsingReloadData(snapshot, completion: nil)
Resets the UI to reflect the state of the data in the snapshot without computing a diff or animating the changes
First up: in most cases #Amirrezas answer will be the correct reason for the problem. In my case it was not the item, but the section identifier that caused the problem. That was Hashable and Identifiable with correct values, but it was a class, and therefore the hash functions were never called. Took me a while to spot that problem. Changing to a struct (and therefore adopting some things ;) ) helped in my case.
For reference here's a link to the topic on the Apple-Dev forums: https://developer.apple.com/forums/thread/657499
Hope my answer helps somebody :)
You'd think that any of these methods would work:
https://developer.apple.com/documentation/uikit/uicollectionviewdelegate/1618007-collectionview
https://developer.apple.com/documentation/uikit/uicollectionviewlayout/1617724-targetcontentoffset
But (in my case) they did not. You might get more mileage out of them, I am doing some crazy stuff with a custom UICollectionViewCompositionalLayout
What I did get to work is manually setting the offset in my custom layout class:
override func finalizeCollectionViewUpdates() {
if let offset = collectionView?.contentOffset {
collectionView?.contentOffset = targetContentOffset(forProposedContentOffset: offset)
}
super.finalizeCollectionViewUpdates()
}
where I have targetContentOffset also overridden and defined (I tried that first, didn't work, figured it was cleanest to just use that here. I suspect if you define targetContentOffset on the delegate without overriding it in the layout the above will also work, but you already need a custom layout to get this far so it's all the same.)
I'm currently using CloudKit as my backend and so far I've been enjoying it pretty much.
I've a query happening, that retrieves data to populate a table view.
Since I don't know the items count that it may have, I'm filtering the query to X number of items (let's say 15).
My goal is that when the user scrolls down to the bottom (last queried item) of the table view ill query the backend to continue filling the table view.
I've searched but couldn't find CloudKit code that does this.
Can somebody give me a hint on how to do it?
Thank you all for the given help.
Best, Ivan.
On IOS I think you have to use UITableViewController or just UITableView.
Add a UIActivityIndicatorView (i.e. spinner) to your UITableViewController. Connect the outlet to the code:
#IBOutlet weak var spinner: UIActivityIndicatorView!
Add a property to your UITableViewController to keep track that you're currently loading more data so that you don't try to do it twice:
var loadingData = false
Start the spinner animating and then call refreshRes():
func tableView(tableView: UITableView, willDisplayCell cell: UITableViewCell, forRowAtIndexPath indexPath: NSIndexPath) {
if !loadingData && indexPath.row == refreshPage - 1 {
spinner.startAnimating()
loadingData = true
refreshRes()
}
Have refreshRes() run on a background thread. This will allow your table to still move freely. The animated spinner will tell the user that more data is coming. Once your query returns, update the table data on the main thread.
func refreshRes() {
dispatch_async(dispatch_get_global_queue(QOS_CLASS_BACKGROUND, 0)) {
// this runs on the background queue
// here the query starts to add new 15 rows of data to arrays
dispatch_async(dispatch_get_main_queue()) {
// this runs on the main queue
self.refreshPage += 15
self.tableView.reloadData()
self.spinner.stopAnimating()
self.loadingData = false
}
}
After that it's depend of the server result you have to make a request to GET the others 15 datas
I've got an array of rooms I'm wanting to filter by usercount/topvotes sorta stuff.
I'm hitting buttons to trigger the filter changes and set a value to "CurrentSearch", reloading my tabledata, and in my cellForRowAtIndexPath I'm checking the current currentsearch value and filtering the list accordingly.
func tableView(_ tableView: UITableView, cellForRowAt indexPath: IndexPath) -> UITableViewCell {
if currentSearch == "new" {
self.PersonalSearchesList = PersonalSearchesList.sorted{ $0.users < $1.users }
} else if currentSearch == "top" {
self.PersonalSearchesList = self.PersonalSearchesList.sorted{ $0.latestUser < $1.latestUser }
}
My images/labels load in perfectly fine before the filtering. On the initial load I'm setting currentSearch to "new" and it works perfectly. It's only once I start trying to swap between filters that things get funky. I'm getting random duplicates of cells, and while I'm swapping between the filters the incorrect loads stay consistent..as in the same duplicates of the same cells are being made/placed at the same spots.
I have it when I click on a cell the information for the cell is printed..and despite the cell information being loaded incorrectly the actual information is correct and the lists are ordered as they should be.
any ideas?
You should do something like this:
var currentSearch: String {
didSet {
// sort your array
tableView?.reloadData() // reload data
}
}
if you will sort your every then it every time get sorted when you scroll your tableview or reload it. so sort your data somewhere else in other method and after successfully sorting reload your tableview.
Top brick problem I face every time is a passing data between component.
I can separate this problem in few sub-problems:
Do we need to pass data to views? Do we need to change model directly in view?
Can we use some service call directly from views, or we need to pass back all operation to UIViewConrtoller and only then controller will request appropriate service.
Specifying indexes instead of real models.
So the first question demonstrate case when we create UITableViewCell and pass to it data directly. So we now have ability to modify some properties of this data object. Let's say we have PlayListViewController that implement UITableView datasource. If you see bellow I set data model directly into view.
func tableView(tableView: UITableView, cellForRowAtIndexPath indexPath: NSIndexPath) -> UITableViewCell
{
let cell = viewController.theTableView.dequeueReusableCellWithIdentifier(String(SongTableViewCell.self)) as! SongTableViewCell
cell.song = songs[indexPath.row]
return cell
}
Second one for example, when you want to trigger something in your service directly from your SongTableViewCell without using any delegate calls. Let's say in SongTableViewCell I want to play my song and on this cell I have play button. So then it is a simple solution - I can bind cell with UIButton action touch up inside for example and invoke needed operation in my service:
#IBAction func onTappedPlayButton(sender: AnyObject)
{
MusicService.playSong(song)
}
But usually I do another things. I store delegate instance in my cell that pass back any action to a controller and controller decides what to do:
#IBAction func onTappedPlayButton(sender: AnyObject)
{
delegate?.didTappedPlayButton()
}
In this case SongTableViewCell looks like this:
class SongTableViewCell: UITabeViewCell
{
weak var delegate:SongTableViewCellDelegate?
...
#IBAction func onTappedPlayButton(sender: AnyObject)
{
delegate?.didTappedPlayButton(index)
}
}
and my view controller implements this didTappedPlayButton method where it calls MusicService.playSong(song). Here is 3rd problem if we have not pushed model object into UITableviewCell then we need to say somehow to view controller that it needs to play some appropriate song from array. So I use index that I set into the UITableviewCell which is sometimes can tangle other developers. I don't know if it's better to use index or data model. I understood advantage of changeability but index say nothing for developers and data model object says a lot.
I know it's more architecture questions, but maybe we can outline some props and cons of these 3 approaches/problems.
I found a post and it says
Classes=more complexity. Values=less complexity. Not sure it can fit all my subquestion, but maybe values it much better then transit entire class.
I am working on a project where I have a table view which contains a number of cells with pretty complex content. It will be between usually not more than two, but in exceptions up to - lets say - 30 of them. Each of these complex cells contain a line chart. I am using ios-charts (https://github.com/danielgindi/ios-charts) for this.
This is what the View Controller's content looks like:
The code I use for dequeuing the cells in the viewController's cellForRowAtIndexPath method is kind of the following:
var cell = tableView.dequeueReusableCellWithIdentifier("PerfgraphCell", forIndexPath: indexPath) as? UITableViewCell
if cell == nil {
let nib:Array = NSBundle.mainBundle().loadNibNamed("PerfgraphCell", owner: self, options: nil)
cell = nib[0] as? FIBPerfgraphCell
}
cell.setupWithService(serviceObject, andPerfdataDatasourceId: indexPath.row - 1)
return cell!
and in the cell's code I have a method "setupWithService" which pulls the datasources from an already existing object "serviceObject" and inits the drawing of the graph, like this:
func setupWithService(service: ServiceObjectWithDetails, andPerfdataDatasourceId id: Int) {
let dataSource = service.perfdataDatasources[id]
let metadata = service.perfdataMetadataForDatasource(dataSource)
if metadata != nil {
if let lineChartData = service.perfdataDatasourcesLineChartData[dataSource] {
println("starting drawing for \(lineChartData.dataSets[0].yVals.count) values")
chartView.data = lineChartData
}
}
}
Now the problem: depending on how many values are to be drawn in the chart (between 100 and 2000) the drawing seems to get pretty complex. The user notices that when he scrolls down: as soon as a cell is to be dequeued that contains such a complex chart, the scrolling gets stuck for a short moment until the chart is initialized. That's of course ugly!
For such a case, does it make sense to NOT dequeue the cells on demand but predefine them and hold them in an array once the data that is needed for graphing is received by the view controller and just pull the corresponding cell out of this array when it's needed? Or is there a way to make the initialization of the chart asynchronous, so that the cell is there immediately but the chart appears whenever it's "ready"?
Thanks for your responses!
What you're trying to do is going to inevitably bump into some serious performance issues in one case or another. Storing all cells (and their data into memory) will quickly use up your application's available memory. On the other hand dequeueing and reloading will produce lags on some devices as you are experiencing right now. You'd be better off by rethinking your application's architecture, by either:
1- Precompute your graphs and export them as images. Loading images into and off cells will have much less of a performance knockoff.
2- Make the table view into a drill down menu where you only show one graph at a time.
Hope this helps!