I'm trying to understand how Core Data works in Objective-C and can't quite get the purpose of categories that have the name SomeClass+CoreDataClass and are created when we want to subclass NSManagedObject.
As far as I know, they should be created only once and not regenerated every time we need to update our entity's structure, so we can add our methods there. However, they are recreated as blank files every time I regenerate a subclass of NSManagedObject.
I think, I'm missing something, so could you explain their purpose?
+CoreDataClass is generated by xcode, you shouldn't edit it, because you can loose changes.
You can edit SomeClass, Xcode will only create it if it isn't exist.
This division was made just for programmers convenience.
You can freely move code from +CoreDataClass to main file and delete category if you wish.
Related
With dozens of models with dozens of properties each, all able to be saved to disk using the NSCoder protocol and NSKeyed(Un)archiver, it's a lot of work to create and maintain models for my iOS application. With a dozen of properties for one model, I have to:
define a dozen of properties (which is ok, because they HAVE to be defined somewhere)
fill the initWithCoder: method, that's a dozen lines and two dozen times typing/copy-pasting the property name (or a constant key), 3) some goes for encodeWithCoder:.
The risk of mistakes (either in typing, copying or changing (or not changing) things like encodeObject: to encodeInteger: is huge. Besides, it's simply a lot of manual work, which I prefer not to do. After all, we have computers to do that for us.
First I looked into something like simplifying the work. Something like this:
#define encodeObject(x) [encoder encodeObject:[self valueForKey:x] forKey:x]
#define decodeObject(x) [self setValue:[decoder decodeObjectForKey:x] forKey:x]
But that is still a lot of work. Can't this be done any simpeler?
I do not prefer to do this on runtime using introspection or something.
I am thinking about some Python script that generates/manipulates the model files and adds them to Xcode. This could be based upon some JSON description file.
Having Xcode run this automatically in the pre-build phase would be great. Meaning a single place where I define every model and every property once and never having to worry about mistakes and properties I forgot to encode/decode.
Is the anything like that out there? Are there methods to add files to an Xcode project, without messing with some unreadable Apple "XML" project files? And what about including the headers in the target.. Or maybe some other great method to save me all that work?
When I go to Editor-->CreateNSManagedObjectSubclass, and export my entities, they show up as the entity names... but another person who was working on my project before seems to have exported as their name with an underscorebefore, and these files look totally different on the inside...So I'm confused as to what's going on. Here's a google doc that contains a few relevant screenshots... Check out the second page to the two sections of fields. I'm sort of confused by them:
https://docs.google.com/document/d/1BMBqJME91Njb69JS4x3bvH0-KSmC-KLBl6QglE22jmQ/edit?usp=sharing
Can someone explain what is going on here?
You might want to read up on MOGenerator, since that's apparently what your predecessor used to generate the managed object classes. By default MOGenerator generates base classes prefixed with an underscore and initially generates stub subclasses (the ones without the underscores).
You can then write any custom code in the subclasses. That way, whenever the model changes, you can regenerate the base classes without worrying about clobbering your custom code, since by default MOGenerator won't regenerate the subclasses.
I am trying to subclass a class whose #interface and #implemetation are buried inside of another class' ".m" file in order to restyle some of the views declared within. The superclass is a cocoapod, which I am unable to modify without forking the repo, which I am really trying to avoid doing. Is there any clever/hacky way to pull this off, or is it simply impossible?
In all honesty, I fail to see why forking would be a bad idea or why you would want to avoid it. That's the entire point of forking, modifying the code to fit your need more and perhaps later merge it back if the community finds it useful as well.
You can try to hack around this by redeclaring the class or whatever, but that implementation would be far more fragile than you having a fork which you have full control over (including merging any upstream changes). I think this is more related to a mental block of thinking that a fork becomes "your" code and "your" responsibility, while in reality it is just as much to maintain as it would be to keep the hacky version working across changes to the 3rd party code.
Is it a good practice to define a category within the same .h/.m files of another class? I know it will build with no error and be exactly the same as if it was defined separately.
The main reason I want to do this is because I'm working on an open source control and I want it to have a single .h/.m file.
In general, the biggest problem with combining multiple classes and categories into the same header/implementation is impaired searchability. When a class is in a file with another class, the file name will no longer reflect the fact that the header/implementation contains your other class, making it much harder for others to look for your class.
If your project is small and self-contained, however, the searchability is less of an issue. When there is only one file to search, there is no question of where each particular piece of code is: it's all in that one file. It sounds like your project is both small and self-contained, so I see no problem in placing all code in a single source file if you want it that way.
Another alternative could be placing each class and category in a separate header/implementation pair of files, and then defining a header that includes them all. This would let you keep an ideal project organization, and let your users include a single header to use your component.
If you need this category in just one place I’d say that it’s not that bad having the category within the .m file.
Obviously, if you need that category in multiple places, you should definitely move to its own file: the convention is to name it in this way:
BaseClass+categoryName.{h,m}
e.g.:
NSString+reverseString.h
NSString+reverseString.m
I was going over a sample Cocoa app from Apple (ImageKitDemo) and noticed that one of the source files (the .m file) actually contains the definition (interface and implementation) of another class. What are the benefits of doing this?
It also has the added benefit of emphasizing the fact that a certain class is only intended to serve as an implementation detail of another class, and should not be used elsewhere.
Less total number of files in your project. Besides that, no difference. You could write an entire project in 1 .m file if you really wanted to.