Lorsque Dave et j'ai écrit Début de développement iPhone, Le SDK a été très bien en version bêta, et beaucoup de la documentation était incomplète ou totalement absente. Étant donné que, je pense que nous avons fait un très bon travail essayant de coller avec Apple "meilleures pratiques" et à deviner ce qui allait plus tard les techniques évoluer vers les meilleures pratiques. Dans un nombre surprenant d'endroits, nous le faisons de la WayTM Apple, même si nous n'étions pas sûrs à 100% ce que le WayTM Apple serait quand nous étions l'écriture du livre.
Nous avons bien fait, mais nous n'avons pas de chauve-souris 1,000.
Un endroit où nous avons manqué de chargement était dans les cellules de tableau créé dans Interface Builder.
Dans la première édition du livre, nous avons codé en dur de l'indice de la cellule. Cela a été mauvaise, parce que quand 2,1 expédiée, la structure du tableau retourné par NSBundle changé et notre code cassé. Whoops!
Dans la seconde édition, nous l'avons changé pour que le code n'utilise plus un indice codé en dur, mais au lieu itère sur le tableau retourné à la recherche d'un objet de la classe à droite (UITableViewCell). Ce fut une bien meilleure approche et fonctionne très bien.
Quelqu'un chez Apple pensé une meilleure façon. C'est effing brillant. Si brillante, en fait, que lorsque j'ai rencontré la documentation pour cela, il m'a fallu un certain temps pour comprendre exactement ce qu'ils faisaient. Voici le code exemple de la documentation d'Apple:
C'est ce qui me confond au premier abord:
La méthode loadNibNamed: le propriétaire: options retourne un NSArray avec le contenu de la plume, mais ce code ignore complètement ce tableau. Il n'a même pas le capturer. Ensuite, elle va sur et ayants allègrement quelques variables d'instance à une autre variable, par exemple, puis définit la variable première instance à néant.
Documentation d'Apple n'est pas parfait, mais habituellement, il est sacrément bon, si j'étais assez sûr que ce code a été bonne, je n'étais pas obtenir quelque chose. Il y avait une pièce du puzzle manquant.
Alors, j'ai regardé tvCell, qui a été déclaré plus tôt, et j'ai vu que c'était une IBOutlet.
"Plus curieux!" S'écria Alice.
Puis il m'est apparu. Le chargeur se connecte automatiquement bundle points faits pour Fichier de propriétaire quand il charge un fichier nib si la sortie est nulle. Notez que lorsque la plume est chargé, le code précise l'auto que le propriétaire du bundle. Donc, puisque cette classe est le contrôleur de Fichier de propriétaire, Lorsque nous avons la charge de la plume, la prise aurez connecté à un objet dans la plume si la sortie de ce nom sur les Fichier de propriétaire est relié à un objet dans la plume.
Alors, qu'est-ce qui se passe est, la cellule est créée dans son propre fichier nib. L' Fichier de propriétaire pour ce fichier nib est notre contrôleur de tableau où le code réside au-dessus. Dans le fichier nib, la prise sur le tvCell Fichier de propriétaire est relié à la cellule personnalisé qui est créé.
Donc, après cette ligne de code:
tvCellis automatiquement connecté à la cellule personnalisé qui a été créé en vertu de la connexion de sortie de la plume. Il n'y a aucun besoin de s'inquiéter de boucle ou des indices. Le chargeur de bundle fait ça automatiquement. Ainsi, cette cellule personnalisé est ensuite affecté à la cellule qui est la cellule de tableau que cette méthode revient à la table pour afficher le contenu de cette ligne. Après cela, tvCell est fixé à zéro de sorte que la prochaine fois que cette méthode est appelée, le chargeur une fois encore bundle relie la sortie pour nous.
C'est tout simplement génial. Bravo à quiconque chez Apple pensait d'elle.
Si vous souhaitez le voir en action, Voici un projet Xcode qui utilise cette technique.
Nous avons bien fait, mais nous n'avons pas de chauve-souris 1,000.
Un endroit où nous avons manqué de chargement était dans les cellules de tableau créé dans Interface Builder.
Dans la première édition du livre, nous avons codé en dur de l'indice de la cellule. Cela a été mauvaise, parce que quand 2,1 expédiée, la structure du tableau retourné par NSBundle changé et notre code cassé. Whoops!
Dans la seconde édition, nous l'avons changé pour que le code n'utilise plus un indice codé en dur, mais au lieu itère sur le tableau retourné à la recherche d'un objet de la classe à droite (UITableViewCell). Ce fut une bien meilleure approche et fonctionne très bien.
Quelqu'un chez Apple pensé une meilleure façon. C'est effing brillant. Si brillante, en fait, que lorsque j'ai rencontré la documentation pour cela, il m'a fallu un certain temps pour comprendre exactement ce qu'ils faisaient. Voici le code exemple de la documentation d'Apple:
- (UITableViewCell *)tableView:(UITableView *)tableView cellForRowAtIndexPath:(NSIndexPath *)indexPath {
static NSString *MyIdentifier = @"MyIdentifier";
UITableViewCell *cell = [tableView dequeueReusableCellWithIdentifier:MyIdentifier];
if (cell == nil) {
[[NSBundle mainBundle] loadNibNamed:@"TVCell" owner:self options:nil];
cell = tvCell;
self.tvCell = nil;
}
UILabel *label;
label = (UILabel *)[cell viewWithTag:1];
label.text = [NSString stringWithFormat:@"%d", indexPath.row];
label = (UILabel *)[cell viewWithTag:2];
label.text = [NSString stringWithFormat:@"%d", NUMBER_OF_ROWS - indexPath.row];
return cell;
}C'est ce qui me confond au premier abord:
if (cell == nil) {
[[NSBundle mainBundle] loadNibNamed:@"TVCell" owner:self options:nil];
cell = tvCell;
self.tvCell = nil;
}La méthode loadNibNamed: le propriétaire: options retourne un NSArray avec le contenu de la plume, mais ce code ignore complètement ce tableau. Il n'a même pas le capturer. Ensuite, elle va sur et ayants allègrement quelques variables d'instance à une autre variable, par exemple, puis définit la variable première instance à néant.
Documentation d'Apple n'est pas parfait, mais habituellement, il est sacrément bon, si j'étais assez sûr que ce code a été bonne, je n'étais pas obtenir quelque chose. Il y avait une pièce du puzzle manquant.
Alors, j'ai regardé tvCell, qui a été déclaré plus tôt, et j'ai vu que c'était une IBOutlet.
"Plus curieux!" S'écria Alice.
Puis il m'est apparu. Le chargeur se connecte automatiquement bundle points faits pour Fichier de propriétaire quand il charge un fichier nib si la sortie est nulle. Notez que lorsque la plume est chargé, le code précise l'auto que le propriétaire du bundle. Donc, puisque cette classe est le contrôleur de Fichier de propriétaire, Lorsque nous avons la charge de la plume, la prise aurez connecté à un objet dans la plume si la sortie de ce nom sur les Fichier de propriétaire est relié à un objet dans la plume.
Alors, qu'est-ce qui se passe est, la cellule est créée dans son propre fichier nib. L' Fichier de propriétaire pour ce fichier nib est notre contrôleur de tableau où le code réside au-dessus. Dans le fichier nib, la prise sur le tvCell Fichier de propriétaire est relié à la cellule personnalisé qui est créé.
Donc, après cette ligne de code:
[[NSBundle mainBundle] loadNibNamed:@"TVCell" owner:self options:nil];
tvCellis automatiquement connecté à la cellule personnalisé qui a été créé en vertu de la connexion de sortie de la plume. Il n'y a aucun besoin de s'inquiéter de boucle ou des indices. Le chargeur de bundle fait ça automatiquement. Ainsi, cette cellule personnalisé est ensuite affecté à la cellule qui est la cellule de tableau que cette méthode revient à la table pour afficher le contenu de cette ligne. Après cela, tvCell est fixé à zéro de sorte que la prochaine fois que cette méthode est appelée, le chargeur une fois encore bundle relie la sortie pour nous.
C'est tout simplement génial. Bravo à quiconque chez Apple pensait d'elle.
Si vous souhaitez le voir en action, Voici un projet Xcode qui utilise cette technique.
Aucun commentaire:
Enregistrer un commentaire