#019: NSTableView mit Leben befüllen
(48:51 Minuten)
Wichtiger Hinweis für das Kompilieren unter oder für OS X 10.5: Neben dem Weglassen der Protokolle - so wie im Podcast erklärt - benutzt bitte in den TableView-Datasource-Methoden statt
NSInteger den Datentyp int! Dann läuft auch alles unter OS X 10.5.Im Übrigen wird uns der TableView auch noch in den kommenden zwei Folgen beschäftigen, bevor wir uns über die Optionen und Einstellungen Gedanken machen können, die hinter jedem Sync-Item stecken. Schließlich wollen wir den Inhalt der Tabelle auch speichern und umsortieren können.
Der Quellcode zu dieser Folge erscheint im Rahmen der angesprochenen Sondersendung diese Woche über Subversion!
Update 29.11.2009:
Wenn ihr diese Revision zukünftig aus dem SVN-Repository auschecken wollt, dann könnt ihr im Terminal folgenden Befehl eingeben:
svn checkout -r 17 https://cheddar1.svn.sourceforge.net/svnroot/cheddar1/trunk Cheddar_r17Kommentar hinzufügen
8. coco am 2. Mar 2010, 12:39 Uhr
@ingo
Wenn man den Fehler dann findet, fällt es einem wie Schuppen von den Augen. Es war der Identifier den ich statt "active" eben "on" benannt hatte. Durch deinen Tipp hatte ich den Fehler in 10 Minuten gefunden.
Herzlichen Dank und dickes Lob für euren Podcast!
coco
@ingo
Wenn man den Fehler dann findet, fällt es einem wie Schuppen von den Augen. Es war der Identifier den ich statt "active" eben "on" benannt hatte. Durch deinen Tipp hatte ich den Fehler in 10 Minuten gefunden.
Herzlichen Dank und dickes Lob für euren Podcast!
coco
7. ingo am 26. Feb 2010, 19:37 Uhr
@coco
ist natürlich so jetzt schwer zu sagen, klingt aber so, als hättest Du eine Property vergessen oder im INterfaceBuilder mit dem falschen Controller oder View verbunden oder nicht die richtigen, internen Spaltennamen eingegeben...
Auf alle Fälle findet er irgendwelche Keys nicht, also bezeichner für Variablen oder properties. Am besten mal mit dem Debugger hier und da das Programm anhalten und schrittweise durchchauen, wo die Fehlermeldung kommt!
@coco
ist natürlich so jetzt schwer zu sagen, klingt aber so, als hättest Du eine Property vergessen oder im INterfaceBuilder mit dem falschen Controller oder View verbunden oder nicht die richtigen, internen Spaltennamen eingegeben...
Auf alle Fälle findet er irgendwelche Keys nicht, also bezeichner für Variablen oder properties. Am besten mal mit dem Debugger hier und da das Programm anhalten und schrittweise durchchauen, wo die Fehlermeldung kommt!
6. coco am 26. Feb 2010, 17:24 Uhr
Hallo ihr Lieben,
ich hab die Folge 18/19 unter 10.5 nachgebaut. Leider lassen sich keine Einträge generieren. Ich bekomme folgende Fehlermeldung beim debuggen nach Klick auf den Add-Button.
2010-02-26 17:11:43.367 Cheddar[2634:813] [<SyncItem 0x122870> valueForUndefinedKey:]: this class is not key value coding-compliant for the key on.
2010-02-26 17:11:43.379 Cheddar[2634:813] [<SyncItem 0x122870> valueForUndefinedKey:]: this class is not key value coding-compliant for the key on.
Um sicher zu sein, dass es kein Tippfehler ist, hab ich die Klassen von Sourceforge Episode_19 in mein Projekt reinkopiert. Hat nicht geklappt.
Das Orginal von Peter und Ingo hab ich nach den benannten Anpassungen sofort zum Laufen gebracht. Jetzt möchte ich bloß wissen, was in meinem Projekt falsch ist. Bin dankbar für jeden Hinweis!
Lieben Gruss
von coco
Hallo ihr Lieben,
ich hab die Folge 18/19 unter 10.5 nachgebaut. Leider lassen sich keine Einträge generieren. Ich bekomme folgende Fehlermeldung beim debuggen nach Klick auf den Add-Button.
2010-02-26 17:11:43.367 Cheddar[2634:813] [<SyncItem 0x122870> valueForUndefinedKey:]: this class is not key value coding-compliant for the key on.
2010-02-26 17:11:43.379 Cheddar[2634:813] [<SyncItem 0x122870> valueForUndefinedKey:]: this class is not key value coding-compliant for the key on.
Um sicher zu sein, dass es kein Tippfehler ist, hab ich die Klassen von Sourceforge Episode_19 in mein Projekt reinkopiert. Hat nicht geklappt.
Das Orginal von Peter und Ingo hab ich nach den benannten Anpassungen sofort zum Laufen gebracht. Jetzt möchte ich bloß wissen, was in meinem Projekt falsch ist. Bin dankbar für jeden Hinweis!
Lieben Gruss
von coco
5. ingo am 27. Nov 2009, 12:41 Uhr
@ramsch:
Genau so ist es! ;)
Zu dem, was Du @McPringle geschrieben hast:
Inits, die sich gegenseitig aufrufen können sehr schnell zu Verwirrungen führen, spätestens wenn man mit Ableitungen arbeitet und jede Unterklasse solche "Scherze" betreibt. Das ist also kein schöner Code. Besser also die Initialisierungen in eine eigene Methode auslagern und diese einmal aus jedem Init aufrufen.
@ramsch:
Genau so ist es! ;)
Zu dem, was Du @McPringle geschrieben hast:
Inits, die sich gegenseitig aufrufen können sehr schnell zu Verwirrungen führen, spätestens wenn man mit Ableitungen arbeitet und jede Unterklasse solche "Scherze" betreibt. Das ist also kein schöner Code. Besser also die Initialisierungen in eine eigene Methode auslagern und diese einmal aus jedem Init aufrufen.
4. @ramsch am 26. Nov 2009, 09:36 Uhr
@McPringle:
Ich vermute, du denkst da ans Konzept der sich aufrufenden Konstruktoren (z. B. bei Java üblich und schön). Mit init-Methoden ist das wie Ingo sagte offenbar schwieriger.
@Ingo:
Mit der nonatomic-Property ist noch eine weitere Ungereimtheit vorhanden: es geht nacht meinem Verständnis nicht darum, ob es ein Objekt oder ein primitiver Datentyp ist sondern um die atomare ausführung des gets bzw. sets d. h. ob bei Concurrency (Zugriff mit mehreren Threads) garantiert wird, dass der Wert atomar und nur von einer Stelle gesetzt bzw. ausgelesen werden kann. Kannst du das bestätigen?
Gruss, Raphael
PS: Vielen Dank für euren Podcast.
PSS: Wer weiter diskutieren möchte oder mich korrigieren kann, möge dies gerne auf www.twitter.com/ramsch tun.
@McPringle:
Ich vermute, du denkst da ans Konzept der sich aufrufenden Konstruktoren (z. B. bei Java üblich und schön). Mit init-Methoden ist das wie Ingo sagte offenbar schwieriger.
@Ingo:
Mit der nonatomic-Property ist noch eine weitere Ungereimtheit vorhanden: es geht nacht meinem Verständnis nicht darum, ob es ein Objekt oder ein primitiver Datentyp ist sondern um die atomare ausführung des gets bzw. sets d. h. ob bei Concurrency (Zugriff mit mehreren Threads) garantiert wird, dass der Wert atomar und nur von einer Stelle gesetzt bzw. ausgelesen werden kann. Kannst du das bestätigen?
Gruss, Raphael
PS: Vielen Dank für euren Podcast.
PSS: Wer weiter diskutieren möchte oder mich korrigieren kann, möge dies gerne auf www.twitter.com/ramsch tun.
3. ingo am 23. Nov 2009, 11:28 Uhr
@McPringle:
Über die Lösung, wie wir Forum und Kommentare irgendwie verschmelzen lassen können denken wir auch schon eine Weile nach. Es gibt da aber ein paar Probleme, nichtmal technischer Natur: So benötigt man für einen Kommentar keine Anmeldung, was wir gerne auch so beibehalten würden. Nicht jeder unserer Zuschauer möchte sich am Forum anmelden und wir wollen auch keine "Zwangsanmeldung". Für den Betrieb eines Forums benötigt man aber heutzutage zwingend eine Anmeldung.
Mit Atomic und Nonatomic hast Du natürlich recht. Ich hatte da aus irgendeinem Grund eine andere Bedeutung im Kopf. Danke für den Hinweis! Ich werde die Property-Optionen nochmal alle ansprechen bzw einen Artikel im bereich Grundlagen dazu schreiben...
Das mit dem Aufrufen des eigenen Inits kann zu Problemen führen, besonders unter ObjectiveC. Man kann init ja leider nur über "self" oder "super" aufrufen. Da "self" Late Bound ist, ruft man unter Umständen das falsche init auf, und das dann womöglich doppelt oder gar in einer Endlosschleife - z.B. wenn die Klasse abgeleitet wurde.
Trotzdem ist unser Ansatz natürlich etwas schlampig, allerdings mit voller Absicht. :) Wenn der Klasse im Laufe des Projekts weitere Instanzvariablen hinzugefügt werden wollte ich zeigen, warum es Sinn macht, dass man die Initialisierung in eine eigene Methode auslagert. ;.)
@McPringle:
Über die Lösung, wie wir Forum und Kommentare irgendwie verschmelzen lassen können denken wir auch schon eine Weile nach. Es gibt da aber ein paar Probleme, nichtmal technischer Natur: So benötigt man für einen Kommentar keine Anmeldung, was wir gerne auch so beibehalten würden. Nicht jeder unserer Zuschauer möchte sich am Forum anmelden und wir wollen auch keine "Zwangsanmeldung". Für den Betrieb eines Forums benötigt man aber heutzutage zwingend eine Anmeldung.
Mit Atomic und Nonatomic hast Du natürlich recht. Ich hatte da aus irgendeinem Grund eine andere Bedeutung im Kopf. Danke für den Hinweis! Ich werde die Property-Optionen nochmal alle ansprechen bzw einen Artikel im bereich Grundlagen dazu schreiben...
Das mit dem Aufrufen des eigenen Inits kann zu Problemen führen, besonders unter ObjectiveC. Man kann init ja leider nur über "self" oder "super" aufrufen. Da "self" Late Bound ist, ruft man unter Umständen das falsche init auf, und das dann womöglich doppelt oder gar in einer Endlosschleife - z.B. wenn die Klasse abgeleitet wurde.
Trotzdem ist unser Ansatz natürlich etwas schlampig, allerdings mit voller Absicht. :) Wenn der Klasse im Laufe des Projekts weitere Instanzvariablen hinzugefügt werden wollte ich zeigen, warum es Sinn macht, dass man die Initialisierung in eine eigene Methode auslagert. ;.)
2. McPringle am 22. Nov 2009, 16:31 Uhr
Hallo Peter und Ingo!
Vielen Dank für diese Folge. Mir fiel gerade ein, ob es nicht vielleicht machbar wäre, ein Forum "Diskussionen zum Podcast" einzurichten und den Kommentar-Link dorthin umzulenken. Zum Einen wäre dann dort alles gesammelt, zum Anderen bietet das Forum Vorteile wie beispielsweise Threads.
Habe ich richtig gehört, dass du in dieser Folge bezüglich der Properties gesagt hast, dass "nonatomic" die Standard-Einstellung ist? Das ist nicht ganz richtig: Die Standard-Einstellung ist "atomic" und mittels "nonatomic" kann man sie ausschalten. Wenn "nonatomic" die Standard-Einstellung wäre, wäre das ganz schön blöd, denn es gibt kein "atomic" Keyword für die Properties… :)
Ausserdem hätte ich die init-Methoden im SyncItem etwas anders gemacht. So wie ihr das macht gibt es doppelten Code ("active" auf "YES" setzen und Aufruf von "super init"). Ich möchte vorschlagen, dass die "initWithTitle" die andere "init" aufruft. So wird doppelter Code vermieden und Erweiterungen sind einfacher (z.B. weitere Variablen auf Standard-Einstellungen setzen, das muss auch nur in der einen "init" Methode gemacht werden).
Ansonsten: Super Podcast, weiter so! Würde am Liebsten wie Paulchen an der Uhr drehen (auf Mittwoch oder so vorstellen)… :)
Danke!
McPringle
Hallo Peter und Ingo!
Vielen Dank für diese Folge. Mir fiel gerade ein, ob es nicht vielleicht machbar wäre, ein Forum "Diskussionen zum Podcast" einzurichten und den Kommentar-Link dorthin umzulenken. Zum Einen wäre dann dort alles gesammelt, zum Anderen bietet das Forum Vorteile wie beispielsweise Threads.
Habe ich richtig gehört, dass du in dieser Folge bezüglich der Properties gesagt hast, dass "nonatomic" die Standard-Einstellung ist? Das ist nicht ganz richtig: Die Standard-Einstellung ist "atomic" und mittels "nonatomic" kann man sie ausschalten. Wenn "nonatomic" die Standard-Einstellung wäre, wäre das ganz schön blöd, denn es gibt kein "atomic" Keyword für die Properties… :)
Ausserdem hätte ich die init-Methoden im SyncItem etwas anders gemacht. So wie ihr das macht gibt es doppelten Code ("active" auf "YES" setzen und Aufruf von "super init"). Ich möchte vorschlagen, dass die "initWithTitle" die andere "init" aufruft. So wird doppelter Code vermieden und Erweiterungen sind einfacher (z.B. weitere Variablen auf Standard-Einstellungen setzen, das muss auch nur in der einen "init" Methode gemacht werden).
Ansonsten: Super Podcast, weiter so! Würde am Liebsten wie Paulchen an der Uhr drehen (auf Mittwoch oder so vorstellen)… :)
Danke!
McPringle
1. Manuel am 22. Nov 2009, 13:33 Uhr
Super Sendung!
Werde sie mir nur noch einmal anschauen, damit ich auch alles verstehe.
Manuel
Super Sendung!
Werde sie mir nur noch einmal anschauen, damit ich auch alles verstehe.
Manuel
http://www.mac-talk.eu/entwickler/71-videotutorials-zu-objective-c.html