3

what approach for adding custom methods to Core Data managed objects in separate files? In particular the requirements would be I guess:

  1. don't want to touch the XCode4 generated classes (i.e. so can regenerator them anytime and not have to redo changes within them)
  2. can effectively add methods to the generated classes (assumption is the class names don't change)

Note - I'm aware of mogenerator but I'm not happy with it entirely at the moment noting https://github.com/rentzsch/mogenerator/issues/55

Would the simple and best answer be just Objective-C: Categories?

Greg
  • 34,042
  • 79
  • 253
  • 454
  • good question - I asked basically the same at the beginning of my core data experience - still haven't gotten further with it. Hope there is an answer!! – user387184 Apr 22 '11 at 03:03

2 Answers2

1

Fixing mogenerator would be the best answer :-).

mogenerator uses subclasses, so you could always do that, but categories would work as well.

gerry3
  • 21,420
  • 9
  • 66
  • 74
0

I just tried... What do you think about a simple #include "included_dataStuff" and putting all your extra code into the "included_dataStuff" file.

There are two possibilities:

  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.

What do you think about that?

user387184
  • 10,953
  • 12
  • 77
  • 147
  • thanks - would want the code formatting so options 1 it would have to be - questions would be (a) how does this compare to using categories?, and (b) wondering if there would be a way to permanently accept the warnings so you don't keep seeing them? – Greg Apr 22 '11 at 04:41
  • @user387184 What is the purpose of this file? Why not subclass or use categories? Isn't this an Objective-C source file? If so, it should have the extension ".m". – gerry3 Apr 22 '11 at 21:55
  • Yes, as mentioned above, there are two possibilities. The *.m file works but causes the warnings. Taking the m away causes the code format to flatten but no warnings. I agree however, categories is a better choice in this case! – user387184 Apr 23 '11 at 05:27