How to enable data prefetching when using the new Compositional Layout & DiffableDataSource?
Before, we can achieve this by conforming a custom data source object, like,
class CustomDataSource: NSObject, UICollectionViewDataSource, UICollectionViewDataSourcePrefetching
Now, the data source is the UICollectionViewDiffableDataSource, which only conforms to UICollectionViewDataSource.
One way is to extend it to conform to the prefetching protocol. However, due to the fact that it encapsulates protocol implementations of the DataSource into its higher level methods like snapshots and apply. I can't figure out how to extend it to conforms to the prefetching protocol.
Your implementation of UICollectionViewDataSourcePrefetching is set on a separate property of UICollectionView called prefetchDataSource. So you should not need to subclass UICollectionViewDiffableDataSource
https://developer.apple.com/documentation/uikit/uicollectionview/1771768-prefetchdatasource
I can confirm that prefetching works when using a UICollectionViewDiffableDataSource. You will need to cache your prefetched data somewhere, and then access it from your cellProvider (or UICollectionView.CellRegistration)
For example, if your view controller implements UICollectionViewDataSourcePrefetching then you may have a line where you assign it as the prefetchDataSource:
myCollectionView.prefetchDataSource = self
Related
I'm following a UITableView tutorial and I've learned that the UITableView is a view object which doesn't handle the logic or data, it primarily the view or user interface. As I continued reading it says that the UITableView requires a "datasource". My question is this, is the datasource the program's logic?
IOS app development widely use Delegate design pattern. Almost all UIView have their own Delegate Protocol. Before understand UITableViewDelegate and UITableViewDatasource Protocol try to learn about Delegate design pattern.
If you work with UITableView you have to implement atleast 2 protocol in your ViewController.
1. UITableViewDelegate : The delegate of a UITableView object must adopt the UITableViewDelegate protocol. Optional methods of the protocol allow the delegate to manage selections, configure section headings and footers, help to delete and reorder cells, and perform other actions.
2. UITableViewDataSource: The UITableViewDataSource protocol is adopted by an object that mediates the application’s data model for a UITableView object. The data source provides the table-view object with the information it needs to construct and modify a table view.
Why is tableView:canMoveRowAtIndexPath: is UITableViewDataSource protocol and not in UITableViewDelegate protocol?
Similar methods (e.g. tableView:canFocusRowAtIndexPath:) are in Delegate protocol. I don't think it's a mistake, so can anyone explain why such method is part of the data source and not the delegate?
A general explanation of which methods belong to data source protocols and which belong to delegate protocols is also appreciated.
The delegate methods generally have to do with the appearance of the table view.
The data source methods generally have to do with the content of the table view. It's often the case that the displayed content's order is fixed. Say the table view was displaying stops on a bus line, or the chapter headings of a book. You can't let the user reorder those: it isn't something that the content itself supports.
Notice that both delegate and data source are actually involved in the decision as to whether a row can move. The data source gets the method you named, but the delegate gets asked tableView:targetIndexPathForMoveFromRowAtIndexPath:toProposedIndexPath: at the same time.
The UITableViewDatasource protocol documentation:
The UITableViewDataSource protocol is adopted by an object that
mediates the application’s data model for a UITableView object. The
data source provides the table-view object with the information it
needs to construct and modify a table view.
As a representative of the data model, the data source supplies
minimal information about the table view’s appearance. The table-view
object’s delegate—an object adopting the UITableViewDelegate
protocol—provides that information.
The required methods of the protocol provide the cells to be displayed
by the table-view as well as inform the UITableView object about the
number of sections and the number of rows in each section. The data
source may implement optional methods to configure various aspects of
the table view and to insert, delete, and reorder rows.
Hope, that clears things out.
EDIT: With my own words (but repeating the docs): Datasource declares methods those somehow directly or indirectly affect/reflect the data model, whereas the method tableView:canFocusRowAtIndexPath: can't be said similar to tableView:canMoveRowAtIndexPath: because it has nothing to do with the data. That said, datasource carries constructive character, delegate - informative.
In my iOS app I have a view controller and a UITableView subclass on one of my views. Currently the UITableView manages it's own data (creating connections, and being the delegate which handles the callbacks).
I was wondering if this is best practice? Is it better to run this on the view controller and then pass the data into the table? Does this not matter at all?
Please explain the reasons in addition to answering my question.
Thanks!
It would be more standard to implement the delegate and dataSource methods in the ViewController.
It is quite unusual to subclass the UI*View classes, except to customise drawing. UITableViewCell is a bit of an exception to this rule.
If you find your ViewController getting a bit big you might think about implementing the delegate and dataSource in a separate class.
In addition to mcfedr's answer, views are things that interact with user and it is generally good to separate concepts (unless unavoidable). Also note that historic versions of ios (iirc) view controllers may load/unload views on demand, so any application logic in there may cease to exist.
In this scenario, I generally have only one class... The UIViewController instance that contains the following view hierarchy:
view -> myTableView
With this approach, my UIViewController will:
Have an IBOutlet to a UITableView (myTableView)
Implement methods of UITableViewDelegate
Implement methods of UITableViewDatasource
Set myTableVIew.delegate to self
Set myTableView.datasource to self
When the host UIViewController is the delegate and datasource of your UIViewContoller, all code can exist in one class. This keeps the code of your project tighter but does tightly couple your logic.
The alternative approach would be to subclass UITableView and implement UITableViewDelegate and UITableViewDatasource. This will be a desirable approach if:
You wanted to reuse the UITableView in multiple UIViewController
You wanted to encapsulate the UITableView logic from the UIViewController
Here is the thought process I use:
Am I going to reuse this UITableView and its logic?
Yes -> UIViewController class and UITableView subclass
No -> UIViewController class only
The best practice would depend on the number of programmers involved, the repeatability of the UITableView, coding patterns already established. This is often a matter of preference and I hope my answer shed some light on why you would go either way,
I have theoretical question.
Currently my app is using UICollectionView as a way to display objects list. UIViewController, that contains UICollectionView as subview, implements UICollectionViewDelegate protocol and acts as delegate and datasource. Datasource uses NSFetchedResultsController to provide data;
In my opinion this is not the best way to implement datasource, and implementing it in separate class looks way better idea. But the issue it that datasource depends on search parameters in UITextField, and some other buttons selections, so every time when user types text into search field or press the any of "sorting" buttons I should update datasource (in particular fetchRequest in NSFetchedResultsController).
So, finally, my question: Is there any "best practices" of implementing datasources that depends on external parameters? Should I create separate class for datasource of leave it the way it is now? If implementing datasource as separate class - should I create datasourcedelegate for calling self-made delegate methods on delegate when datasource was updated or there is some other workarounds for this problem (I'm not considering using notifications on datasource update because as for me notifications mechanism is more global solution then I need here)?
I'm not looking for the fastest way, I just want to find out the rightest theoretical way of implementation.
Thank you all in advance :)
I personally implemented a concrete NSObject derived class, that implements UICollectionViewDataSource as well as NSFetchedResultsControllerDelegate that practically translates the fetched results controller events (object inserted, updated, deleted) to collection view events (insert, update or delete cells). You can find examples on how to do this, I took mine from here but I implemented it as a separate class instead of a category over collection view. I found my class highly reusable, in practice I use it in all of my projects where there is a need to visualize managed objects in a collection view. A similar class can be implemented also for UITableViewDataSource.
If you need to update the fetch request with the search predicate, I would subclass your newly created DataSource class, and add the logic to update the fetch request right there. Say, you add a -(void)updateSearchFilterWithText:(NSString*)text method where you add the logic to update the fetch request of the fetched results controller. Don't forget to perform fetch again afterwards and call a reloadData on the collection view!
With this architecture the view controller owns this dataSource object. Every time the user updates one of your filtering text field (or other widget), the view controller calls the updateSearchFilterWithText: of your data source object and the rest of the work is done by this later.
What you currently have is the standard approach. While there is no defined 'best' approach, what you describe is certainly a better approach.
Your view controller would own an instance of your new data source class, and would itself most likely handle the delegate methods (because these are actions to take rather than data to provide), so when anything changes in the UI the view controller should be 'pushing' these changes to the data source. No additional delegation should be required.
You shouldn't be creating your data source with the idea that text fields and buttons are directly driving changes in. Your data source should be presenting a generic interface where you can update the fetch request to execute (which covers the predicate and sorting) and change how the cell is configured (perhaps with a block). This way you keep your business logic in the view controller and the reusable data source code in another class that is reusable for other collection views / projects.
I am using XCode5 and iOS7.
Is it possible to embed a UICollectionView into a normal UIViewController class and have the UIViewController implement the methods?
Or do I need the UICollectionViewController?
Which methods are required at minimum?
Yes it is possible to implement UICollectionView without UICollectionViewController. CollectionViews are just like tableView.
As you probably already know, when you use a UITableView you have to set a data source and a delegate in order to provide the data to display and handle events (like row selection).
Similarly, when you use a UICollectionView you have to set a data source and a delegate as well. Their roles are the following:
1. The data source (UICollectionViewDataSource) returns information about the number of items in the collection view and their views.
2. The delegate (UICollectionViewDelegate) is notified when events happen such as cells being selected, highlighted, or removed.
And new to UICollectionView, you have a third protocol you must implement – a protocol specific to the layout manager you are using for the collection view.
You can use a UICollectionView, you'll need the UICollectionView to conform to the UICollectionViewDelegate and UICollectionViewDataSource protocols.
so you will need at a minimum;
numberOfSectionsInCollectionView, numberOfItemsInSection and you'll need to implement cellForItemAtIndexPath to create the cells. Obviously you'll also need to define the Cell
Answer is NO. UICollectionView is subclass of UIVIew and can be added to any view you wish.
Since UIVIewController has view property you can add UICollectionView to it using:
[self.view addSubview:self.collectionView];
Here is a great tutorial with sample project where you can see how to implement UICollectionView in your custom UIViewController subclass:
http://www.raywenderlich.com/22324/beginning-uicollectionview-in-ios-6-part-12
You don't need an UICollectionViewController. Just make sure, that your ViewController implements the UICollectionViewDelegate and UICollectionViewDataSource.
This example should help you with the topic UICollectionView:
http://adoptioncurve.net/archives/2012/09/a-simple-uicollectionview-tutorial/