I have a pretty straightforward MVC design question.
I've got a class with a bunch of properties, and a form to present an instance of the class. Several of the class properties are arrays - some are arrays of NSStrings to be presented in a one-dimensional table view, and some are arrays of sub-objects to be presented in a two-dimensional table view (one column per sub-object property). I don't actually want to do anything with the data in any of these tables - just present the contents in a scrollable, read-only table view.
During my first attempt at bindings, I added an object controller bound to the class instance. Then, I tried to bind each column of each table view to the "selection" member of the class, with a model key path specifying the array property of the instance (and, for the two-dimensional tables, a member of the sub-object). I was surprised that this didn't work for the columns of the one-dimensional tables.
Next, I added one array controller for every table, binding it to the "selection" member of the object controller. For the one-dimensional tables, I bound the column to the array controller with no model key path; for the two-dimensional tables, I bound the column to the array controller with a model key path specifying a property of the sub-object. This works - but for a window with seven tables, I have seven array controllers! That feels like overkill, since the tables aren't doing anything other than presenting data.
My question is simple: Is my design in line with good MVC practice - do I really need all of these array controllers? Or is there a simpler way to specify my bindings (for one-dimensional and/or two-dimensional tables) that will enable me to eliminate some array controllers? When I have an array of strings in an object to be displayed in a one-column table, it feels like overkill to use an array controller bound to the object and the table.
As an ancillary question - do I really need to worry about excessive array controllers? Are they lightweight objects that I should use liberally, or resource-intensive objects that I should conserve, especially in limited resource contexts like iOS?
Related
I am currently studying for some interviews, and I've heard that at some of these interviews people are sometimes asked to build a data structure from scratch, including a hash table. However, I am having some trouble ..really understanding hash tables from a programming perspective.
I've been building these data structures from scratch using C++, and I know that using templates I can create linkedlists, dynamic arrays, binary search trees, etc, that can basically store whatever type of object (as long as that object is the only type that can be stored in that instance of the hash table). So I would assume I could create a template or "generic" hash table that depending on the instance of the hash table, could store a particular object. But I have two things that confuse me:
I know that the through a hash function, the different keys are mapped to different indices in the array that makes up the hash table. But let's say you are using the hash table you created to store objects of type Book, and then let's say you create another hash table to store objects of type People. Obviously, different types of objects will have different member attributes, and one of these attributes would have to be the key. Would this mean that basically every object that you would ever want to store on the hash table you created would have to have at least one attribute that has the same name? Because your hash function would have to have some key value to hash, so it would have to know which attribute of the object it is using as a key to hash? So for example, every object that you would wanna store in this hash table would have to have an attribute called "key" that you can use when using a hash function to map to an index of the array, no? Otherwise, how would it know what "key" to hash?
This would also lead to the problem of the hash function...I've read that depending on the datasets you're given, some hash functions are better than other. So if the hash function depends on the dataset, how could you possibly create a hash table data structure that could store any type of object?
So am I just overthinking this? Should I just learn to create an easy hash table that hashes integers when practicing for my interviews? And are hash tables in real life created generically, or do people usually come up with a different hash table depending on the type of data they have?
If this question is better suited for the Computer Science theory stack exchange, please let me know. I am just finding these little details are keeping me from truly understanding this data structure.
You need to seperate the hash table from the hash function, these are different functionalities.
There are two common practices to keep your hash table generic and still be able to properly hash objects.
The first is to assume your template type (let it be T) implements
the hash method, and use it. You don't care how it is being
implemented, as long as you have it.
The other option is to have in addition to the template type, a
template function hash(T), that needed to be provided when
declaring a hash table.
This basically solves both problems: The user, who knows the data distribution better than the library reader, is supplying the hash function, and the supplied hash function works on the supplied type, regardless of what the "key" is.
If chosen the 2nd option, you could implement some default hash functions for the known and primitive types, so users won't need to reinvent the wheel for each usage of the library, when using standard types.
How does one bind an NSArrayController's content to the entities in an ordered to-many relationship?
I have an unordered to-many relationship in my Core Data model, and an NSArrayController whose Content Set is bound to that relationship from the parent entity. This works fine, the data is accessible from the NSArrayController, no problem.
I decided during development that it would be better to allow users to manually reorder these child objects, so I changed the relationship to an ordered one. Now, when my NSArrayController is being created from my nib, the following error is presented:
Cannot create NSSet from object Relationship '...' fault on managed object ... of class _NSFaultingMutableOrderedSet
Now actually, I think this all makes sense: It's an ordered relationship, so now I'm getting an ordered set. Binding it to Content Array also would be inappropriate, since it's now an NSOrderedSet, not an array. My question is: Now how do I bind this relationship's data back into the NSArrayController?
I came across this discussion while searching to see if there've been any new developments on this front. In a shipping app I currently bind the array controller's content array to orderedSetKey.#array and it works just fine, not sure if I discovered that myself or if someone else suggested it somewhere.
The fundamental problem is that a Core Data ordered to-many relationship returns an NSOrderedSet, and NSOrderedSet is not a subclass of NSSet. Any array controller bindings that expect an NSSet will fail.
Tom Fewster has a detailed blog post describing the use of NSValueTransformer to work around this shortcoming, converting between NSOrderedSet and NSArray on the fly. He also provides a sample implementation on Github.
Here's the scenario. There are two CoreData model objects, A and B, and the relationship between them is that A has-many B, represented by the property setOfBs. I'd like to display two tables, one listing all the As (Table 1), another listing all the Bs (Table 2). As the user selects items in Table 1, the selection in Table 2 changes to reflect the value of setOfBs of the A selected in Table 1. The content of the table doesn't change, only the selection changes. And if the selection in Table 1 changes, it would change the setOfBs to reflect that.
Can this be accomplished using bindings? Or would custom logic be required?
I believe you will have to write additional logic to get this approach to work. Here's why: The selection bindings for NSArrayControllers (and all the UI objects that bind to them) are based on selection indexes but when you have an object of type A, it vends a set of B objects. Assuming you have an array controller for As and an array controller for Bs, you need a way to get from those objects to their indexes in the array of Bs in order to set the selection of the array controller for B. This isn't hard code to write, but I don't believe you'll be able to do this with bindings alone.
That said, as you speculated in your comment, this doesn't seem like a good way to edit this relationship. In the common case, TableView selection is UI state, and not model state. If you build a UI like you describe, UI state and model state become the same thing. I'm not saying it's impossible, or inherently bad, but it's not really a "standard" way to do this sort of thing. One common pattern looks like this:
Even an approach like this will require additional logic, because there appears to not be a way (out of the box) to bind to "All Bs not in the selected A's setOfBs" without writing code. Again, not difficult code to write, but it's not clear to me that this can be done with bindings alone. I could be wrong, but that's my reading of the situation.
I'm making a custom view that I want to be bindings/core data compatible and represent a collection of data (a la NSTableView)
Is there any way my view can refer to a specific subset of the elements in the collection (other than the current selection) after a change by the user?
A bit of context:
The view is going to display a number of user-moveable boxes in a 2D space. Each box corresponds to a record in the model. Several can be moved at once, and I can't rely on the delta value being the same for each box (so no adding a delta to each selected object).
I guess I'm looking for something like an id assigned to each element of the content array by NSArrayController, so that the view can associate that id with each box. My first thought was to use the the index in a content array, but this could be messed up by undo/redo. I could subclass NSArrayController and get it to auto-generate an id for each model item, but does cocoa already do something like this already? Feels like I might be missing something.
I should have mentioned that I originally tried keeping each of the content array's elements stored in the view (as Peter suggests), but had them stored as keys in an dictionary.
The objects in the view didn't match the keys in the dictionary, so I assumed this meant that NSArrayController changed the proxy objects it uses to stand for model objects.
However, it turned out that NSDictionary copies its keys, so it seems to be no good for situations where you want to associate a particular instance of an object with another.
NSMapTable is its more flexible cousin, and can be configured not to copy its keys.
Why not just refer to the objects themselves? You can keep them in a set or array, whichever is appropriate.
If you really need an identifier of some sort: What for? What are you going to do with it?
I can't find in the Docs where they explain all those fields and what they mean. Especially "Controller Key" is not clear to me.
[Copying my answer on another question…]
The controller key is the key for the (property of the controller object) you're binding to. The model key path is the key path by which the bound object can ask the model objects for more basic objects, such as strings or images, or for other model objects (i.e., drill down into the model).
An example: Let's say you have a Person objects in an array controller, and each Person has a name. You bind a table column to the array controller, controller key arrangedObjects (thereby getting the model objects), model key path name (thereby getting the value objects).
A more complex example: Suppose you have an array controller of Departments. Each Department contains Persons (employees in the department). You can bind your People array controller to the Departments controller, controller key arrangedObjects (getting the Department model objects), model key path #distinctUnionOfObjects.employees (getting the Person model objects), and then bind a table column to the People controller, controller key arrangedObjects, model key path name.
That table would be for people who work for your company; if you have a separate table of prospective employees, you can create Person objects for them, too, and they won't show up in the table of existing employees because they're not in a Department. When you hire them, you'll add them to one or more Departments; then, they'll show up in the People array controller automatically, because that array controller is observing the employees of all of the Departments.
The Controller Key pop-up menu is a way to help you discover what keys the controller (typically a NSArrayController, NSObjectController or a NSTreeController) presents.
The best example is the selection key of NSArrayControllers, which contains the set of selected objects. What is confusing is the NSObjectController presents a 'selection' key too, although the controller can control only a single object (therefore the selection = the object).
I agree that it is not clear at all. I personnally began to understand it when I bound my objects programmatically (i.e. using the bind:toObject:withKeyPath:options: method).
It has to do with key-value coding. You can bind a control in IB to a value in your controller. To connect that value, you have to specify the keypath to it. For example, if you have a textfield in IB and you want to bind it to say a field called 'name' in your controller, you would specify 'name' as the keypath. You then need to set up your name field in your controller to be accessible through key-value coding. This is done in 10.5 by using the #property and #synthesize specifiers.
Take a look at this topic: Cocoa Key Value Bindings: What are the explanations of the various options for Controller Key?
I posted an explanation of where to find definitions for all Controller Key's there.