[Presence 2] Ai-je bien passé ma variable d'instance à mon autre classe ?
Salut !
Je continue mon apprentissage sur l'iPhone et la programmation toujours tout en suivant les cours de Stanford. J'en suis au 8ème cours sur les tableview et suit actuellement le TP sur Twitter (Presence Part 2).
En gros l'application doit aller récolter l'image , le prénom et les statuts d'un membre dont on connaà®t son username stocké dans un .plist. Une première vue est une tableview affichant les photos et les username. Lorsque l'on clique sur un username une seconde vue apparaà®t affichant ses derniers statuts.
L'une des consignes de l' "Assignment-Presence 2 .pdf " est :
La partie en gras est mon problème. Mon application fait bien ce qui est demandé mais je ne sais pas si je l'ai fait de manière propre. C'est pourquoi je vous demande de jeter un petit coup d'oeil au quelques lignes de codes de mon projet. Plus précisément je ne sais si je gère bien l'utilisation de la classe "Person" et si je passe correctement mes variables d'instances d'une classe à l'autre.
Ici encore un bref aperçu du code :
PersonListViewController.m
et encore dans PersonDetailsviewController.h :
dans PersonDetailsviewController.m :
le mieux est de voir directement dans le .xcodeproj je crois.
Merci
Je continue mon apprentissage sur l'iPhone et la programmation toujours tout en suivant les cours de Stanford. J'en suis au 8ème cours sur les tableview et suit actuellement le TP sur Twitter (Presence Part 2).
En gros l'application doit aller récolter l'image , le prénom et les statuts d'un membre dont on connaà®t son username stocké dans un .plist. Une première vue est une tableview affichant les photos et les username. Lorsque l'on clique sur un username une seconde vue apparaà®t affichant ses derniers statuts.
L'une des consignes de l' "Assignment-Presence 2 .pdf " est :
In Presence 1, we pushed a PersonDetailViewController onto the navigation stack in our button's
action method. Now, we're going to do it in response to a table selection. You remember how to
do that, right? Your PersonDetailViewController class should now have a “person†property. Be
sure to set it on the instance after creation, before you push it onto the stack.
La partie en gras est mon problème. Mon application fait bien ce qui est demandé mais je ne sais pas si je l'ai fait de manière propre. C'est pourquoi je vous demande de jeter un petit coup d'oeil au quelques lignes de codes de mon projet. Plus précisément je ne sais si je gère bien l'utilisation de la classe "Person" et si je passe correctement mes variables d'instances d'une classe à l'autre.
Ici encore un bref aperçu du code :
PersonListViewController.m
<br />// Person instance<br /> person = [[Person alloc]initWithName:nil userName:[users objectAtIndex:indexPath.row] withImage:nil];<br /> <br /> // Load details view<br /> PersonDetailsViewController *personDetailsViewController = [[PersonDetailsViewController alloc]initWithStyle:UITableViewStyleGrouped andPerson:person];<br />[...]<br />// Release<br />[person release];<br />
et encore dans PersonDetailsviewController.h :
<br />@class Person;<br /><br />@interface PersonDetailsViewController : UITableViewController {<br /> NSString *username;<br />}<br />- (id)initWithStyle:(UITableViewStyle)style andPerson:(Person *)iperson;<br />@end<br />
dans PersonDetailsviewController.m :
<br />- (id)initWithStyle:(UITableViewStyle)style andPerson:(Person *)person {<br /> <br /> self = [super initWithStyle:style];<br /> if (self) {<br /> NSLog(@"Cool !");<br /> NSLog(@"%@",[person userName]);<br /> username = [[NSString alloc]initWithFormat:[person userName]];<br /> }<br /> return self;<br />}<br />
le mieux est de voir directement dans le .xcodeproj je crois.
Merci
Connectez-vous ou Inscrivez-vous pour répondre.
Réponses
(A part qu'il manque 2 releases dans le projet zippé )
Pour moi ça sous-entend dans le .h :
et dans le .m
J'ai eu le même problème que toi de core dans le cas d'ajout d'un utilisateur dans le plist, et il y a deux raisons :
Pense à tester le retour (et donc que infoUser ne soit pas nil) avant de continuer sur le user
Dans TwitterHelper.h :
Il faut le passer à 0 pour faire des requêtes sur la production de Twitter, sinon il fonctionne sur le serveur de Stanford, et tu ne trouveras jamais tes amis !
Au début je ne comprenais pas l'intérêt de ces méthodes, qui crée un dictionary à partir d'un dictionary existant... autant faire un simple égal "=" (ou plutôt à la limite un copy+autorelease) sur le dictionary, non ?
Eh eh et ben non, parce que si l'argument est nil, ça crée un NSDictionary (resp. NSArray) vide !
[NSDictionary dictionaryWithDictionary:nil] --> retourne un NSDictionary non-nil, mais vide (count=0)
[NSDictionary dictionaryWithDictionary:d] --> retourne une copie de d, avec les mêmes éléments (ou un NSDico vide si d est nil)
@Smy : Mouarf, je savais que c'était tout con, c'était en plus écrit dans les commentaires du code source...
Moi aussi je tourne en ralentit cette semaine, j'en suis à cette partie du tuto "presence " :
... et c'est pas simple. :crackboom:-
J'ai des légers memory leak à trouver, mais sinon c'est terminé.
@AliGator
Du coup, tu ne testes jamais les retours, mais tu te bases sur le comportement d'un dictionary vide ?
@CrazyJo
Quand tu ajoutes un projet à un post, pense à nettoyer les objets avant de le zipper (Build/Clean all target), ou même supprime le contenu du dossier Build.
Dodo
[Edit]: Ne pas prendre cette version mais celle plus bas...
Bon, en fait, non, ce n'est pas terminé, j'ai un joli bug de scroll vertical sur la seconde view. Mmmmhhhhh !
CrazyJo, tu as terminé ?
Mais souvent je veux partir par exemple d'un NSDictionary existant (ou pas) pour lui rajouter des clés, par exemple. Dans ce cas je crée un NSMutableDictionary à partir de ma variable de type NSDictionary... sauf que si je fais ça avec un code genre ... ben si ma variable monDico est à nil, monDicoModifiable vaudra nil aussi (l'envoi d'un message à nil n'a pas d'effet et retourne nil/NULL/0)... du coup le setValue:forKey: n'aura pas d'effet non plus, et on se retrouvera encore avec un dico vide à l'arrivée... alors que de prime abord on s'attend plutôt à finir avec un dico avec juste la clé @tata et sa valeur "@toto si on est parti de rien....
Donc dans ce genre de cas plutôt que de tester si monDico est nil ou pas avant de créer la mutableCopy, je trouve qu'il est tout aussi voir plus simple de créer un NSMutableDictionary en demandant "en récupérant les données de l'ancien" comme ça s'il n'est pas nil, on repart de la même base... mais s'il est nil car n'a encore jamais été affecté/alloué, bah on part d'un NSMutableDico vide, mais existant (non-nil) : Et là non seulement on a pas à ne pas oublier le "release", puisqu'on crée clairement un objet autoreleased avec dictionaryWithDictionary, mais surtout si monDico est nil, pour monDIcoModifiable ça fera comme si monDico existait mais était vide... ce qui en l'occurrence est le comportement qui nous intéresse, puisqu'on veut y rajouter des valeurs, donc faut que monDicoModifiable ne soit pas nil mais bien un dico alloué (vide éventuellement, mais existant).
Après bien sûr ça ne s'applique pas à tous les cas, y'a des fois où on a quand même besoin, voire ça nous arrange, de tester si la valeur est à nil. Mais ici c'est plutôt plus simple d'utiliser dictionaryWithDictionary.
Donc voilà au moins ça explique aussi l'intérêt de ces méthodes (plutôt que d'envoyer un simple retain, copy ou mutableCopy au dico, ce qui retournera nil si le dico de depart est nil).