In my project I have two text fields which are bound to a mutable dictionary. I want to make a third text field that is the first field divided by the second. However when I try to do this inside the Model Key Path in the bindings tab in Interface Builder it says it is invalid. How can I get this to work?
You cannot perform arbitrary arithmetic operations or use arbitrary expressions in a key or key path. A key specifies a property provided by an object, and a key path specifies a sequence of properties. Although there are some variations such as collection operators, they do not apply to your particular setting.
That said, you could try:
Using a custom class instead of a dictionary and exposing a property that represents the arithmetic operation based on those two other properties. The Key-Value Observing Programming Guide has a section on that.
Using a custom value transformer that would transform the dictionary into the result of the arithmetic operation.
Using a category on NSDictionary to expose a property representing the arithmetic operation. I personally think this is overkill and wouldn’t really recommend it.
Not using bindings at all and performing the arithmetic operation directly in your application delegate, window controller, or view controller.
Related
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.
The documentation for -[NSObject scriptingValueForSpecifier:] says:
You can override this method to customize the evaluation of object specifiers…
I want to do this to make AppleScript lookups in my app more efficient. There are certain types of whose tests where I could do a hash lookup instead of having AppleScript ask for every single object and then query their properties one-by-one. The problem is that if I receive a NSWhoseSpecifier, I can get its test, which is a NSSpecifierTest, but there doesn’t seem to be a way to look inside the NSSpecifierTest to figure out the property being tested. Everything but the initializers and the -isTrue method are private.
Let's make a distinction. If you merely want to customize the values returned by a whose clause — in the sense of fine-tuning results — then you would override scriptingValueForSpecifier for the object in question. For example, say you have an object called 'box' that has a property called 'color,' and you want a statement like every box whose color is blue to also return boxes whose color is 'aqua,' 'teal,' or 'navy' (which are all shades of blue), then you would override scriptingValueForSpecifier to implement that.
However, if your goal is to make a more efficient form of whose test, you're probably going to have to implement appropriate methods from the NSScriptingComparisonMethods protocol. These are the routines that AppleScript uses to evaluate scripting object comparisons through NSSpecifierTest (which is what NSWhoseSpecifier) relies on). Again, you'd override these methods on your object(s) to provide different methods for doing evaluations.
As a last resort, you might try subclassing NSWhoseSpecifier or NSSpecifierTest, with the understanding that these are opaque classes for which Apple discourages subclassing. I'm not entirely certain how you would implement those subclasses; you'd probably have to register your subclass with NSScriptSuiteRegistry commands.
It looks like it will be possible to override -scriptingValueForSpecifier: and then ask the NSScriptObjectSpecifier for its descriptor. This produces an NSAppleEventDescriptor that has the needed information, but it has to be interpreted manually.
There is a pattern or term that is used to avoid codes like
myObject.fieldA.fieldB.fieldC
something like this. I forgot what this term is called. Can anyone let me know about it?
It violates the Law of Demeter, which states that code should only access its own local variables, parameters, and instance members.
It could be a case of of feature envy, where a class calls a lot of getters or accesses a lot of data from another class.
If these are really fields, they are poorly encapsulated (i.e., not behind a function), and any change to these fields forces you to modify all code that's using them.
Testing such code becomes hard, as you will have to mock not only fieldA, but also that's fieldB, and in turn that's fieldC.
I think you are trying to create a new object and add certain properties to that object. If that is the case then it's Builder design patten where you seperate the construction and representation.
If you are trying to call a certain field with the above shown code then your design is very poor. An object should store only it's own properties.
I'm showing the contents of an array of strings with an NSTableView via binding through an Array Controller.
I have "NSString" in Class Name in the attributes inspector for the Array Controller and in the Model Key Path of the Array Controller's binding inspector I have the path to my array. And I have the only column of the table bound in its Value section to the Array Controller without Model Key Path specified (it's just an array of strings).
As a result, the array's strings are displayed fine in the table. But I can't edit any of the rows:
2015-06-17 15:48:44.285 ProjectName[9043:123132] An uncaught exception was raised
2015-06-17 15:48:44.285 ProjectName[9043:123132] Error setting value for key path of object five (from bound object <NSTableColumn: 0x618000082d50> identifier: (null)): [<Swift._NSContiguousString 0x608000045d60> setValue:forUndefinedKey:]: this class is not key value coding-compliant for the key .
"five" is the fifth string in the array that I was trying to edit. And as you can see there is a gap in "path of" because the Model Key Path is empty for the column's values.
So do I somehow refer to the string itself in the Model Key Path to make the array editable via the table?
The Class Name should absolutely be set to a valid class. The bigger problem is that the array controller doesn't really play nicely with arrays of strings. There's no (reasonable) way to use -setValue:forKey: on a string since the string is itself what's being edited (replaced), not some property (like "displayName").
I know it seems wasteful, but if you really must use an array controller (more on that in a moment), you should just create a class with a string property and set that as the controller's class name and maintain an array of that class instead of plain strings. Say your array of strings represents tags. Make a Tag class with a name property of type String (or NSString). Set your controller's class name to Tag. This way, there's a key path to which to bind.
But if you really don't see yourself needing anything but an array of strings, you could just use the standard (and infinitely more flexible) [NSTableViewDataSource][1] protocol and good old-fashioned actions triggered by buttons (like Add and Remove). This way you're not fighting the Cocoa Bindings / KVC / KVO mechanisms for what in this case amounts to too-primitive a type (string) for a very abstract controller.
As to amount of work, it's almost "six of one half-dozen of the other" but not quite -- I'd go with the "make it a class with a name property" route for two reasons: 1) It's less work than spinning up a whole table controller / data source, and 2) It's likely you'll later wish you had a more extensible class instead of a simple string for a "list of stuff" even if you don't think so now.
I've been using mogenerator for a while now, and while there is a reasonable Getting Started Guide and a Stack Exchange article on the command line options, I haven't found a good guide for all of the functionality it provides.
In short: what, above and beyond the classes that Core Data provides for you, what does mogenerator actually generate?
(Frankly, I kept finding little pleasant surprises in the headers/implementations that I didn't realize were in there and I decided to step through the mogenerator templates and code and document what I found in a Stack Exchange Q&A. I'd love to see additional answers and edits, however. )
In addition to its core feature of a two class system, mogenerator helps you by automatically implementing a number of best practices regarding Core Data in your machine header and implementation files.
Property Accessors
Methods to access the attributes of your Entities are the core of what mogenerator generates. But there are some nice features implemented in the accessors above and beyond what the out of the box Xcode class generator provides to you.
Scalar Accessors
Xcode's built in generator gives you the option of "use scalar properties for primitive data types". This option gives you choice of having Xcode create properties with NSTimeIntervals instead of NSDates for date types, BOOLs instead of NSNumbers for boolean types, and int16_t (or similar) rather than NSNumbers.
I find this infuriating because most of the time I prefer the primitive types, but not for NSDates which are much more useful than a NSTimeInterval. So Core Data is giving me the choice of objects, in which case I will be constantly unboxing stuff and making stupid mistakes like if(myBooleanAttribute) (which is always YES because myBooleanAttribute is a NSNumber, not a BOOL). Or I can have scalars, but in that case, I get NSTimeIntervals that I'll always have to convert to NSDates. Or I can hand edit all of the generated files by hand to give me my desired mix of NSDates and BOOLs.
On the other hand, mogenerator provides you with both options. For example, you will get both a myBooleanAttribute getter that gives you an NSNumber (for easy storage in an NSArray) and a myBooleanAttributeValue getter that gives you an actual BOOL. Same with integers and floats. (Mogenerator does not generate NSTimeInterval accessors: only NSDates.)
Typed Transformable Properties
If you have a transformable property, you can set a specific UserInfo key ( attributeValueClassName ) in the attribute that will specify the class that your property will return/accept. (And it will properly forward declare the class etc.) The only place I found this documented was on Verious.
In contrast, the Xcode code generator will only type these transformable attributes as id types.
Validation Declaration
While mogenerator does not automatically generate any validation methods, it does include the proper signature as a comment in the machine h file. The seems to largely be for historical reasons, but it does mean that it is easy to copy and paste the signature if you decide to implement it in your human file implementation. (I wouldn't actually uncomment the declaration as you aren't supposed to call validation directly.)
Primitive Accessors
Core Data already provides you these accessors to the primitive values, but for some reason doesn't include them in its Xcode generated headers. Having mogenerator include them in its header files makes it much easier to access a primitive value.
Fetched Properties
mogenerator will generate accessors for fetched properties. As far as I can tell there is no way to have the Xcode generator do this.
Helper methods
Automatic NSFetchedResultsController generation
If you have a to many relationship in your Entity and you pass --template-var frc=true into mogenerator, mogenerator will automatically generate a method to create a fetch request for the child objects associated with a parent object. It even automatically generates a unique cache name, and isolates everything inside an #if TARGET_OS_IPHONE preprocessor macro.
Even if this doesn't fit your particular needs, it is a great example of how the templates can be extended.
+fetchMyFetchRequest:moc_
If you like defining your fetch requests in the model, this is a lot better way to retrieve them than hardcoded strings.
-MyEntitySet
Mogenerator uses the magic of KVC to give you a NSMutableSet proxy into your relationships.
+entityName
Need to provide a entity name to a NSFetchRequest or other Core Data method? It's easy to avoid hard coded strings by using this simple method that returns the name of the entity as an NSString.
+insertInManagedObjectContext: and entityInManagedObjectContext:
Another way to avoid hardcoding entity names is to use these helper methods.
Typed object ids
Each of your headers and implementations also includes a MyEntityID class. They are empty interfaces and implementations that merely subclass the NSManagedObjectID class. Also, each model class has a helper method called objectID that overrides the standard objectID method in NSManagedObject. The helper method does nothing but cast the superclass's return value to the MyEntityID type.
The net result: the compiler can catch your mistakes if you ever accidentally interchange your object ids from different entities.
Miscellaneous
Subclassing a Custom Superclass
One of the command line options is --base-class: which allows you to specify a base class that all of your generated classes will inherit from. This is very useful, either so that you can have a base class where you define convenience methods (which, given Core Data, you probably should) or so you can use an off the shelf Core Data toolkit like SSDataKit (or both).
includem
A simple little thing, but if you specify a --includem argument, mogenerator will generate a header file that includes all of your model header files. Convenient if you want to include all of your headers in a PCH, or something some other standard header you include.
Const Definitions of All Attributes, Relationships, Fetched Properties
An extern declaration of a struct is included in the header that has an NSString defined for every attribute and relationship defined in your Entity. This allows you to define predicates and other parameters, without baking the names of your entities into your strings. For example,
req.predicate = [NSPredicate predicateWithFormat:
#"(%K == YES) AND (%K <= %#)",MyObject.favorite, MyObject.availableDate, [NSDate date]];
(This type of struct used for "namespaced" constants is described My Mike Ash on his blog
const Definitions of User Info Keys/Values
Similarly an extern declaration of a struct is defined in the header that includes the keys as members of the struct, and the values as a values. i.e.
NSLog(#"User info for key my key is %#",MyObjectInfo.mykey) //will log "myvalue"
Alternate Templates
One of the interesting things about mogenerator is that in building mogenerator its author (Wolf Rentzsch) has basically built a generic parser and templating engine for the xcdatamodel files produced by Xcode. So you don't need to use the mogenerator templates. You can provide your own with a simple command line argument. There are lots of user contributed templates on the GitHub site.
In fact, you don't even have to use Core Data. Many of the contributed templates allow you to generate a series of ordinary NSObject model classes based on the data model. (So called PONSOs: "plain old nsobjects"). Want to use the data modeler in Xcode, but some other persistence mechanism? mogenerator can help you there.
You don't even need to generate objects at all: another interesting submitted template just provides a diff of two different model versions.