Accès aux méthodes et aux variables d'autres classes/objets (où sont les objets btw)?

Question

Ok, je suis nouveau dans la programmation d'Objective-C/iPhone, donc il y a quelques questions qui surgissent quand j'essaie de faire des choses qui seraient assez faciles en C++.

Je construis une application iPhone basée sur une barre d'onglets avec trois vues, une pour chaque bouton de la barre d'onglets. Dans la première vue, l'utilisateur crée un NSdictionary, que la deuxième vue doit afficher sous forme de graphique. Pour accéder à ce dictionnaire, je le sauvegarde dans un fichier .plist dans le premier contrôleur de vue, puis j'élabore un nouveau dictionnaire à partir de ce fichier .plist dans le second.

Pour faire la représentation graphique, j'utilise s7graphview, qui est initialisé dans SecondViewController, mais a ses propres fichiers .h et .m, que j'importe. La méthode de chargement des valeurs dans le graphe (qui provient du dictionnaire créé) est implémentée dans le fichier GraphInfoList.m, ce qui signifie que je dois créer un autre dictionnaire à partir du fichier .plist pour accéder aux données. Comment puis-je accéder au dictionnaire déjà créé? Pendant ce temps, j'ai également fait une méthode "dataFilePath", qui retourne le chemin du fichier .plist, que j'utilise pour charger les données dans un dictionnaire. Je n'ai trouvé aucun autre moyen d'implémenter cette méthode que de le copier/coller dans tous les fichiers .m qui l'utilisent! Il doit y avoir un autre moyen?

Un moment où je suis là: où sont les objets dans la programmation iPhone? Les fichiers .m sont des classes, n'est-ce pas? Je ne crée jamais un nouvel objet en utilisant le nouvel opérateur, et je pensais pouvoir accéder aux méthodes si j'avais un objet à appeler (comme [FirstViewController dataFilePath]). Je ne sais vraiment pas comment cela est géré dans Obj-C/Cocoa, et je ne sais pas quoi chercher pour trouver les réponses. L'aide serait vraiment appréciée.

Answer 1

J'ai eu le même problème en utilisant s7graphview dans un autre contrôleur de vue. Je l'ai résolu en ajoutant un NSDictionary comme une propriété dans le AppDelegate et lorsque les feux de la méthode viewwilldisappear i ajouté ce code:

[((MyAppDelegate*) [[UIApplication sharedApplication] delegate]) setDictionary:self.dictionary]; 

Je pense que ce n'est pas la seule façon de le faire, mais vous enlèverai le .plist code qui ralentit votre application

Answer 2

Un objet est une instance d'une classe (un fichier .m). Vous allouez/init un nouvel objet comme vous le faites en Java avec le nouvel opérateur. vous pouvez importer le .h d'une classe que vous souhaitez utiliser/avoir accès à et ensuite utiliser quelque chose comme

MyClass *objectInstance = [[MyClass alloc] init]; 

pour créer une instance.

En ce qui concerne la méthode dataFilePath ... vous pouvez simplement l'avoir dans le délégué de votre application (probablement quelque chose comme MyAppNameAppDelegate.m) qui est un singleton (une instance pour l'application entière). Vous pouvez ensuite obtenir le chemin d'accès du fichier en utilisant:

myFilePath = [[[UIApplication sharedApplication] delegate] dataFilePath]; 

Je suggère de regarder dans un livre début objectif-c pour plus d'informations. Je suggérerais Learn Objective-C on the Mac. En outre, je voudrais jeter un coup d'oeil à une introduction de base à la programmation orientée objet, car il semble que c'est ce qui vous trébuche plus que tout. Bonne chance.

Answer 3

Le délégué de votre application est un bon endroit pour partager des choses. vous pouvez garder la fonction de chemin du fichier de données dans votre délégué application et accéder

path = [[[UIApplication sharedApplication] delegate] dataFilePath]; 

Ne pas oublier de #import fichier « YourAppDelegate.h ».Les fichiers .m ressemblent à des fichiers .cpp ou à des fichiers .c.

Fondamentalement, les fichiers d'implémentation.

Answer 4

L'utilisation d'un NSDictionary est un mauvais remplacement des objets de domaine appropriés, vous avez des problèmes lorsque vous jonglez avec vos clés. Et souvent, les objets ne sont pas la meilleure façon de modéliser vos données, par exemple, les numéros NSNumber sont tout simplement encombrants.

Introduisez plutôt une classe de domaine appropriée. Il n'y a aucun problème à laisser les deux contrôleurs de votre barre d'onglets accéder au même objet, vous pouvez facilement utiliser la méthode viewWillAppear: pour mettre à jour les états d'une vue à l'autre.

Il est même possible que vous souhaitiez un singleton. S'il ne peut y avoir qu'une seule instance logique d'un objet, le singleton est le chemin à parcourir. Ne les crains pas. Habituellement, un modèle paresseux comme Apple utilise dans leurs cadres est ce que vous voulez. Avec par exemple cette interface:

@interface MyDomainManager : NSObject { /* ivars here */ } 

+(MyDomainManager*)sharedManager; 

// More proper tie and method here  

@end 

Et puis une mise en œuvre comme ceci:

@implementation MyDomainManager 

+(MyDomainManager*)sharedManager; 
{ 
    static MyDomainManager* manager = nil; 
    if (manager == nil) { 
     manager = [[self alloc] init]; 
    } 
    return manager; 
} 

// More implementation cruft… 

@end 

débutez simple que cela est un bon début, puis construire à partir de là.