Settings für ein CoreData Document

Diese Seite verwendet Cookies. Durch die Nutzung unserer Seite erklären Sie sich damit einverstanden, dass wir Cookies setzen. Weitere Informationen

  • Settings für ein CoreData Document

    Hi,

    ich möchte zu meinem CoreData Document weitere Daten speichern wie z.B. welcher Eintrag als letztes im Tableview selektiert war, um dieses beim erneuten Öffnen des Dokumentes wieder zu setzen. Geht das nur über eine eigene Entität oder gibt es dafür besondere Funktionen ?

    Gruß

    Claus
    2 Stunden Try & Error erspart 10 Minuten Handbuchlesen.

    Pre-Kaffee-Posts sind mit Vorsicht zu geniessen :)

  • So,

    Habe mir das geradeaus durchgelesen und bin nicht sicher ob das für meine fall die richtige Wahl ist. Es würde dann ja für jedes document irgendwo dieser State gespeichert. das würde dann u.u. Eine Menge tote Daten geben da die Daten von gelöschten Dokumenten ja nicht entfernt würden. Zudem muss ja jedes Fenster einen Unikum Identifier haben. Hier konnte ich noch den Pfad mit Filenamen des Dokumentes nehme aber toll ist das ja auch nicht. Ich denke das ganze ist mehr für statische Fenster gedacht oder?

    Gruß

    Claus
    2 Stunden Try & Error erspart 10 Minuten Handbuchlesen.

    Pre-Kaffee-Posts sind mit Vorsicht zu geniessen :)

  • kannst du nicht deiner Entity einfach noch nen Feld hinzufügen (lastSelectedIndex) welches den Index als Int abspeichert und dann beim erneuten Aufruf der App einfach checken welcher Datensatz in lastSelectedIndex einen Wert stehen hat und die Tabelle da hin scrollen lassen? Oder funktioniert das nicht so?
    [window close]

  • hmmm naja was den Speicher anbetrifft kenn ich mich nicht aus was jetzt wieviel verbraucht, aber so hätte ich es gemacht, aber ne eigene Entity Settings klingt auch gut da kannst du ja dann direkt Variablen drin abspeichern die man dann ja theoretisch in ne plist laden kann oder nen Dictionary :)
    [window close]

  • MCDan schrieb:

    Füge dem Model doch einfach ein Entity Settings mit einem Binary Attribute hinzu. In diesem kannst Du dann alle weiteren Daten zu einem Dokument als Serialized NSData ablegen.


    Hi Dan,

    Mir ging es ja eigentlich nur darum zu erfahren ob das die probate Methode ist eine eigene Entität dafür zu machen oder ob es vlt irgendwelche extra Funktionen in NSDocument z.b. gibt wo man sowas speichern kann. ich hatte da halt nichts gefunden.

    Gruß

    Claus
    2 Stunden Try & Error erspart 10 Minuten Handbuchlesen.

    Pre-Kaffee-Posts sind mit Vorsicht zu geniessen :)

  • macmoonshine schrieb:

    Ich würde es in die User-Defaults oder in eine eigene Property-List in die Preferences packen.


    Finde ich nicht gut. Nhmen wir an ich erstelle 3 Dokumente. Dann muss ich in meinen UserDefaults dafür 3 Einträge machen. Dann löscht der User im Finder 2 der Dokumente. Die Einträge in meinen UserDefaults sind damit absolete, werde aber niemals gelöscht. Somit werden die UserDefaults über die Zeit zu einem riesigen File wovon immer nur ein ganz kleiner Teil gebraucht wird.

    Gruß

    Claus
    2 Stunden Try & Error erspart 10 Minuten Handbuchlesen.

    Pre-Kaffee-Posts sind mit Vorsicht zu geniessen :)

  • Ich finde, wenn es nur um Applikationseinstellungen geht, hat Amin recht: Die gehören nicht ins Dokument. Das ist etwas vielleicht anderes, wenn diese Einstellungen auch in anderen (hypothetischen) Applikationen, diese Dokumente darstellen können, Sinn machen. Also wenn die Selektion des Tabelleneintrags einen datenspezifischen Sinn hat.

    Ansonsten kannst Du es ja wie Xcode machen: Das legt die Projektdaten im Projektbundle getrennt von den Nutzerdaten ab. Wenn Du die Nutzerdaten löschst, funktioniert das Projekt immer noch. Auf Core Data bezogen würde das wahrscheinlich bedeuten, dass Du dafür einen eigenen Entitätstyp anlegst.
    „Meine Komplikation hatte eine Komplikation.“

  • Also prinzipiell ist das Feature von Apple ja auch explizit so gewollt.
    Nur: man speichert nicht die Auswahl der Tabelle, sondern des Array Controllers.
    Und: man hat ein Dokument. In diesem Dokument kann man doch soweit ich weiß schreiben was und wie man will.
    Ergo: rein damit ins Dokument!
    «Applejack» "Don't you use your fancy mathematics to muddle the issue!"

    Iä-86! Iä-64! Awavauatsh fthagn!

    kmr schrieb:

    Ach, Du bist auch so ein leichtgläubiger Zeitgenosse, der alles glaubt, was irgendwelche Typen vor sich hin brabbeln. :-P

  • macmoonshine schrieb:

    Ich finde, wenn es nur um Applikationseinstellungen geht, hat Amin recht: Die gehören nicht ins Dokument. Das ist etwas vielleicht anderes, wenn diese Einstellungen auch in anderen (hypothetischen) Applikationen, diese Dokumente darstellen können, Sinn machen. Also wenn die Selektion des Tabelleneintrags einen datenspezifischen Sinn hat.


    Da bin ich vollkommen bei Dir. Es gibt nichts nervigeres, als wenn sich die Einstellungen eines Programmes ändern wenn man ein anderes Dokument öffnet. Das habe ich ja auch nicht vor.


    Ansonsten kannst Du es ja wie Xcode machen: Das legt die Projektdaten im Projektbundle getrennt von den Nutzerdaten ab. Wenn Du die Nutzerdaten löschst, funktioniert das Projekt immer noch. Auf Core Data bezogen würde das wahrscheinlich bedeuten, dass Du dafür einen eigenen Entitätstyp anlegst.


    In meinem Dokument zeige ich halt immer einen Detailview zu dem Tableview an, da der Tableview alleine keinen Sinn macht. (Zu viele Daten als das man für jedes Attribut eine row machen könnte/sollte/würde. Wenn nun der User sich einen Datensatz ansieht/bearbeitet, dann wäre es schön wenn er nach dem Beenden des Programms, beim nächsten Start wieder bei diesem Datensatz landen würde und sich den nicht erst wieder selber raussuchen muss.
    Ich denke im Endeffekt läuft es auf die Entität hinaus.

    Gruß

    Claus
    2 Stunden Try & Error erspart 10 Minuten Handbuchlesen.

    Pre-Kaffee-Posts sind mit Vorsicht zu geniessen :)

  • Ich würd ja jetzt fast schreien: Doku!

    NSDocument:
    - (void)encodeRestorableStateWithCoder:(NSCoder *)coder
    For example, you could use this method to record references to the data currently managed by the document and displayed by the window. (Do not store the actual data itself. Store only references to the data so that you can load it later from disk.) You must store enough data to reconfigure the document and its window to their current state during a subsequent launch of the app.

    - (void)restoreStateWithCoder:(NSCoder *)coder
    You can also use this method to reconfigure the document (or its associated window controller and window) to their previous appearance.

    + (NSArray *)restorableStateKeyPaths
    You can use this method instead of, or in addition to, the encodeRestorableStateWithCoder: and restoreStateWithCoder: methods to save and restore the state of your document. The key paths must refer to attributes that are key-value coding and Key-value observing compliant.
    When changes are detected, the specified attributes are automatically written to disk with the rest of the app’s interface-related state. At launch time, the attributes are automatically restored to their previous values.

    Da ich aber nicht weiß, ob du auch pre-Lion unterstützen willst, schreie ich mal nicht.
    «Applejack» "Don't you use your fancy mathematics to muddle the issue!"

    Iä-86! Iä-64! Awavauatsh fthagn!

    kmr schrieb:

    Ach, Du bist auch so ein leichtgläubiger Zeitgenosse, der alles glaubt, was irgendwelche Typen vor sich hin brabbeln. :-P