Comment est-ce que [auto.tableView reloadData] savoir quelles données pour la recharger?

D'accord, je comprends votre frustration parce que la grande majorité de l'iPhone sur le matériel didactique ne paient pas suffisamment d'attention à l'ensemble de la conception d'application. Ils font un beeline pour les bonbons pour les yeux de l'interface et de payer du bout des lèvres seulement de façon que l'application doit traiter les données même si la manipulation des données est tout l'objet de l'application en premier lieu!

Le matériel didactique ne passent pas assez de temps pour expliquer le Modèle-Vue-Contrôleur modèle de conception sur laquelle l'ensemble de l'iPhone/API Cocoa est basé. Vous rencontrez un moment difficile de comprendre quoi que ce soit parce que vous continuez à essayer de caser des fonctionnalités dans le mauvais objets vertu de la croyance erronée que la vue de l'INTERFACE utilisateur est au cœur du programme, tels que le matériel didactique qui t'ont amené à croire. En vertu de ce malentendu, rien n'a de sens, pas même la Documentation d'Apple.

Vous avez besoin de prendre du recul et à repenser. Ce n'est pas la fonction d'un point de vue de décider quelles sont les données à afficher et quand pour l'afficher. Ce n'est pas la fonction de l'affichage de la table de contrôleur de détenir, de gérer ou de stocker de l'application des données. Ces fonctions relèvent du modèle de données objet (que vous avez probablement jamais entendu parler.) Vous avez de la difficulté parce que vous êtes en train de séparer le modèle de données de la tâche à travers le point de vue et le point de vue du contrôleur ont été elles n'appartiennent pas.

Apparemment, votre application n'a même pas un modèle de données parce que vous êtes la tenue de la table de données en tant que propriétés de la tableview contrôleur. Bien que vous voyez souvent cette simpliste tutoriel, exemples, c'est un mauvais design, qui va s'effondrer en vertu de la complexité de tout mais le plus trivial des applications.

Au lieu de cela, vos données doivent être stockées et gérées dans son propre objet personnalisé. C'est le modèle de données. Dans votre cas, il semble que vous avez données réparties sur deux tableaux afin de créer un modèle de données objet quelque chose comme ceci:

@interface MyDataModel : NSObject {
@protected
    NSArray *arrayOne;
    NSArray *arrayTwo;
@public
    NSArray *currentlyUsedArray;

}
@property(nonatomic, retain)  NSArray *currentlyUsedArray;

-(void) switchToArrayOne;
-(void) switchToArrayTwo;
-(void) toggleUsedArray;

@end

#import "MyDataModel.h"

@interface MyDataModel ()
@property(nonatomic, retain)  NSArray *arrayOne;
@property(nonatomic, retain)  NSArray *arrayTwo;

@end


@implementation MyDataModel

- (id) init{
    if (self=[super init]) {
        self.arrayOne=//... initialize array from some source
        self.arrayTwo=//... initialize array from some source
        self.currentlyUsedArray=self.arrayOne; //whatever default you want
    }
    return self;
}

-(void) switchToArrayOne{
    self.currentlyUsedArray=self.arrayOne;
}

-(void) switchToArrayTwo{
    self.currentlyUsedArray=self.arrayTwo;
}

- (void) toggleUsedArray{
    if (self.currentlyUsedArray==self.arrayOne) {
        self.currentlyUsedArray=self.arrayTwo;
    }else {
        self.currentlyUsedArray=self.arrayOne;
    }
}

(Notez que les données réelles sont encapsulées et que d'autres objets ne peuvent accéder à la currentlyUsedArray. Le modèle de données qui décide de données à fournir en fonction de l'état interne des données.)

Ce modèle de données objet doit être dans un universellement accessible. La meilleure méthode est d'en faire un singleton, mais la rapide et sale de la méthode est de se garer comme un attribut de l'délégué d'application.

Afin de vous tableview contrôleur de vous aurait une propriété:

MyDataModel *theDataModel;
@property (nonatomic, retain) MyDataModel *theDataModel;

puis dans la mise en œuvre

@synthesize theDataModel;

-(MyDataModel *) theDataModel; {
    if (theDataModel; !=nil) {
        return theDataModel; ;
    }
    id appDelegate=[[UIApplication sharedApplication] delegate];
    self.theDataModel=appDelegate.theDataModelProperty;
    return theDataModel;
}

Puis dans votre tableview de la source des données méthode:

- (UITableViewCell *)tableView:(UITableView *)tableView cellForRowAtIndexPath:(NSIndexPath *)indexPath{
    ...
    cell.textLabel.text=[self.theDataModel.currentlyUsedArray objectAtIndex:indexPath.row];
    return cell;
}

Si certains événements n'importe où dans l'application nécessite de passer des tableaux, vous appelez modèle de données de l'objet à partir de l'app délégué et l'envoyer à la appropriée de l'interrupteur de tableau de message.

id appDelegate=[[UIApplication sharedApplication] delegate];
[appDelegate.theDataModelProperty toggleUsedArray];

Maintenant toutes les données, que ce soit dans ce tableau ou certains autres complètement sans rapport avec vue, utilisez le formulaire de données le bon tableau.

Pourquoi passer par tout ce mal? Cela rend l'application modulaire. Vous pouvez facilement ajouter sur les différents points de vue de chacun d'afficher les données d'une manière différente sans avoir à réécrire la gestion de vos données à chaque fois. Vous pouvez utiliser le modèle de données pour gérer les données qui seront affichées dans un tableau, dans une webview ou sur la ligne de commande. Vous pouvez même déplacer facilement le modèle de données à une tout autre application.

Cette modularité rend la gestion complexe des grandes applications de manière beaucoup plus facile. Vous n'avez qu'un objet qui manipule et contrôle les données. Vous n'avez pas à vous inquiéter que les quelques erreurs mineures dans certains rarement utilisé segment de code sera corbeille de la totalité de l'app. Vous pouvez les vues du plugin facilement ou de les supprimer facilement sans casser l'application.

C'est bien sûr un exemple trivial, mais il montre de bonnes pratiques.

Toutefois, vous pouvez demander, comment résoudre le problème de la tableview savoir quelles sont les données à charger et quand le charger? Simple, il ne le fait pas. Il n'est pas le travail de la tableview de savoir quelles sont les données à charger ou quand la charge. Le modèle de données gère des données et tableview contrôleur gère la quand. (Vous pouvez même avoir le modèle de données d'émettre des avis lorsqu'elle est mise à jour par exemple, pour une url. le point de vue du contrôleur pouvez vous inscrire pour la notification et l'appel reloadData chaque fois que le modèle de données de changement).

Par impitoyablement de cloisonnement et l'encapsulation des fonctionnalités en MVC, à vous de créer des applications à partir de simple, de composants réutilisables qui sont faciles à entretenir et à déboguer.

C'est vraiment mauvais la plupart du matériel didactique seulement du bout des lèvres à présent totalement concept critique.

OriginalL'auteur TechZen