2012-03-26 14 views
4

Ich habe eine dokumentenbasierte App erstellt, die Core Data verwendet. Ich habe zuerst die Mac-Version erstellt, und jetzt, da es richtig funktioniert, werde ich eine iOS-Version davon erstellen.Freigabe von Code zwischen NSDocument und UIDocument

Ich kann mir einfach nicht vorstellen, wie man die Wiederverwendung von Code zwischen den iOS/Mac-Versionen im Hinblick auf das Core-Datenbit maximiert, da sie nicht die gleichen Klassen verwenden.

Meine Dokumentklasse, die das Speichern behandelt, ist eine Unterklasse von NSPersistentDocument. Meine Absicht ist, dass eine gut entworfene Modellklasse in beiden Umgebungen funktionieren sollte, vor allem, weil ich in Bezug auf Core-Daten nicht allzu viel Fantasie betreibe.

Jetzt, da NSPersistentDocument nicht in iOS verfügbar ist, trete ich auf eine Wand. Ich habe versucht, dies zu umgehen, indem Sie #if TARGET_OS_MAC and TARGET_OS_IPHONE verwenden und auf diese Weise eine Unterklasse von in der iOS-Version machen. Das wäre offensichtlich bequem gewesen, aber ich kann es anscheinend nicht so machen. Und es sieht wirklich ziemlich unordentlich aus, da es eine Menge anderer Sachen gibt, die ebenfalls konditioniert werden müssen.

Ich habe auch versucht, statt NSDocument/UIDocument oben auf die Klassen baut, hakt mich die Kerndaten der Umsetzung, aber es sieht auch ziemlich chaotisch, mich zu verlassen, es ist nicht der richtige Weg, das Denken zu gehen.

Die Frage:

Für mich scheint es wie eine gute Idee, die gleiche Dokumentenklasse zwischen dem iOS/Mac-Versionen wieder zu verwenden, aber vielleicht naiv mir zu sein.

Was ist der beste Weg, dies zu tun?

Sollte ich die Code-Freigabe vergessen und eine separate Dokumentklasse für die iOS-Version erstellen, die alle in der Mac-Version vorhandenen Methoden emuliert?

+1

Ich kann nicht mit diesem spezifischen Szenario sprechen, aber es könnte hilfreich sein, den allgemeinen Fall zu betrachten: Sie haben zwei Klassen, die von verschiedenen Oberklassen erben müssen, aber Sie möchten Code zwischen ihnen teilen. Die übliche Antwort auf solche (in ObjC) ist die Zusammensetzung: setze den geteilten Code in eine andere Klasse und referenziere eine Instanz dieser Klasse von beiden. – rickster

+0

Das scheint eine gute Idee zu sein. Bitte post ist eine Antwort, und ich werde es auswählen. Eine weitere Frage, es scheint, als ob ich in meinem zusammengesetzten Objekt 20-30 Methoden schreibe, die sie nur an die exakt gleiche Methode auf dem spezialisierten Empfänger weiterleitet. Gibt es einen schöneren Weg? – Frost

Antwort

2

(Bringing diese über von meinem Kommentar.)

Im Allgemeinen ist die Situation, in der Sie zwei Klassen haben, die von verschiedenen Oberklassen erben müssen, sondern die auch eine Menge Code teilen möchtenZusammensetzung ist.Setzen Sie den gemeinsamen Code in eine separate Klasse. Ihre Unterklassen NSDocument und UIDocument können jeweils eine Instanz dieser Klasse behalten und sie melden, wenn sie diesen gemeinsamen Code aufrufen müssen. (Obwohl als @noa erwähnt, mögen Sie vielleicht zu prüfen, ob alle diesen Code in der Dokumentenklasse gehören mit zu beginnen.)

Natürlich dann könnten Sie eine Reihe von Methoden am Ende zu schreiben, wie zu lesen:

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

Das kann ein Schmerz sein ... so sollten Sie vielleicht in message forwarding System von Objective-C suchen.

+0

Hinweis für zukünftige Leser: Ich wählte dies als die Antwort auf die Frage, aber ich musste es in meinem speziellen Fall aufgeben, nachdem es offensichtlich wurde, dass es viele Weiterleitungsmethoden gibt, die geschrieben und auf dem neuesten Stand gehalten werden müssen. Stattdessen ging ich getrennte Klassen für die iOS- und Mac-Implementierungen, da es praktischer schien. – Frost

3

Habe ich Recht, dass der Code, den Sie teilen möchten, modellbezogen ist? Ich schlage vor, diesen Code zu einem separaten Objekt zu refactorisieren, das sowohl NSDocument als auch UIDocument enthält (wie Rickster oben vorgeschlagen).

ich eine DocumentRoot Core Data Einheit mit eigener NSManagedObject Unterklasse verwenden, aber wenn es keine Objekte sind Sie Core Data verwalten, können Sie nur NSObject Unterklasse.

Das mag seltsam klingen, aber NSDocument und UIDocument sind tatsächlich Controller-Klassen. (Um genau zu sein, sind sie Teil des Model-Controllers.) Ihre Aufgaben sind das Laden des Modells, das Einrichten von Fenstern und das Speichern des Modells. Wenn Sie eine Schnittstelle für den Zugriff auf Modellobjekte auf höherer Ebene bereitstellen müssen, könnte sie sich stattdessen in einer Dokumentstamm- oder Modellhelferklasse befinden.

In ähnlicher Weise NSPersistentDocument 's Auftrag besteht darin, den verwalteten Objektkontext und den persistenten Speicher zu konfigurieren und laden und speichern. Es muss nicht unbedingt eine vollständige Schnittstelle für den Zugriff auf das Modell bereitstellen.

Verwandte Themen