Code Exchange between NSDocument and UIDocument

Question

I created a document-based application that uses Core Data. First I created the Mac version, and now that it works correctly, I’m moving on to creating the iOS version.

I just can't figure out how to maximize code reuse between iOS / mac versions in relation to the Core data bit, since they don't use the same classes.

My document class that handles persistence is a subclass of NSPersistentDocument . My intention is that a well-designed model class should work in both environments, especially since I don’t do everything that is very bizarre with basic data.

Now, as NSPersistentDocument available in iOS, I hit the wall. I tried to get around this using #if TARGET_OS_MAC and TARGET_OS_IPHONE and thereby make it a subclass of UIManagedDocument in the iOS version. That would obviously be convenient, but I can't get it to work like that. And it really looks pretty dirty, since there is a lot of other material that should also be conditional.

I also tried to build the atop classes of NSDocument / UIDocument , instead I implement Core data bindings myself, but it also looks pretty confusing, and I don't think this is the right way.

Question:

It seems like a good idea to me to reuse the same class of documents between versions of iOS / mac, but maybe I'm naive.

What is the best way to do this?

Should I forget about code sharing and create a separate document class for the iOS version that emulates all the methods that are present in the Mac version?

Answer 1

(Extract this from my comment.)

In general, the situation where you have two classes that should inherit from different superclasses, but who also want to use a lot of code, is composition. Put the common code in a separate class; your subclasses NSDocument and UIDocument can store an instance of this class and report it whenever they need to call this common code. (Although, as @noa mentions, you might be wondering if all this code should belong in your document class.)

Of course, then you can write a bunch of methods that read as follows:

 - (id)doSomething { return [sharedController doSomething] } 

This can be a pain ... so you can take a look at the Objective-C message forwarding system .

Answer 2

Am I right that the code you want to split is related to the model? I suggest refactoring this code for a separate object that contains both an NSDocument and a UIDocument (as the reker suggested above).

I am using a DocumentRoot Core Data object with my own subclass of NSManagedObject , but if there are no properties that you want to control using Core Data, you can simply subclass NSObject .

This may seem strange, but NSDocument and UIDocument are actually controller classes. (To be specific, they are part of the controller model.) Their job is to load the model, configure windows, and save the model. If you need to provide an interface for accessing higher-level model objects, it can be in the root directory or in the helper class instead.

Similar to the NSPersistentDocument task is to configure the context of the managed object, as well as save and save the stored storage and descriptor. It is not necessary to provide a complete interface for accessing the model.