#022 Cheddar: Frühjahrsputz im Winter
(40:11 Minuten)
Diese Folge ist im Prinzip nur der erste Teil einer Aufräumaktion. Geschriebenen Code nochmals anzupacken und frühere Schlampereien auszubügeln gehört quasi zum Programmiereralltag. Daher räumen wir in dieser Folge auch nicht alles auf, sondern sprechen nur ein paar Punkte an.
Wenn ihr diese Revision zukünftig aus dem SVN-Repository auschecken wollt, dann könnt ihr im Terminal folgenden Befehl eingeben:
svn checkout -r 33 https://cheddar1.svn.sourceforge.net/svnroot/cheddar1/trunk Cheddar_r33Links zur Folge:
Kommentar hinzufügen
5. ingo am 17. Mar 2010, 11:45 Uhr
@Andre:
Hui, da hast Du vollkommne recht. Das ist ein Bug, der bisher nicht aufgefallen ist, da er ja keinen Fehler produziert... ;-)
Das mit dem MutableArray ist ansonsten NICHT unnötig. Wir benötigen an der Stelle ein NSMutableArray, zurückgeliefert wird aber nur NSArray - zumindest meines Wissens, ohne es jetzt konkret getestet zu haben. Das Ganze wird im Übrigen über kurz oder lang sowieso nochmals umgeschrieben, so dass es ohne den Umweg über den KeyedArchiver in die UserDefaults geschrieben werden kann, und dann brauchen wir den kleinen Umweg auf alle Fälle. Vor Allem sehen die UserDefaults dann deutlich hübscher aus.
Letztendlich muss aber beizeiten das registerDefaults an einen sinnvolleren Ort verschoben werden, z.B. in das init des AppDelegates. Wir werden in einer der nächsten Folgen mal drauf eingehen.
@Andre:
Hui, da hast Du vollkommne recht. Das ist ein Bug, der bisher nicht aufgefallen ist, da er ja keinen Fehler produziert... ;-)
Das mit dem MutableArray ist ansonsten NICHT unnötig. Wir benötigen an der Stelle ein NSMutableArray, zurückgeliefert wird aber nur NSArray - zumindest meines Wissens, ohne es jetzt konkret getestet zu haben. Das Ganze wird im Übrigen über kurz oder lang sowieso nochmals umgeschrieben, so dass es ohne den Umweg über den KeyedArchiver in die UserDefaults geschrieben werden kann, und dann brauchen wir den kleinen Umweg auf alle Fälle. Vor Allem sehen die UserDefaults dann deutlich hübscher aus.
Letztendlich muss aber beizeiten das registerDefaults an einen sinnvolleren Ort verschoben werden, z.B. in das init des AppDelegates. Wir werden in einer der nächsten Folgen mal drauf eingehen.
4. Andre am 12. Mar 2010, 21:51 Uhr
Hallo,
diese Folge ist leider fehlerhaft:
Wenn man die angesprochenen Methoden applicationDidFinishLaunching und awakeFromNib debuggt, stellt man fest, dass awakeFromNib zuerst ausgeführt wird. Somit ist natürlich das ganze Konzept, erst das NSDictionary zu setzen, hinfällig.
Bei euch funktioniert das ganze nur zufällig, da ihr den eigentlich unnötigen Umweg vom NSArray zum NSMutableArray in der awakeFromNib-Methode geht. Dabei wird nämlich das Array initialisiert (und nicht wie es eigentlich sein sollte, in der ApplicationDidFinishLaunching).
Es wäre schön, wenn ihr das nochmal richtigstellen könntet, mich würde da auf jeden Fall die richtige Lösung interessieren!
Ansonsten seid ihr super, weiter so!
Gruß,
Andre
Hallo,
diese Folge ist leider fehlerhaft:
Wenn man die angesprochenen Methoden applicationDidFinishLaunching und awakeFromNib debuggt, stellt man fest, dass awakeFromNib zuerst ausgeführt wird. Somit ist natürlich das ganze Konzept, erst das NSDictionary zu setzen, hinfällig.
Bei euch funktioniert das ganze nur zufällig, da ihr den eigentlich unnötigen Umweg vom NSArray zum NSMutableArray in der awakeFromNib-Methode geht. Dabei wird nämlich das Array initialisiert (und nicht wie es eigentlich sein sollte, in der ApplicationDidFinishLaunching).
Es wäre schön, wenn ihr das nochmal richtigstellen könntet, mich würde da auf jeden Fall die richtige Lösung interessieren!
Ansonsten seid ihr super, weiter so!
Gruß,
Andre
3. @ramsch am 14. Dec 2009, 10:53 Uhr
Absolut, leuchtet nun total ein. Es musste ja mindestens einen Grund geben, wenn alle Factory Methoden im Framework auch so gemacht wurden, ich bin einfach nicht drauf gekommen. Vielen Dank Ingo!
Absolut, leuchtet nun total ein. Es musste ja mindestens einen Grund geben, wenn alle Factory Methoden im Framework auch so gemacht wurden, ich bin einfach nicht drauf gekommen. Vielen Dank Ingo!
2. ingo am 14. Dec 2009, 10:10 Uhr
@ramsch:
Also, ein Nachteil fällt mir spontan ein:
Nehmen wir mal an, Du hast eine Klasse namens MyClass. Die Klasse hat eine Methode
+(MyClass*)myClassWithTitle:(NSString*)title;
leitest Du nun von dieser Klasse die Klasse MyMutableClass ab, und es besteht keine Notwendigkeit die oben beschriebene Methode zu überschreiben, weil sie auch so noch mit der neuen Klasse funktioniert, dann kannst Du ohne zusätzliches Type Casting NICHT mehr folgenden Aufruf machen:
MyMutableClass* object = [NSMutableClass myClassWithTitle:@"Titel"];
Im Prinzip ist es also eine gute Konvention an dieser Stelle immer (id) zu nehmen. Man weiss ja nie, ob man mal etwas vererben mag. Gewöhnlich weist man den zurückgegebenen Objektzeiger sowieso direkt einer entsprechend typisierten Variable zu. Zumindest danach funktioniert die Typprüfung dann wie erwartet. Sollte man den Zeiger einer falschen Variable zuweisen, dann gibt es auf jeden Fall Warnungen, wenn man danach die Klasse mit den eigentlich korrekten Methoden nutzen möchte. Der kurze Moment des "Informationsminus" ist also vernachlässigbar. Ich bin da auch noch nie vor die Wand gerannt.
Ich hoffe ich konnte das hier in der Kürze verständlich erklären ;-)
@ramsch:
Also, ein Nachteil fällt mir spontan ein:
Nehmen wir mal an, Du hast eine Klasse namens MyClass. Die Klasse hat eine Methode
+(MyClass*)myClassWithTitle:(NSString*)title;
leitest Du nun von dieser Klasse die Klasse MyMutableClass ab, und es besteht keine Notwendigkeit die oben beschriebene Methode zu überschreiben, weil sie auch so noch mit der neuen Klasse funktioniert, dann kannst Du ohne zusätzliches Type Casting NICHT mehr folgenden Aufruf machen:
MyMutableClass* object = [NSMutableClass myClassWithTitle:@"Titel"];
Im Prinzip ist es also eine gute Konvention an dieser Stelle immer (id) zu nehmen. Man weiss ja nie, ob man mal etwas vererben mag. Gewöhnlich weist man den zurückgegebenen Objektzeiger sowieso direkt einer entsprechend typisierten Variable zu. Zumindest danach funktioniert die Typprüfung dann wie erwartet. Sollte man den Zeiger einer falschen Variable zuweisen, dann gibt es auf jeden Fall Warnungen, wenn man danach die Klasse mit den eigentlich korrekten Methoden nutzen möchte. Der kurze Moment des "Informationsminus" ist also vernachlässigbar. Ich bin da auch noch nie vor die Wand gerannt.
Ich hoffe ich konnte das hier in der Kürze verständlich erklären ;-)
1. @ramsch am 14. Dec 2009, 01:40 Uhr
Hallo Ingo und Peter!
Im SyncItem.h deklarieren wir die Klassenmethoden + (id)syncItem; und + (id)syncItemWithTitle:(NSString *)name; warum geben wir id zurück, wenn wir eigentlich genau wissen, dass unser Rückgabewert vom Typ SyncItem sein wird?
UIButton macht das überigens bei seiner factory method genau so: + (id)buttonWithType:(UIButtonType)buttonType und ich sehe den Vorteil nicht sondern eher ein Minus an Information (Typenprüfung).
Kann einer von euch dazu was sagen? Würde mich sehr interessieren.
Gruss!
Hallo Ingo und Peter!
Im SyncItem.h deklarieren wir die Klassenmethoden + (id)syncItem; und + (id)syncItemWithTitle:(NSString *)name; warum geben wir id zurück, wenn wir eigentlich genau wissen, dass unser Rückgabewert vom Typ SyncItem sein wird?
UIButton macht das überigens bei seiner factory method genau so: + (id)buttonWithType:(UIButtonType)buttonType und ich sehe den Vorteil nicht sondern eher ein Minus an Information (Typenprüfung).
Kann einer von euch dazu was sagen? Würde mich sehr interessieren.
Gruss!
http://www.mac-talk.eu/entwickler/71-videotutorials-zu-objective-c.html