开发者

How to modify behaviour of NSManagedObject class in reusable way which can be accessed in Bindings?

开发者 https://www.devze.com 2023-03-02 13:44 出处:网络
Xcode auto-generates the class implementations for your NSMO entities - great. But we often need to customize them. If you ever forget that you customized these files, Xcode will happily \"delete\" (

Xcode auto-generates the class implementations for your NSMO entities - great.

But we often need to customize them. If you ever forget that you customized these files, Xcode will happily "delete" (overwrite) and remove all your code.

So ... a classic trick was to:

  1. Create the NSManagedObject's in Apple's model view
  2. Generate the classes
  3. Create new classes which use Categories to extend the original classes, adding the modified behaviour
  4. Import the custom-category-headers rather than the base NSMO headers, there开发者_JS百科by getting the "new" behaviour

This works great: put custom code in the category, and when you auto-generate files using Xcode, you never lose anything.

But ... now I'm using Bindings / Mac OS code, and Bindings are great, but I have no idea how to make a Binding "import" the derived header (with the category, and the modified methods / custom behaviour)?

e.g. if I have an ArrayController (very common) that's holding NSMO instances, you normally tell it the "Entity Name" (e.g. "MyCoreDataEntity"), and it requests the NSMO with that class name. But that will never load the category, so it will never pick up the customized version of the class.

How do you get around this? Either: how do you load in the category-version of a class?

OR: how do you write custom code without using categories and AVOID Xcode deleting all your code when it feels like it?


I must admit since I use cocoa touch there is no binding available - so I really do not know if my suggestion is applicable in your case.

However, maybe this helps?

There is an alternative to categories for core data additions - not as "sophisticated" as categories - I know.

One may use #include statements:

There are two alternatives:

  1. create a new ClassFile, delete the include "header.h", (delete the header.h), put the extra code there. It compiles but brings the two warnings: (which are understandable) [WARN]warning: no rule to process file '$(PROJECT_DIR)/Classes/../included_dataStuff' of type text for architecture armv6 [WARN]warning: no rule to process file '$(PROJECT_DIR)/Classes/../included_dataStuff' of type text for architecture armv7

  2. create a new "empty" file and put the extra code there. This does not produce any warnings.

The difference between 1 and 2 is that while the code formatting remains in the first alternatve (having to accept the 2 warnings) in the second all the code format is lost and its treated like normal text (but there is no warning)

I guess I would prefer the first. Of course, the only modification to the generated code file would be the #include statement.


The easiest solution would be to subclass NSArrayController, import the category and then use the subclass in IB. That way your bindings should automatically know of the category.

MoGenerator used to be good at generating custom classes without having to overwrite anything. I'm tinkering with updating it or something like it for Xcode 4.x since the original authors don't seem to have the time to do so.

0

精彩评论

暂无评论...
验证码 换一张
取 消

关注公众号