Evaluate making fetchedResultsController private

[3lvis]

DO IT!

[3lvis]

Done #29

[bonebox]

Hey @3lvis , just curious what the reasoning was for making fetchedResultsController private. I have a need to subclass DATASource and it requires access to fetchedResultsController. I guess I can make a fork, but would rather not...

[3lvis]

Hi @bonebox,

At the beginning it started with making convenience methods for handling common operations, using fetchedResultsController methods felt way too verbose:

=> self.dataSource.fetchedResultsController.fetchRequest.predicate

• self.dataSource.predicate

=> self.dataSource.fetchedResultsController.fetchedObjects?.count ?? 0

• self.dataSource.objectsCount

=> self.dataSource.fetchedResultsController.objectAtIndexPath(NSIndexPath(forRow: index, inSection: 0)) as? Song

• self.dataSource.object(indexPath: NSIndexPath)

=> self.dataSource.fetchedResultsController.indexPathForObject(song)

• self.dataSource.indexPath(object: NSManagedObject)

=> self.dataSource.fetchedResultsController.fetchedObjects!

• self.dataSource.objects

=> if self.dataSource.fetchedResultsController.fetchedObjects?.count == 0 {

• self.dataSource.isEmpty? {

Then the issue with changing the fetchedResultsController's predicate started, updating the self.dataSource.fetchedResultsController.delegate object isn't enough. You also have to do some clean up, and I had reports that updating the predicate was causing problems, so I went for just hiding the fetchedResultsController in order to push towards the use of the safer method.

https://github.com/3lvis/DATASource/blob/535147df9e2e0ca3f89d1a39ce678ec6c3a2c8e8/Source/DATASource.swift#L79-L94

[3lvis]

Btw, what problem are you trying to solve? Maybe we can find another solution.

[bonebox]

Hey @3lvis, thanks for the explanation--that's understandable. Perhaps a happy medium would be making it read-only? For example, public private(set) var fetchedResultsController: NSFetchedResultsController would be the only change needed, and work for keeping it readable, but not writable.

As for the problem I'm trying to solve - I need to subclass DATASource to override some of the UICollectionViewDataSource methods to modify the return values, and it requires read access to fetchedResultsController. The reason is the way my model is set up - I have a many-to-many relationship, and I need to fetch on one entity but display its relationship as the collection view items in order to section it properly. For example, say I have many-to-many Organization ←→ Person , I need to fetch the Organization entity and yet have each cell be a Person in order to section by Organization. Fetching by Person doesn't work, since a Person can belong to multiple Organizations, I can't derive which specific Organization a certain Person should belong to. This requires some manipulation of the datasource methods, similar to this. Hope that makes sense.

[bonebox]

Actually after looking at it further, a few more of the properties/methods would also need to be made public/read-only in order to accomplish what I want to do. The configureCell method would also have to be overridden, so would need to be public. Also collectionConfigurationBlock and tableConfigurationBlock properties would need to be public private(set) since they would need to be accessed in the overridden configureCell method...

[bonebox]

Anyway, don't worry about this. It's more of an edge-case that hardly anyone will likely need. I'll just create a fork and make my changes there. Thanks!

[3lvis]

Hi Jeremy,

Thanks for taking the time of explaining. I understood what you're trying to achieve. I'm sure your users will appreciate the extra work that takes making something like this. I can imagine why it would be useful.

I hope it works out for you, if I can help in anything just let me know.

Have a nice weekend!