Plist et dictionnaire
muqaddar
Administrateur
Salut,
Je voulais initialiser un dico à partir d'une plist comme ça :
{
tags = (
toto,
titi,
lulu & lolo
)
}
Bon, l'espace entre lulu et lolo fait foirer la demande, si je les vire, pas de pb, avec le bundle et le path je peux charger mon dictionnaire.
Pourquoi on ne peut pas mettre d'espace ? Comment faire pour remplir un dictionnaire (pour charger un tableau) à partir d'un fichier dans ce cas là ?
Merci !
Je voulais initialiser un dico à partir d'une plist comme ça :
{
tags = (
toto,
titi,
lulu & lolo
)
}
Bon, l'espace entre lulu et lolo fait foirer la demande, si je les vire, pas de pb, avec le bundle et le path je peux charger mon dictionnaire.
Pourquoi on ne peut pas mettre d'espace ? Comment faire pour remplir un dictionnaire (pour charger un tableau) à partir d'un fichier dans ce cas là ?
Merci !
Connectez-vous ou Inscrivez-vous pour répondre.
Réponses
Tant que j'y suis, j'ai un crash mémoire :
Apparemment, ça vient de la dernière ligne.
tabRegions est une varoable d'instance. Je m'en sers dans d'autres méthodes.
3 choses :
- dans les 2 premières lignes du code, il faut tester les valeurs de retour (regionsValues et regionsValues). Si pour une raison ou une autre, l'appel aux méthodes échoue, ça renvoie nil. Comme tu ne testes pas ces cas, tu risques de te trimbaler des nils un peu partout jusqu'à ce que ça te fasse planter à un moment donné ton appli.
- Avant dernière ligne : tu créés un tableau (NSMutableArray) et tu places sa référence dans la variable tabRegions. Mais 1 ligne plus bas, tu écrases cette référence par une autre référence de tableau provenant de objectForKey:. Résultat, peu à peu, tu remplis la mémoire de ton appli par des NSMutableArray jamais détruits (on appele ça un mémory leak).
- dernière ligne : le tableau retourné par objectForKey: est en autorelease, c'est à dire que son allocation est temporaire, et qu'il sera détruit à la prochaine boucle d'événement. Si tu veux le garder "longtemps", tu dois faire un retain dessus.
.
J'ai compris et réparé les 2 derniers points. ça marche.
En revanche, je ne comprends pas ce que je dois faire / ajouter pour le premier point. Qu'appelles-tu tester les valeurs de retour de regsionsValues et regionsPath ?
Un truc du style :
[tt]
{
  NSString *regionsPath;
  NSDictionary *regionsValues;
  regionsPath = [[NSBundle mainBundle] pathForResource:@Regions ofType:@plist];
  if ( !regionsPath ) NSLog(@erreur sur l'accès à la ressource de Regions.plist\n);
  else
  {
    regionsValues = [NSDictionary dictionaryWithContentsOfFile: regionsPath];
    if ( !regionsValues ) NSLog(@erreur sur lecture du contenu de Regions.plist\n);
    else tabRegions = [[regionsValues objectForKey: @regions] retain];
  }
}
[/tt]
.
Néanmoins, faudrait vraiment que le gars soit allé virer le fichier à l'intérieur du paquet de l'application...
Mais enfin, oui, il vaut mieux éviter.
D'ailleurs, vous avez un moteur d'affichage des erreurs dans vos applications je suppose ?
Genre, on envoie un paramètre à une fonction qui crée l'alerte avec le paramètre...
Dans mon boulot, j'ai vu des utilisateurs (de mes applis) faire pire...
Donc, il faut tout prévoir.
.
Néanmoins, je voulais faire un test comme ça :
et
Sauf que si je vire le fichier plist du bundle, il refuse tout bonnement de me lancer l'appli et donc je ne peux tester l'alerte !
As tu quelque chose dans la log ?
.
"No such file or directory"
Je crois que c'est l'inverse...
Dans Xcode, il y a toujours la référence au fichier regions.plist (dans le groupe Resources), mais t'as dû le viré depuis le Finder...
.
Si quelqu'un a une idée concernant le fait que ma sheet devienne une alerte classique au démarrage de l'appli ... ? Est-ce parce qu'elle est chargée ds le init avant le nib ?
Je pense que oui !
Je suppose que t'as mis tout ça dans un awakeFromNib...
Dans ce cas, la fenêtre à laquelle tu tentes d'attacher ton alerte n'est pas encore à l'écran (même si elle est déjà en mémoire), donc l'alerte devient classique.
.
Est-ce une histoire d'encodage ?
Le message d'erreur :
CFPropertyListCreateFromXMLData(): plist parse failed; the data is not proper UTF-8. The file name for this data could be:
/Users/oxitan/Cocoa/Prod/MyApp/build/MyApp.app/Contents/Resources/Regions.plist
The parser will retry as in 10.2, but the problem should be corrected in the plist.