Settings für ein CoreData Document

Grade vor diesem Hintergrund denke ich, dass ihr alle recht habt und man speziell schaun muss was genau gewünscht ist. Vielleicht ist es ja gewünscht, dass das Dokument immer so geöffnet werden soll wie es verlassen wurde, egal auf welchem Gerät es verlassen wurde. Dann lägen Thalius und Co richtig. Vielleicht ist aber auch ein Verhalten, wie du es beschreibst, Amin, gewünscht. Dann lägst du richtig.Die Frage, was nun den richtige Weg ist benötigt nun halt noch was genau für ein Verhalten gewünscht ist.
Entspannt euch ein wenig, alles wird gut werden

Klar, es steht hier ja auch schon drin, dass es situativ ist. Aber die Selektion eines Tableviews ist wirklich extrem UI-bezogen.

In dem aktuellen Fall war es so, dass es eine längere Liste gab, die man derart konfigurieren konnte, dass man nur ausgewählte Einträge sieht. Das haben die dann – AFAIK – mit einem Attribut hidden oder so programmiert. Ich hätte das in erster Näherung auch so gemacht.

Als die Tester dann das Synching testeten, kam dann "Was soll der Blödsinn? Jetzt habe ich ja auf jedem iPhone dieselbe Auswahl." Und dies ist wesentlich UI-entfernter.

Denke dir nur, dass du die App auf dem iPad verlässt, weil du auf einen Termin musst. Unterwegs hantierst du dann mit deinem iPhone. Niemand erwartet, dass er zuhause auf dem iPad den Stand des iPhones vorfindet. Das ist sehr befremdlich.

Das kommt halt drauf an, so verallgemeinert würde ich das nicht sagen wollen. Ich mein, was machen denn z.B. Repositories in Xcode z.B. Wenn da jemand an Rechner X die Datei xyz ändert ist es ja nicht ungewöhnlich, dass man an Rechner Y sieht, dass die Datei xyz geändert wurde. Und wenn nun die Änderung noch nicht abgeschlossen war ist es u.U. sogar klug, wenn sich die Datei an Rechner Y genau so öffnet wie sie an Rechner X geschlossen wurde, mit eben gleicher Selektion und allem. Vielleicht WILL ich ja genau dieses Verhalten haben.
Es ist sicher nicht üblich, wenn ich an bisherige Anwendungen denke (es war zumindest bei mir nicht üblich), dass bei einem Neustart des Rechners sich die Fenster/Dokumente wieder öffnen, die beim Herunterfahren geöffnet waren. Zu Anfang fand ich das Verhalten auch merkwürdig, inzwischen nutze ich das Verhalten von ML und finde das sogar nicht mal mehr schlecht, im Gegenteil. Auf meinem PB mit Leopard vermisse ich dieses Verhalten inzwischen.

Bedenke doch auch mal die iCloud. Die bewirbt doch quasi, dass eine Änderung auf einem Gerät automatisch auf alle anderen Geräte gesynct (was für ein Deutsch...:D) wird. Die Welt ist im Wandel ;).

In meinen Beispiel wird die iCloud bedacht. Genau das führt zu dem angesprochenen Fehler.

Ich verstehe auch nicht, warum du die Datei mit gleicher Selektion geöffnet haben willst. Du willst sie möglicherweise mit gleichem Inhalt geöffnet haben. Das ist ja auch kein Problem, weil das sicherlich Model ist. Ansonsten hatte ich ja gerade das Beispiel der Editierposition in Texte selbst genannt.

Wie bereits gesagt: Es gibt Fälle "Zum Beispiel die Selektion in einem Tableview" ist sicherlich kein solcher Fall.

Welchen Fehler denn? Die Frage ist doch, was man will und vielleicht will man ja grade bei deinem Beispiel:

eben doch, dass man auf dem iPad den Stand vom iPhone vorfindet inklusive einer Selektion in einem TableView. Warum du dich gegen so ein Verhalten so sehr sträubst ist irgendwie niemandem klar. Du hast sicher recht, wenn du sagst das sei ein ungewöhnliches Verhalten aber warum soll das denn ein falsches Verhalten sein? Dann müssten ja auch die Restaurations-Geschichten, die mit Lion einzug hielten, auch falsch sein. Die gabs/gibts so in Leopard und Co auch nicht. Aber nur weils das vorher nicht gab heißt es doch nicht, dass es falsch ist.

Stellen wir uns ein Spiel vor welches auf iPhone und iPad läuft. Dort hat man vielleicht in einem TableView mehrere Einheiten selektiert. Wenn ich das Spiel nun "beende" auf dem iPad (eben weil ich zu einem Termin muss) und unterwegs nun mit dem iPhone weiter spielen will wäre es grade da doch ideal wenn man dort das Spiel exakt so weiter spielen könnte wie man es auf dem iPad beendet hat, mit exakt gleicher Selektion.

Ich hatte zwei Beispiele genannt. Gesträubt habe nicht ich mich, sondern die Tester. Ich habe den lediglich Recht gegeben.

Und hier ist wieder die Frage, was gewünscht ist und das gibt immer noch der Nutzer vor. Ich sage ja nicht, dass es keine Situationen gibt wo das beschriebene Verhalten nicht erwünscht ist. Es gibt halt beides. Bei deinen Testern und deiner Anwendung mag das nicht gut sein aber wir wissen ja nicht was Thallius für eine Anwendung schreibt und da kann es auch durchaus sinnvoll sein, dass die Selektion eines TableViews im Dokument gespeichert ist. Wie auch immer, wir wissen es nicht.

Die fabelhafte Erkenntnis, dass es andere Fälle geben kann, hatte ich bereits vor zwei Tagen geschrieben.

Was wir wissen:
" wie z.B. welcher Eintrag als letztes im Tableview selektiert war"

Und da ist es ganz einfach falsch.

Und genau da kommt es darauf an, welches Verhalten erwünscht ist weshalb man nicht pauschal sagen kann, dass das falsch ist. Aber ich seh schon, das hat keinen Zweck bei dir...

Richtig, es hat keinen Zweck mit mir, meine eigenen Aussagen ständig zu wiederholen. Ich sehe darin auch grundlegend keinen Sinn.

Doch du hast bis heute nicht erklärt, warum "wie z.B. welcher Eintrag als letztes im Tableview selektiert war" niemals nicht zu den Dingen gehören kann, die bei Weitergabe des nach Schließen des Programms abgespeicherten Dokumentes überall übernommen werden müssen.
Du sagtest lediglich, dass Tester eines völlig anderen Programms mit einen geringeren und weniger offensichtlichen Einschnitt der UI-Darstellung unzufrieden waren.

Du hältst beispielsweise die Cursorposition eines Textviews für eine sinnvolle abzulegende Dokumenteigenschaft, nicht aber die letzte Selektion in diesem Dokument?
Beides ändert doch das UI gravierend. Das Eine sei genehm, das Andere nicht?

Welchen Unterschied macht es zunächst, ob der zuletzt selektierte Eintrag des Tableviews beim erneuten Öffnen des Dokuments wieder selektiert ist?
In erster Linie nur den Unterschied, ob jetzt die oberste Zeile farbig hervorgehoben wurde oder irgend eine beliebige andere.
Es wird ja nichts in der Gesamtdarstellung des UI verändert, sondern nur die Hervorhebung einer einzigen Zeile in einem ansonsten komplett gefüllten TableView.
Vermutlich werden 80% der Nutzer dies noch nicht einmal bemerken.

Also: warum gehört "wie z.B. welcher Eintrag als letztes im Tableview selektiert war" niemals nicht zu den Dingen, die bei Weitergabe des nach Schließen des Programms abgespeicherten Dokuments überall übernommen werden müssen?
Wichtig ist und bleibt hierbei: nach dem Schließen des Dokumentes, denn genau dann und nur dann wird diese Information dank NSWindowRestauration in das Dokument geschrieben.
Wichtig ist auch weiterhin: die Änderungen werden erst nach erneutem Öffnen des Dokumentes angezeigt, denn genau dann und nur dann wird diese Information dank NSWindowRestauration aus dem Dokument geholt.

Ich habe nicht von "niemals nicht" gesprochen, sondern vom Gegenteil. Ich habe gesagt, dass diese Anforderung, so wie sie hier beschrieben wurde, nicht so umgesetzt werden sollte. Wenn ihr euch etwas hinzuphantasieren wollt, kann ich ja nichts dafür. Aber immerhin kenne ich gefühlt 4232394 Tableviews aus gefühlt 19283791823798 Programmen, die das alle nicht machen. Die Frage müsste also eher lauten, wie die außerordentliche Phantasie in euren Köpfen entsteht.

Ich habe auch nicht von der Cursorposition in einem Textview gesprochen. Hier hast du nun Behauptungen von mir hinzu phantasiert.

Und wenn es gar nicht bemerkt wird, muss ich nicht das MVC verletzen. Aber eine Argumentation, dass es doch richtig sein könnte, weil es doch egal sei, weil es mutmaßlich ohnehin nicht bemerkt werde, ist auch von solch intellektuellem Feinschliff, dass sich eigentlich jede Antwort von selbst erübrigt.

Ich habe immer noch nicht von niemals nicht gesprochen. Ich habe sogar ausdrücklich gesagt, dass es solche Fälle geben kann. Den Grund der Falschheit habe ich auch schon genannt: Es verletzt das MVC. Du hast schon einmal darüber nachgedacht, warum das Model hießt bei Core Data?

Dass ich das erneut erklären muss, ist an sich ein Hohn.

Du hast nicht davon gesprochen, dass man niemals nicht die Selektion des TableViews in das Dokument abspeichern soll, sondern du hast gesagt, die Anforderung, die Selektion des TableViews in das Dokument abzuspeichern sollte so nicht umgesetzt werden.
Du hast also nicht von 'die Selektion des TableViews sollte man niemals nicht im Dokument abspeichern' gesprochen, sondern von "die Selektion des TableViews sollte man niemals nicht im Dokument abspeichern."
Habe ich das jetzt richtig verstanden?

Die außerordentliche Phantasie in meinem Kopf fußt übrigens auf simpler Usability. Vielleicht habe ich mich bei 4232386 TableViews in 19283791823765 Programmen ja darüber geärgert, dass diese Mistdinger ihre letzte Selektion einfach nicht behalten wollen - obwohl es in meinen Augen ausgesprochen sinnvoll wäre.

In der Tat schriebst du nicht von der Cursorposition in einem TextView, sondern von der Position in einem Textdokument.
Doch was sollte man dann im Textdokument (dessen Textdarstellung in gefühlt 98,11% der Fälle über ein Textview realisiert ist) positionieren wollen - wenn nicht den Cursor?
Vielleicht Katzenbilder. Es werden viel zu wenig Katzenbilder in Softwareprodukte integriert, jawohlja.

"Design ist, wenn man es nicht sieht." (Gerrit Götzen, 2004)
Es ist kein unsinniger Unsinn, wenn 80% der User die Selektion des zuletzt gewählten TableView Eintrags nicht negativ auffällt, sondern ein Feature. Das nur von 20% der Nutzern bemerkt wird. Der Rest benutzt es unbemerkt.

Es verletzt eben nicht das MVC, wenn man Modelldaten in das Dokument packt. Es verletzt auch nicht das MVC, wenn man Modelldaten aus unterschiedlichen Modellen in ein Dokument packt. Es verletzt nicht einmal das MVC, wenn die Modelldaten im Dokument nicht den Modelldaten in der Anwendungsimplementierung entsprechen.
'Niemand hat die Absicht, einen Controller ins Dokument zu speichern'.

Wenn ich ein Modelldatum 'lastSelectionValue' in das Dokument packe, wird es automatisch und vollkommen logisch zu einem Modelldatum. Irgend ein Controller sollte dann freilich ein passendes View entsprechend dieses Modelldatums anpassen.
Wo liegt jetzt also genau die Verletzung des MVC?
(wir erinnern uns: das Modelldatum symbolisiert "wie z.B. welcher Eintrag als letztes im Tableview selektiert war")

Warum das bei Core Data Modell heißt ist selbsterklärend. Ebenso selbsterklärend wie ein Wert 'lastSelectionValue' nicht Controller oder View heißt.


Dass du nicht verstehen willst ebenso.

Gegenbeispiel, Meister: Von 1980 (oder seit wann gibts Macs?) bis 2011 hat ein Mac nie alle Fenster/Dokumente wieder geöffnet, die beim Herunterfahren geöffnet waren...öhm, soll ichs weiter ausführen?
Nur weil eine Funktionalität das erste Mal verwendet wird, heißt das noch lange nicht, dass sie falsch ist. Wie wäre es wenn du mal versuchst dein Gegenüber zu verstehen? Darf man auch als Amin mal