#026 Cheddar: Drag & Drop von Dateien
(37:04 Minuten)
Am Ende der Folge haben wir Programmcode, der noch so einige Bugs hat - und das ist gleichzeitig eine kleine Vorschau auf Folge 27, in der wir den Code etwas aufräumen werden: Wir betreiben das nächste Mal also Bugfixing und machen den Code schöner. Fix & CleanUp nimmt wie bei jedem Programm einige Zeit in Anspruch.
Ihr bekommt den Quellcode zu dieser Folge in unserem SVN-Repository direkt aus Xcode heraus unter "releases/episode_026", oder am Terminal mit:
svn checkout https://cheddar1.svn.sourceforge.net/svnroot/cheddar1/releases/episode_026
Kommentar hinzufügen
11. Raphael am 4. Feb 2010, 03:28 Uhr
Hier ein Lösungsansatz: http://stackoverflow.com/questions/2097822/retain-counts-of-iboutlets
Hier ein Lösungsansatz: http://stackoverflow.com/questions/2097822/retain-counts-of-iboutlets
10. ingo am 24. Jan 2010, 20:33 Uhr
@skytek:
Naja, wir nehmen als Gästebuch die Bewertungen in iTunes, da kannst Du Dich gerne verewigen, das freut uns!
Ansonsten beherbergen wir ja schon ein Forum und diese Kommentare, das ist uns zusammen mit iTunes genug Zeug, was wir pflegen müssen!
Obendrein ist ein Gästebuch ja totaaaal Old Skool! :-D
Vielen Dank also für das fette Lob!
@skytek:
Naja, wir nehmen als Gästebuch die Bewertungen in iTunes, da kannst Du Dich gerne verewigen, das freut uns!
Ansonsten beherbergen wir ja schon ein Forum und diese Kommentare, das ist uns zusammen mit iTunes genug Zeug, was wir pflegen müssen!
Obendrein ist ein Gästebuch ja totaaaal Old Skool! :-D
Vielen Dank also für das fette Lob!
9. ingo am 24. Jan 2010, 20:32 Uhr
@MCplusplus:
Stimmt, haben wir noch gar nicht erklärt! Mist! ;-)
Jedenfalls kann man auch so drauf kommen, 0x ist jedenfalls der Code (auch x-Code genannt), um eine hexadezimale Zahl in C-Dialekten einzuleiten. Habe ich was vergessen zu erklären? Ich denke nicht... :-D
@MCplusplus:
Stimmt, haben wir noch gar nicht erklärt! Mist! ;-)
Jedenfalls kann man auch so drauf kommen, 0x ist jedenfalls der Code (auch x-Code genannt), um eine hexadezimale Zahl in C-Dialekten einzuleiten. Habe ich was vergessen zu erklären? Ich denke nicht... :-D
8. skytek am 24. Jan 2010, 09:00 Uhr
Hi Ing, hi Peter,
in Ermangelung eines Gästebuchs hier mal ein lobender Off-Topic Kommentar. Ich habe durch Zufall diesen Video-Podcast beim Apple-TV surfen entdeckt und bin absolut begeistert. Es macht große Freude Euch bei der wirklich großartigen Einführung zu XCode zuzusehen. Ich bin seit 10 Jahren Programmierer für große Webanwendungen, habe aber mich aber bisher noch nicht mit XCode und Cocoa-Apps beschäftigt und daher endlich mal reingeschnuppert. Die Nacht endete mit über 10 angeschauten Folgen und dem sofortigen Einstieg in ein eigenes Projekt für meine Projekt-Verwaltung (Tests und MVC-Konzept) ;-)
Eure Art der lockeren aber sehr informativen und immer nachvollziehbaren Video-Podcasts ist einfach großartig. Alle Themen und wichtigen Punkte werden behandelt und geben genug Raum für eigene Ideen und schlagen die wichtigsten Brücken über die typischen Fallstricke und Hürden in IDE und Programmiersprache, so dass man genug in der Hand hat, um auch selber ohne zu starke Lernkurve motiviert an eigenen Sachen zu arbeiten.
Macht weiter so!
Viele Grüße aus Berlin.
Hi Ing, hi Peter,
in Ermangelung eines Gästebuchs hier mal ein lobender Off-Topic Kommentar. Ich habe durch Zufall diesen Video-Podcast beim Apple-TV surfen entdeckt und bin absolut begeistert. Es macht große Freude Euch bei der wirklich großartigen Einführung zu XCode zuzusehen. Ich bin seit 10 Jahren Programmierer für große Webanwendungen, habe aber mich aber bisher noch nicht mit XCode und Cocoa-Apps beschäftigt und daher endlich mal reingeschnuppert. Die Nacht endete mit über 10 angeschauten Folgen und dem sofortigen Einstieg in ein eigenes Projekt für meine Projekt-Verwaltung (Tests und MVC-Konzept) ;-)
Eure Art der lockeren aber sehr informativen und immer nachvollziehbaren Video-Podcasts ist einfach großartig. Alle Themen und wichtigen Punkte werden behandelt und geben genug Raum für eigene Ideen und schlagen die wichtigsten Brücken über die typischen Fallstricke und Hürden in IDE und Programmiersprache, so dass man genug in der Hand hat, um auch selber ohne zu starke Lernkurve motiviert an eigenen Sachen zu arbeiten.
Macht weiter so!
Viele Grüße aus Berlin.
7. MCplusplus am 23. Jan 2010, 22:33 Uhr
Ich weiß nicht, ob diese Frage schon mal beantwortet wurde, aber was hat es mit dem 0x02100 auf sich?
Ich weiß nicht, ob diese Frage schon mal beantwortet wurde, aber was hat es mit dem 0x02100 auf sich?
6. Raphael (@ramsch) am 19. Jan 2010, 23:20 Uhr
Lieber Ingo, lieber Peter
nwdserdaer wiederlegt ihr ja selbst ;-)
"Objects in the nib file are initially created with a retain count of 1. As it rebuilds the object hierarchy, however, AppKit autoreleases any objects that have a parent or owning object, such as views nested inside view hierarchies. By the time the nib-loading code is done, only the top-level objects in the nib file have a positive retain count and no owning object. Your code is responsible for releasing these top-level objects."
Es ist ziemlich kompliziert da unter Mac und iPhone sehr anders. Habe das alles nun ausführlich getestet und bin zu folgendem kleinen "Guideline" gekommen:
Objekte aus NIBs/Outlets:
Auf Mac und iPhone wird versucht, die Outlet-Verbindung mit einem implementierten Setter zu setzten (ansonsten wird es direkt gesetzt).
Top-level objects: "have [...] no owning object"
Non-top-level objects: "any objects that have a parent or owning object, such as views nested inside view hierarchies."
1) Outlet für top-level objects machen. Für non-top-level objects wenn nötig (Zugriff).
2) Für Outlets property machen:
Top-level objects auf Mac: @property (nonatomic, assign) IBOutlet SomeObject *someObject; @synthesize someObject; [self.someObject release];
Non-top-level objects auf Mac: @property (nonatomic, assign) IBOutlet NSWindow *window; @synthesize someObject;
Top-level objects auf iPhone (must retain): @property (nonatomic, retain) IBOutlet SomeObject *someObject; @synthesize someObject; [self.someObject release];
Non-top-level objects auf iPhone (should retain): @property (nonatomic, retain) IBOutlet UIWindow *window; @synthesize window; [self.window release];
Quelle: http://developer.apple.com/mac/library/documentation/Cocoa/Conceptual/LoadingResources/CocoaNibs/CocoaNibs.html
(Ich greife auch lokal immer mit accessors auf i-vars zu um KVO-kompatibel zu bleiben -- keine Ahnung ob es bei Cheddar zu Problemen kommt, wird jedenfalls so empfohlen ...)
PS: Heeh :D Das @ verwirrt langsam. Twitter halt ... ;)
Lieber Ingo, lieber Peter
nwdserdaer wiederlegt ihr ja selbst ;-)
"Objects in the nib file are initially created with a retain count of 1. As it rebuilds the object hierarchy, however, AppKit autoreleases any objects that have a parent or owning object, such as views nested inside view hierarchies. By the time the nib-loading code is done, only the top-level objects in the nib file have a positive retain count and no owning object. Your code is responsible for releasing these top-level objects."
Es ist ziemlich kompliziert da unter Mac und iPhone sehr anders. Habe das alles nun ausführlich getestet und bin zu folgendem kleinen "Guideline" gekommen:
Objekte aus NIBs/Outlets:
Auf Mac und iPhone wird versucht, die Outlet-Verbindung mit einem implementierten Setter zu setzten (ansonsten wird es direkt gesetzt).
Top-level objects: "have [...] no owning object"
Non-top-level objects: "any objects that have a parent or owning object, such as views nested inside view hierarchies."
1) Outlet für top-level objects machen. Für non-top-level objects wenn nötig (Zugriff).
2) Für Outlets property machen:
Top-level objects auf Mac: @property (nonatomic, assign) IBOutlet SomeObject *someObject; @synthesize someObject; [self.someObject release];
Non-top-level objects auf Mac: @property (nonatomic, assign) IBOutlet NSWindow *window; @synthesize someObject;
Top-level objects auf iPhone (must retain): @property (nonatomic, retain) IBOutlet SomeObject *someObject; @synthesize someObject; [self.someObject release];
Non-top-level objects auf iPhone (should retain): @property (nonatomic, retain) IBOutlet UIWindow *window; @synthesize window; [self.window release];
Quelle: http://developer.apple.com/mac/library/documentation/Cocoa/Conceptual/LoadingResources/CocoaNibs/CocoaNibs.html
(Ich greife auch lokal immer mit accessors auf i-vars zu um KVO-kompatibel zu bleiben -- keine Ahnung ob es bei Cheddar zu Problemen kommt, wird jedenfalls so empfohlen ...)
PS: Heeh :D Das @ verwirrt langsam. Twitter halt ... ;)
5. peter am 18. Jan 2010, 23:48 Uhr
@ @ramsch:
Nicht verwirren lassen. Denn merke: nwdserdaer*
Ingo findet diesen Artikel sehr spannend (ich auch, vor allem wegen der Kapitelüberschriften):
http://developer.apple.com/documentation/Cocoa/Conceptual/LoadingResources/CocoaNibs/CocoaNibs.html#//apple_ref/doc/uid/10000051i-CH4-SW6
"The Nib Object Life Cycle" ist der spannende Part. Da findet sich unter Drittens, wie Outlets gebastelt werden. Es nutzt also erstmal Properties, wenn vorhanden.
Auch ein wichtiger Satz:
"If the instance variable cannot be found, no connection is created."
Sieht unscheinbar aus, hats aber in sich: es passiert kein Fehler. Und man fragt sich doof, warum das Programm nicht läuft.
Ingo & Peter
* Alte OO-Weisheit "Nur wo Du selbst ein Retain, da auch ein Release"
@ @ramsch:
Nicht verwirren lassen. Denn merke: nwdserdaer*
Ingo findet diesen Artikel sehr spannend (ich auch, vor allem wegen der Kapitelüberschriften):
http://developer.apple.com/documentation/Cocoa/Conceptual/LoadingResources/CocoaNibs/CocoaNibs.html#//apple_ref/doc/uid/10000051i-CH4-SW6
"The Nib Object Life Cycle" ist der spannende Part. Da findet sich unter Drittens, wie Outlets gebastelt werden. Es nutzt also erstmal Properties, wenn vorhanden.
Auch ein wichtiger Satz:
"If the instance variable cannot be found, no connection is created."
Sieht unscheinbar aus, hats aber in sich: es passiert kein Fehler. Und man fragt sich doof, warum das Programm nicht läuft.
Ingo & Peter
* Alte OO-Weisheit "Nur wo Du selbst ein Retain, da auch ein Release"
4. @ramsch am 18. Jan 2010, 23:11 Uhr
Nachtrag: IBOutlets werden auto-retained, wenn das NIB von der Disc unarchiviert wird. Wird eine Property für ein solches synthesiert, die assign benützt, müssen wir die Outlets händisch retainen? Mein Hirn rennt da gerade an eine Wand.
Nachtrag: IBOutlets werden auto-retained, wenn das NIB von der Disc unarchiviert wird. Wird eine Property für ein solches synthesiert, die assign benützt, müssen wir die Outlets händisch retainen? Mein Hirn rennt da gerade an eine Wand.
3. @ramsch am 18. Jan 2010, 21:13 Uhr
Ihr habt oft betont, weil es ein IBOutlet sei, greife man nicht als Property darauf zu. Spricht etwas dagegen, IBOutlets generell mit einer Property mit nonatomic (greifen ja nie mehrere Threads auf das NIB zu beim unarchivieren) und assign zu versehen? Wie ihr einmal richtigerweise erwähnt habt (und im AppDelegate programmiert), muss die Runtime die i-vars ja sowieso irgendwie "reinwursteln". Als OO-Purist könnte man dann auch auf IBOutlets mit self.foo zugreifen. Was meint ihr?
Anderes Trivia: in dealloc-Implementationen evtl. anstatt self.foo = NULL; eine release message an self.foo schicken (guter Stil?).
Und noch was kommt mir gerade in den Sinn: Hillegass empfiehlt, wird ein designated initializer implementiert (in unserem Fall initWithPath:) sollte der designated initializer (in unserem Fall init) der Super-Klasse (in unserem Fall NSObject) überschrieben werden. Das machen wir im Moment noch nicht. Entweder von dort aus dann unserem designated initializer aufrufen oder eine Exception werfen, dass es zwingend mit unserem initializer kreiert werden muss.
Sind alles Kleinigkeiten, eure Meinung dazu würde mich aber sehr interessieren, ich frage mich das sonst ständig.
Liebe Grüsse, @ramsch
PS: gibt es in Zukunft eine Möglichkeit, eine weitere Branch zu machen? Wäre super, im Hintergrund etwas mitzuhelfen.
Ihr habt oft betont, weil es ein IBOutlet sei, greife man nicht als Property darauf zu. Spricht etwas dagegen, IBOutlets generell mit einer Property mit nonatomic (greifen ja nie mehrere Threads auf das NIB zu beim unarchivieren) und assign zu versehen? Wie ihr einmal richtigerweise erwähnt habt (und im AppDelegate programmiert), muss die Runtime die i-vars ja sowieso irgendwie "reinwursteln". Als OO-Purist könnte man dann auch auf IBOutlets mit self.foo zugreifen. Was meint ihr?
Anderes Trivia: in dealloc-Implementationen evtl. anstatt self.foo = NULL; eine release message an self.foo schicken (guter Stil?).
Und noch was kommt mir gerade in den Sinn: Hillegass empfiehlt, wird ein designated initializer implementiert (in unserem Fall initWithPath:) sollte der designated initializer (in unserem Fall init) der Super-Klasse (in unserem Fall NSObject) überschrieben werden. Das machen wir im Moment noch nicht. Entweder von dort aus dann unserem designated initializer aufrufen oder eine Exception werfen, dass es zwingend mit unserem initializer kreiert werden muss.
Sind alles Kleinigkeiten, eure Meinung dazu würde mich aber sehr interessieren, ich frage mich das sonst ständig.
Liebe Grüsse, @ramsch
PS: gibt es in Zukunft eine Möglichkeit, eine weitere Branch zu machen? Wäre super, im Hintergrund etwas mitzuhelfen.
2. ingo am 18. Jan 2010, 11:01 Uhr
@Fabrice:
Ich weiss, wir haben es nicht erklärt, aber wir haben mittelfristig vor durch ein paar kleinere Änderungen die beiden Klassen "PathItem" und "SyncItem" so umzuschreiben, dass Sie von NSUserDefaults ohne den Umweg über NSCoding gefressen werden. NSUserDefaults kennt die Klasse NSURL nicht, daher hinterlegen wir sie jetzt schonmal als Strings.
@Fabrice:
Ich weiss, wir haben es nicht erklärt, aber wir haben mittelfristig vor durch ein paar kleinere Änderungen die beiden Klassen "PathItem" und "SyncItem" so umzuschreiben, dass Sie von NSUserDefaults ohne den Umweg über NSCoding gefressen werden. NSUserDefaults kennt die Klasse NSURL nicht, daher hinterlegen wir sie jetzt schonmal als Strings.
1. Fabrice am 17. Jan 2010, 16:20 Uhr
Erst einmal wieder ein Lob, super Folge! Danke dafür. Eine Frage habe ich aber, warum Speichert ihr den Pfad nicht einfach als NSURL im PathItem?
Erst einmal wieder ein Lob, super Folge! Danke dafür. Eine Frage habe ich aber, warum Speichert ihr den Pfad nicht einfach als NSURL im PathItem?
http://www.mac-talk.eu/entwickler/71-videotutorials-zu-objective-c.html