Delegate et DataSource 'externe'

iLandes

Bonjour,

 

Il y a un truc qui m'échappe dans la gestion des uipicker. J'utilise toujours self pour les delegate et les datasource. Mais aujourd'hui j'ai voulu mettre le protocole dans une autre classe.

 

Je n'y arrive pas. J'ai placé mon projet sur github :

 

https://github.com/iLandes/TimeToBars.git (Branch BugReport).

 

Voila ce qui marche et ce qui ne marche pas se trouve ici

 

        // DO NOT WORK !!!!

        //

        // [_myTimePicker setDataSource:_myMintuesSeconds];

        // [_myTimePicker setDelegate:_myMintuesSeconds];

        

        //

        // WORK

        [_myTimePicker setDataSource:self];

        [_myTimePicker setDelegate:self];

 

_myMinutesSeconds est un NSObject <UIPickerViewDataSource, UIPickerViewDelegate>. Je fais plus hua un alloc/init de cet objet.

 

Le code du protocole est basique :

 

#pragma -mark DataSource Protocole

- (NSInteger)numberOfComponentsInPickerView:(UIPickerView *)pickerView {

    return 2;

}

 

- (NSInteger)pickerView:(UIPickerView *)pickerView numberOfRowsInComponent:(NSInteger)component

{

    return 10;

}

 

#pragma -mark Delegate Protocole

- (NSString *)pickerView:(UIPickerView *)pickerView titleForRow:(NSInteger)row forComponent:(NSInteger)component

{

    return @test;

}

 

- (void)pickerView:(UIPickerView *)pickerView didSelectRow:(NSInteger)row inComponent:(NSInteger)component

{

    NSLog(@selected);

}

 

D'avance merci pour votre aide

 

s

e

b

AliGator

J'ai pas regardé ton projet sur github, mais qui retient ton objet _myMintuesSeconds du coup ?

C'est bien beau de faire un alloc/init de "_myMintuesSeconds" mais si "_myMintuesSeconds" n'est retenu (strong reference) par personne " ni par la property delegate de ton datePicker, qui est __weak, ni par personne d'autre " alors il va forcément disparaitre de la mémoire et retomber à  nil.

Il faut penser à  le retenir avec une strong reference (par exemple une @property(strong) sur ton objet self) tant que tu en as besoin sinon si personne ne s'intéresse plus à  lui il va être désalloué, c'est le principe.

iLandes

You are so strong ! 

 

Je n'ai pas connu les périodes pré-ARC où il fallait s'occuper de la mémoire. Du coup je ne me suis jamais trop posé ce genre de question et fait mes @property avec les valeurs par défaut.

 

Merci de ton aide.

AliGator

C'est la plus grosse erreur que font les gens qui n'ont connu que ARC : ils croient que parce qu'il y a ARC, TOUS les problèmes afférents à  la gestion mémoire ont disparu.

Ce n'est pas parce qu'ARC est là  qu'il ne faut pas avoir conscience des problématiques de weak/strong, qui ont un sens même si la mémoire est gérée automatiquement. Car il faut bien que tu indiques si la relation entre tes objets est forte ou faible. (Un peu comme en CoreData où tu indiques des Delete Rules)

D'ailleurs avec Swift qui vient d'arriver c'est pareil, le statut est le même. Même s'il n'y a plus de pointeurs, que tout est géré automatiquement avec ARC et tout... il faut quand même indiquer quand on veut des relations "weak" ou "unowned" au lieu des relations "strong" par défaut. C'est une problématique qui reste vraie, et à  laquelle il faut penser et dont il faut avoir conscience dans tous les cas.

C'est de toute façon une description sémantique de ton modèle, pour indiquer qu'un Livre **possède** (strong reference) des pages, et que des Pages **appartiennent** (weak reference) à  un Livre. Ca n'est pas spécialement lié au fait que ta mémoire soit gérée par ARC ou par un autre moyen. C'est une caractéristique de ta relation. Notion et caractéristique qui existent d'ailleurs jusque dans UML, puisque UML aussi fait la distinction entre **association** et **composition**. L'arrivée d'ARC n'enlève en aucun cas tous ces concepts.