I'm struggling to understand how to use UICollectionViewDiffableDataSource and NSDiffableDataSourceSnapshot to model change of items.
Let's say I have a simple item which looks like this:
struct Item {
var id: Int
var name: String
}
Based on the names of the generic parameters, UICollectionViewDiffableDataSource and NSDiffableDataSourceSnapshot should operate not with Item itself, but only with identifier, which Int in this example.
On the other hand, again based on names of generic parameters, UICollectionView.CellRegistration should operate on complete Item's. So my guess is that UICollectionViewDiffableDataSource.CellProvider is responsible for finding complete Item's by id. Which is unfortunate, because then aside from snapshots, I need to maintain a separate storage of items. And there is a risk that this storage may go out of sync with snapshots.
But it is still not clear to me how do I inform UICollectionViewDiffableDataSource that some item changed its name without changing its id. I want UICollectionView to update the relevant cell and animate change in content size, but I don't want insertion or removal animation.
There are two approaches that would work solve your problem in this scenario.
The first is to conform your Item model to the hashable protocol. This would allow you to use the entire model as an identifier, and the cell provider closure would pass you an object of type Item. UICollectionViewDiffableDataSource would use the hash value for each instance of your model (which would consider both the id and name properties, thereby solving your name changing issue) to identify the data for a cell. This is better than trying to trick the collection view data source into considering only the id as the identifier because, as you stated, other aspects of the model might change. The whole point of structs is to act as a value-type, where the composition of all the model's properties determine its 'value'...no need to trick the collection view data source into looking only at Item.id.
Do as you said, and create a separate dictionary in which you can retrieve the Items based on their id's. While it is slightly more work to maintain a dictionary, it is a fairly trivial difference in terms of lines of code. All you should do is dump and recalculate the dictionary every time you apply a new snapshot. In this case, to update a cell when the model changes, make sure to swap out the model in your dictionary and call reloadItem on your snapshot.
While the second option is generally my preferred choice because the point of diffable data source is to allow for the handling of massive data sets by only concerning the data source with a simple identifier for each item, in this case your model is so simple that there's really no concern about wasted compute time calculating hash values, etc. If you think your model is likely to grow over time, I would probably go with the dictionary approach.
Related
I want to add selection field in a model which should be array of references. If I add this to model selection: types.array(types.reference(Todo)) then I have some undesirable side-effects like selection is being saved/loaded in snapshots and also changes to selection are recorded to the undo/redo history when using UndoManager middleware. If I put selection in volatile properties as just plain array then I lose reference sync capabilities(ie if one of selected elements removed from model selection will not be updated automatically).
Is there an approach which would allow to get benefits of both? Is there a way to ignore model field in patches/snapshots without moving it to volatile?
Good approach for models is to only have fields that belong to this entity and that you need in snapshots to send to server or elsewhere. Otherwise models become confusing and hard to manage.
Usually in such cases I put property like that into separate store or sub-store which bound to particular page/view for example. So this is structural issue more then anything else in my opinion.
I have a huge amount of data, already stored in STL containers. It feels very bad to do full copy for all data to Gtk::ListStore. And also, my data structure contains big gaps in some rows, which simply can be filled with a default value if the line of the view becomes visible. To store tons of default values into a model is also a bad overhead.
For this I thought it is easy to setup a own model which will then provide some entry points/callbacks where I simply can provide my own data from my containers.
But I can not find any line of documentation.
Here a standard TreeView, but no idea how to improve with own model:
https://developer.gnome.org/gtkmm-tutorial/stable/sec-treeview-examples.html.en
In https://developer.gnome.org/gtkmm-tutorial/stable/sec-treeview-model.html.en I found the beautiful sentence
Although you can theoretically implement your own Model,
you will normally use either the ListStore or TreeStore model classes.
After that I take a look into the sources... well, because Gtkmm is only a wrapper over the C-code, it is not simply deriving from a class and overwrite some methods. It is more to pick up the underlaying c code if my interpretation of the code I saw is correct.
Anyway, is there any chance to get some lines of code where the ListStore is replaced by a own model?
In my collection view I need to generate an index for each item. As Items get reordered I need this index to update with its new position.
The data are Core Data entities in a managed NSArrayController.
The closest I have come to a possible solution is implementing this method on the entity class and then using representedObject.dynamicIndex to bind it to the UI.
- (NSNumber *) dynamicIndex
{
NSInteger r = [[[[self managedObjectContext] registeredObjects] allObjects] indexOfObject:self];
NSNumber *result = [NSNumber numberWithInt:r];
return result;
}
This solution is sketchy at best, and not really functional as it doesn't necessarily reflect the order in the collection view.
Anyone have a model / mechanism for generating or retrieving item indexes in an NSCollectionView?
First, make sure you understand the difference between (and properly use the terminology of) "entity" and "instance." It makes all the difference in communicating your problems/solutions with others.
Second: Don't worry about NSCollectionViewItems ... worry about each one's "represented object," which is held in some container.
Third: Did you want the display order to be a persistent attribute of your entity or do you just need to know what position the item is in at the moment, regardless of what it might be later? Important question.
Fourth: Core Data does not give you the concept of ordered collections. This is to support store types such as NSSQLiteStoreType, where you might only want to fault in a few items (or one) without loading the whole list. Therefore, you're on your own if you want a persistent sort order. To do this, just add an attribute to your entity called "sortOrder" and make it a number type.
Fifth: Because of the "no ordered collections" issue above, your attempt to find the index of a given instance of your entity from an array, built from a set, which was faulted in with a nondeterministic order is doomed to failure.
Sixth: Since you're using an array controller, you'll need to set its sort descriptors. You'll want to use your "sortOrder" key. That way, your fetched instances will always be kept sorted by their "sortOrder."
Seventh and finally: If you're trying to get the index of any objects in your array controller's set/array of objects, you'll want to ask it for its -arrangedObjects, so you're getting the index of the object in the sorted collection the array controller controls.
Hope that helps.
Update for Lion (10.7)
With regard to my sixth point: If you're targeting 10.7 and above in your application, [NSManagedObject now gives you ordered relationships.][1] Use -mutableOrderedSetValueForKey: and -mutableOrderedSetValueForKey: to set and retrieve NSOrderedSets. Yay!
I'm building a report that needs to include an 'estimate' column, which is based on data that's not available in the dataset.
Ideally I'd like to be able to define a Java interface
public int getEstimate(int foo_id, int bar_id, int quantity);
where foo_id, bar_id and quantity are available in the row I want the estimate presented.
There will be multiple strategies for producing the estimate so it would be good to use an interface to allow swapping them when needed.
Looking at the BIRT docs, I think it's possible I ought to be using the event handler mechanisms, but that seems to only allow defining a class to use and I'd somehow like to inject a configured estimator.
A non-obfuscated example might be to say that I have a dataset which includes an IP address column, and I'd like to be able to use some GeoIP service to resolve the country from the IP address. In that case I'd have an interface public String getCountryName(String address) and the actual implementations may use MaxMind, a local cache or some other system.
How would I go about doing this?
Or.. would I be better off by writing a scripted data source that can integrate the computed data before delivering it to BIRT?
Or.. some sort of scripted data source that is then used to create a join data set?
I think a Scripted Data Source would work fine, but a Java-based event handler would be more straightforward. You can implement it as a simple POJO and get access to any and all the complex objects and tools that will allow you to calculate your estimate. The simplest solution of all may simply to be adding a calculated field to the data set.
When creating the calculated field, you can get pretty complex in terms of the scripting logic you can leverage in order to produce the resultant value. The nicest thing about this route is that all the other column values in the row (which I assume you need to calculate the estimate) are made available via the Expression editor. You can pull in complex objects (POJOs) to help in your calculations here as well by using the "Packages" object (i.e. var red = new Packages.redwood.HelloWorld())
If you want to create the Event Handler class, here is what I would do. I would create a text object and bind the onCreate even to your POJO (by extending the TextItemEventAdapter) and override the "onCreate" method. There you can do any work you want to and at the end simply call 'text.setText(theEstimateResult);' to make the estimate itself visible. As far as accessing data values to do your calculations, You can get to those in the POJO too. I assume the estimate will be a part of a larger table of values. You can access any specific row value via the reportContext.
Those are the two ideas I would give a try first. The computed column is the fastest to implement and the least likely to throw you a curve during deployment. Let me know which way you choose and we can hash it out further if needed.
I'm trying to make a Core Data app in which when you select one "Player" in a TableView, and a list of all teammates appears in a second tableView, with a column for how many times those two players have played on the same "Team" (another entity).
This has got me completely stuck, because while I know how to fill up a table from a normal array, using ArrayControllers and Core Data has really cluttered up my view of the situation.
How would you approach this?
Yours is a Bindings problem, not a Core Data problem. :-)
You should definitely get a handle on Cocoa Bindings before dealing with Core Data. This is stated in the docs and is very true.
The subject of your question seems to differ from the body, so I'll answer both.
Showing the Teammates
Core Data aside, assume you have a table representing Player instances. Player has one Team. Team has many players. Therefore, it's inferred that an instance of Player has "team.players" (minus itself) as teammates. Whether you're using Core Data to manage the model or not, this is true of the overall relationships.
If you read through and master Cocoa Bindings, you'll find that this is not hard at all to set up using a basic Master/Detail setup (with an extra array controller for the Detail part, for simplicity). Your Master array controller represents all Player instances, while your detail array controller represents the Teammates - or the Master's selection's "team.players" (minus itself).
The Teammates array controller will have its entity and managed object context set up as usual (see the docs). The "contentSet" will be bound to the Master array controller's "selection" controller key, with "team.players" as the model key path.
The trick is to filter out the Master controller's selected player using predicates. This you can do with the array controller's Filter Predicate. Maybe one with a format of "self != %#", where "%#" represents the Master array controller's selection. I'll leave Predicates (a complicated topic unto itself) to you. Remember, you can set them in code ([myController setFilterPredicate:myPredicate]) or by using bindings. Predicates are independent of Core Data as well.
Getting Selection
Since the array controller is in charge of the array the table represents, it's best to ask the array controller what its selection is. One way is to ask its -arrangedObjets for the objects at its -selectedIndexes.
NSArray * selectedObjects = [[myArrayController arrangedObjects] objectsAtIndexes:[myArrayController selectedIndexes]];
You can also ask it for its -selectedObjects. There are differences between these two approaches that are described by the documentation (API reference and conceptual docs) that you should definitely understand, but asking the controller is the most important concept, regardless of whether you use an NSArrayController or some custom controller that conforms to the and protocols.
Disclaimer: Typed hastily after a social Sake evening. Not checked for errors. :-)