[PLIST] Pourquoi notifier les changements?

colas_colas_ Membre
juin 2015 modifié dans Objective-C, Swift, C, C++ #1

Je suis tombé sur ce bout de code ici:


 


(il s'agit d'ajouter une entrée dans un plist)



NSString* plistPath = nil;
NSFileManager* manager = [NSFileManager defaultManager];
if ((plistPath = [[[NSBundle mainBundle] bundlePath] stringByAppendingPathComponent:@mySpecial/PathTo.plist]))
{
if ([manager isWritableFileAtPath:plistPath])
{
NSMutableDictionary* infoDict = [NSMutableDictionary dictionaryWithContentsOfFile:plistPath];
[infoDict setObject:@foo object forKey:@fookey];
[infoDict writeToFile:plistPath atomically:NO];
[manager setAttributes:[NSDictionary dictionaryWithObject:[NSDate date] forKey:NSFileModificationDate] ofItemAtPath:[[NSBundle mainBundle] bundlePath] error:nil];
}
}

Je l'ai adapté pour ios, en utilisant 



[NSSearchPathForDirectoriesInDomains(NSDocumentDirectory, NSUserDomainMask, YES) lastObject]

Ma question concerne la ligne



[manager setAttributes:[NSDictionary dictionaryWithObject:[NSDate date] forKey:NSFileModificationDate] ofItemAtPath:[[NSBundle mainBundle] bundlePath] error:nil];

• Est-elle nécessaire ?


• Si oui, à  quoi sert-elle ? Sinon, dans quel cas la mettre et pourquoi ?


 


Merci à  ceux qui sont au courant !


Réponses

  • CéroceCéroce Membre, Modérateur
    Sur la page de StackOverflow, les gens posent exactement la même question à  l'auteur original... sans obtenir de réponse. Je ne comprends pas non plus l'intérêt de la manoe“uvre, mais en donnant le bénéfice du doute à  l'auteur, je pense que ça sert à  déclencher une action du Finder, ou quelque chose comme ça.

    De toute façon, sous iOS, on ne peut pas modifier le bundle de l'application, alors si c'est simplement pour modifier une plist dans le répertoire /documents, alors cette ligne ne sert à  rien.
  • AliGatorAliGator Membre, Modérateur
    Le cas d'un fichier a l'intérieur d'un bundle est particulier, car quand tu modifies un fichier à  l'intérieur d'un bundle, la date de modification du fichier est mise à  jour en conséquence, mais celle du bundle n'est pas changée.


    Or certains trouvent ça dommage ou gênant pour certains cas d'usage, par exemple si tu utilises un Makefile qui ne va copier que les fichiers modifiés (= ceux dont la date de modification est plus récente que celle de la dernière copie) à  la compilation, du coup il va considérer que le bundle n'a pas changé et ne va pas le copier à  nouveau.


    Mais ça reste un cas d'usage particulier, plutôt à  considérer par exemple quand tu écris un script shell qui va générer le bundle avant la compilation. ça n'a pas trop de sens quand tu modifies un bundle par du code ObjC en général.

    Et de toute façon ça a encore moins de sens quand cette modification se fait avec du code pour une app iOS, où :

    (1) si le bundle en question c'est le mainBundle de ton application, de toute façon tu ne peux pas le modifier ni lui ni son contenu, donc la question ne se pose même pas

    (2) si c'est un bundle modifiable genre un fichier ".bundle" que tu aurais fais glisser dans ton dossier "Documents" de ta sandbox " ce qui déjà  semble assez abscons " l'intérêt me semble beaucoup moins clair de s'assurer que la date de modification du bundle soit mise à  jour dans un tel contexte.
  • @ceroce et @ali merci pour vos retours !
Connectez-vous ou Inscrivez-vous pour répondre.