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.
All those “NSOrderedSet was added later and thus doesn’t have to play nice with other components” bugs drive me crazy…
(https://twitter.com/kubanekl/status/413447039855640576)
I have two managed objects and an ordered 1:N relationship between them, which is backed by an instance (or more precise a subclass) of NSOrderedSet. I want to manage this relationship using a NSArrayController in order to profit from features it offers (selection management, binding of the content, bindings to views like NSTableView).
Since NSOrderedSet is not a subclass of NSSet, the contentSet binding of NSArrayController doesn't work with that relationship. I found following thread and tried to implement the suggestions mentioned there.
The first suggestion is to use the contentArray binding and a value transformer for transforming the ordered set to an array on the fly. The problem with this solution is the reassigning of the content each time a change is made, which is not what I want.
The second suggestion provided in the mentioned thread is to use the contentArray binding and apply the #array operator to the model key path. I've tried that, but the underlying relationship was not touched at all when adding/removing objects through the NSArrayController.
Another option I found is using sort descriptors with the contentSet binding. This would require making the relation unordered in order to make the contentSet binding work and introducing a new attribute used especially for managing the order. This would furthermore require a custom ordering mechanism to implement and it would mess up the model. Honestly said, I would like to avoid this solution.
My question is pretty clear: Is there any way to manage an ordered Core Data relationship using NSArrayController? If so, which is the best way causing as little pain as possible?
It is indeed very sad that NSArrayController does not come with support for ordered relationships. As a keen observer to the bindings technology I find it sub optimal that it seems that Apple has "abandoned" it without saying anything. The last notable change that Apple introduced with regards to bindings are NSTreeController bug fixes. That was I believe with 10.6/10.7. It seems that Apple does not want to touch the bindings technology anymore. I am not sure why because bindings are really great sometimes. They can be the "90% solution". During prototyping this is fine. I am using bindings where it makes sense and having NSArrayController with ordered relationships support would be something great.
Most of the solutions that have been mentioned already are no real solutions. But this depends. Here is something to think about:
If you are planning to support iCloud then you should not/cannot use ordered relationships anyway because Core Data on iCloud does not support them.
Since ordered relationships are fairly new and the desire for a ordered collection of objects existed long before them, there must be a way in Core Data to mimic ordered relationships. You have already pointed out what 99.9% of the Core Data eating world did before ordered relationships were available: Sort by an additional attribute. You have pointed out that this is messing up the model but I disagree: It is true that you have to add an additional attribute to your model which does not necessarily "represent" true model data. But how many ordered relationships are you planning to have in your model? Usually you don't have that many per application. Even though it feels a bit dirty this is what has been done by lots of people for at least three major releases of Core Data (10.4, 10.5 and 10.6). Even today this solution is used for backwards compatibility or if you want to use iCloud. It is a "pragmatic" solution. Not a nice one but pragmatic. Also please not: Even if you were using ordered relationships the order of your objects has to be stored somewhere. If you are using the SQLite store then having an ordered relationship causes the NSSQLiteStore to create an additional column for you. The column has the name: Z_FOK_$RELATIONSHIPNAME. So by using ordered relationships you are merely doing something that is done for you under the hood anyways. This means that it does not really matter from a pure technical perspective if you are using ordered relationships or an additional attribute. The underlying technical problems remain the same. Ordered relationships are no magic.
If you are planning to go with the "additional attribute" solution be aware that you have to adjust the value of this attribute a lot: Every time the user is changing the ordere via drag and drop you have to modify the value of the attribute. This seems wasteful but it really isn't. Even the worse case: A user who is exchanging the object at row 0 with an object at the last possible row does only cause 2 attribute changes. The complexity of the trivial solution for changes needed to represent any change that can be made by drag and drop in a table view is O(n) where n is the number of selected rows. This is really not that bad since users are usually not reordering 10000000 rows at once and even then there are smarter algorithms out there which are not that hard to implement.
If you are looking the for cleanest solution you should subclass NSArrayController and add a "orderedContentSet" bindings yourself. You can find out how to do that by reading the Cocoa Bindings Programming topic guide. The guide contains an example: https://developer.apple.com/library/mac/documentation/cocoa/conceptual/CocoaBindings/Concepts/HowDoBindingsWork.html (Listing 2). The bad thing about this is that you are subclassing NSArrayController which is usually a no go. Many people tend to subclass NSArrayController for reasons that don't justify subclassing it. In this case however subclassing NSArrayController is justified if you want to go with the cleanest solution.
For 3. there are generic solutions out there which do a lot of the stuff for you. Don't use them.
I think that the terminology used in Qt with model/view controls is flawed. On their explanation page they state, that they simplified the MVC to MV by merging View and Controller and they are giving the following picture:
However I think, they misnamed the roles of objects and I think that,
What they call View with merged Controller is in fact a View only.
What they call Model is in fact Controller only.
If you really want to have a model it would be somewhere where their "Data" is.
I am speaking about usual and sane way you would use Qt model/view component in your app.
Here are the reasons:
This is typically Qt component which is used as is, without adding any Controller logic specific to your objects)
This is hardly a Model, just because you should implement several Qt methods like rowCount, columnCount, data etc. which have nothing to do with your model. In fact there are typical model methods found in Controllers. Of course, you can implement both Controller and Model logic here, but first it would be quite bad code design and secondly you would merge Controller and Model not Controller and View as they state.
As said in reason 2. if you want to separate Model logic that it is surely not the blue box on the picture, but rather the dashed "Data" box (communicating to real Data of course).
Is Qt wrong in their terminology, or it is just me who does not understand? (BTW: The reason why it is not academic question is that I have started to code my project following their naming and I have soon found out, that the code clearly is not right. It was only after that when I realized, that I should not try put Model logic in what they call Model)
Short answer
Qt's MVC only applies to one data structure. When talking about an MVC application you should not think about QAbstractItemModel or QListView.
If you want an MVC architecture for your whole program, Qt hasn't such a "huge" model/view framework. But for each list / tree of data in your program you can use the Qt MVC approach which indeed has a controller within its view. The data is within or outside of the model; this depends on what type of model you are using (own model subclass: probably within the model; e.g. QSqlTableModel: outside (but maybe cached within) the model). To put your models and views together, use own classes which then implement the business logic.
Long answer
Qt's model/view approach and terminology:
Qt provides simple views for their models. They have a controller built in: selecting, editing and moving items are something what in most cases a controller "controls". That is, interpreting user input (mouse clicks and moves) and giving the appropriate commands to the model.
Qt's models are indeed models having underlying data. The abstract models of course don't hold data, since Qt doesn't know how you want to store them. But you extend a QAbstractItemModel to your needs by adding your data containers to the subclass and making the model interface accessing your data. So in fact, and I assume you don't like this, the problem is that you need to program the model, so how data is accessed and modified in your data structure.
In MVC terminology, the model contains both the data and the logic. In Qt, it's up to you whether or not you include some of your business logic inside your model or put it outside, being a "view" on its own. It's not even clear what's meant by logic: Selecting, renaming and moving items around? => already implemented. Doing calculations with them? => Put it outside or inside the model subclass. Storing or loading data from/to a file? => Put it inside the model subclass.
My personal opinion:
It is very difficult to provide a good and generic MV(C) system to a programmer. Because in most cases the models are simple (e.g. only string lists) Qt also provides a ready-to-use QStringListModel. But if your data is more complex than strings, it's up to you how you want to represent the data via the Qt model/view interface. If you have, for example, a struct with 3 fields (let's say persons with name, age and gender) you could assign the 3 fields to 3 different columns or to 3 different roles. I dislike both approaches.
I think Qt's model/view framework is only useful when you want to display simple data structures. It becomes difficult to handle if the data is of custom types or structured not in a tree or list (e.g. a graph). In most cases, lists are enough and even in some cases, a model should only hold one single entry. Especially if you want to model one single entry having different attributes (one instance of one class), Qt's model/view framework isn't the right way to separate logic from user interface.
To sum things up, I think Qt's model/view framework is useful if and only if your data is being viewed by one of Qt's viewer widgets. It's totally useless if you're about to write your own viewer for a model holding only one entry, e.g. your application's settings, or if your data isn't of printable types.
How did I use Qt model/view within a (bigger) application?
I once wrote (in a team) an application which uses multiple Qt models to manage data. We decided to create a DataRole to hold the actual data which was of a different custom type for each different model subclass. We created an outer model class called Model holding all the different Qt models. We also created an outer view class called View holding the windows (widgets) which are connected to the models within Model. So this approach is an extended Qt MVC, adapted to our own needs. Both Model and View classes themselves don't have anything to do with the Qt MVC.
Where did we put the logic? We created classes which did the actual computations on the data by reading data from source models (when they changed) and writing the results into target models. From Qt's point of view, this logic classes would be views, since they "connect" to models (not "view" for the user, but a "view" for the business logic part of the application).
Where are the controllers? In the original MVC terminology, controllers interpret the user input (mouse and keyboard) and give commands to the model to perform the requested action. Since the Qt views already interpret user input like renaming and moving items, this wasn't needed. But what we needed was an interpretation of user interaction which goes beyond the Qt views.
I agree with you that Qt's naming is misleading. In my opinion however, the problem is not Qt's alone, but is shared by all frameworks that allow us to adhere to the principle of separation of concerns when implementing our UIs. When someone comes up with such a framework, and finds a good way to keep "things" separated, they always feel obliged to have modules that they call "Model" and others that they call "View". Over the years I have worked with these frameworks:
MFC
Qt
Swing
SWT
WPF with MVVM
If you compare how the terms "Model" and "View" are used in these frameworks, and what responsibilities the classes in the "View", the "Model", and the "Controller" (if there is one) have, you will find that there are very big differences. It would certainly be useful to have a comparison of the different concepts and terminologies, so that people switching from one framework to another have a chance to stay sane, but that would require a lot of work and research. A good read is Martin Fowler's overview.
Since there are so many different ideas what an MVC pattern can look like, which one is correct? In my opinion, the people who invented MVC should be turned to when we want to know how it is supposed to be implemented "correctly". In the original smalltalk paper it says:
The view manages the graphical and/or textual output to the portion of the bitmapped display that is allocated to its application. The controller interprets the mouse and keyboard inputs from the user, commanding the model and/or the view to change as appropriate. Finally, the model manages the behavior and data of the application domain, responds to requests for information about its state (usually from the view), and responds to instructions to change state (usually from the controller).
In light of that I would answer your three main concerns thusly:
In fact a Qt component "manages the graphical [...] output", and "interprets the mouse and keyboard inputs", so it could indeed be called merged View and Controller with respect to the definition above.
I agree that you are/would be forced to merge Controller and Model (again with respect to the definition above).
I agree, again. The Model should only manage the data of the application domain. This is what they call "data". Clearly, dealing with rows and columns for example has normally nothing to do with our applications domain.
Where does it leave us? In my opinion, it is best to figure out what Qt really means when the terms "Model" and "View" are used and use the terms in their manner while we are programming with Qt. If you keep being bothered it will only slow you down, and the way things are set up in Qt does allow elegant design - which weighs more that their "wrong" naming conventions.
The terminology isn't right or wrong, it's useful or useless.
You might change the question a bit and ask why Qt isn't more MVC-friendly. The answer to is that the early Qt developers believe that decoupling V from C in GUI applications makes for bad Vs and Cs both. QWidget's design tries to make it simple to bind mouse input interperation closely with pixel output decisions, and you can see how that's not the road towards MVC.
As Model function is to respond to requests for information, I think there is nothing wrong in defining such methods as rowCount, columnCount, etc. I think Model is some kind of wrapper for data source (no matter what is it SQL table or just an array), it provides data in standard form, and you should to define methods depends on your data source structure.
I believe their terminology is correct...although in real applications I find it can be very easy to blur the lines between model, view, and controller depending on your level of abstraction: one level's view may be a higher level's model.
I feel the confusion arises from their QAbstractModelItem class. This class isn't a model item, but rather it is an interface to a model. To make their view classes interface with the model, they had to create a generic abstract interface to the model. However, a model can be a single item, a list of items, a table of 2 or more dimensions of items, etc; so their interface has to support all these model variations. Admittedly, this makes the model items fairly complex, and the glue code to make it work with an actual model does seem to stretch the metaphor a bit.
I think that ... What they call Model is in fact Controller only.
No, their "model' is definitely not a controller.
The controller is the part of user visible controls that modify the model (and therefore indirectly modify the view). For example, a "delete" button is part of the controller.
I think there is often confusion because many see something like "the controller modifies the model" and think this means the mutating functions on their model, like a "deleteRow()" method. But in classic MVC, the controller is specifically the user interface part. Methods that mutate the model are simply part of the model.
Since MVC was invented, its distinction between controller and view has become increasingly tense. Think about a text box: it both shows you some text and lets you edit it, so is it view or controller? The answer has to be that it is part of both. Back when you were working on a teletype in the 1960s the distinction was clearer – think of the ed – but that doesn't mean things were better for the user back then!
It is true that their QAbstractItemModel is rather higher level than a model would normally be. For example, items in it can have a background colour (a brush technically), which is a decidedly view-ish attribute! So there's an argument that QAbstractItemModel is more like a view and your data is the model. The truth is it's somewhere in between the classic meanings of view and model. But I can't see how it's a controller; if anything that's the QT widget that uses it.
I've got an NSArrayController bound to a mutable array in my controller, which manages an array of my model objects. The array controller is bound to my UI. It works well.
Now I'm trying to manually observe when a value changes in my model in my controller class (basically I'm marking the changed model as "needsToSave" for later on, but there are a few other tasks I have when it changes).
I've read up on KVO but I'm not entirely sure what I need to be observing... The NSArrayController? The array of objects? each model object itself? Confusion.
Any pointers would be very helpful. Thanks in advance!
In your model item add and remove methods you should start and stop observing of each item in order to know about everything that happens. This will also help you implement undo. If you need sample code I know the Hillegass book covers it (at least 2nd edition did, have checked 3rd edition yet). You could also look for sample code for implementing undo for help.
My question pertains to windows forms
Let's say I have a combobox for customer and orders, and depending on the selection made on those comboboxes I populate a datagrid for all the Order details.
I am interested in a double click event within the datagrid row.
Upon the event 2 things can happen:
the record was deleted.
one or both combobox was changed.
With no OO Experience, I am handling all that logic in the code-behind.
Is that a wrong thing to do? Should I be creating a class that returns a boolean whether to cancel the event or do something else if all the conditions are satisfied?
If I create a class that handles that logic then that class needs reference to datagrid and all the associated controls and their Previous values and current values.
I am just confused.
I'm not sure that this is an OO question: more about patterns.
If I were you, I'd look at MVC (Model View Controller), MVP (Model View Presenter) and so on. Martin Fowler is one of the main authorities on this subject.
MVVM is popular in WPF - not sure if databinding is up to it in Forms.
One of the key things is that testing is so much easier if you have logic separate from the display gubbins.
Object oriented way of doing things is something that no one can tell you in just a single shot. It's a whole new paradigm of thinking on how a problem can be solved in terms of few interacting objects. These objects are from the problem domain for which you are creating a solution.
From the question, I can easily pick out atleast two problem domain objects - one would be "Customer" and the other "Order".
May be your "Order" class is composed of various objects of "OrderItem" which is composed of a reference to one of the "Product", quatity and may be the price.
If this is getting a bit hard to understand, I'm pretty sure that you would atleast have a database with tables that provides persistent storage of data. The tables that you have, (in many cases) can correspond to the actual classes that you need to design.
You dont' have to design seperate classes that are actually going to work with the datagrid and other controls, that can stay be in the code behind. But all your business domain objects and the operations that can be performed on these objects must be encapsulated into classes.