2012-04-26 13 views
6

Aunque estoy seguro de que existen, tengo dificultades para encontrar o establecer una práctica recomendada oficial para declarar puntos de venta en un ViewController.¿Deberían IBOutlets ser ivars o propiedades?

Hay 3 opciones por lo que yo puedo ver:

  1. Ivar única
  2. propiedad sólo
  3. propiedad respaldado con una Ivar

Xcode se bloquea actualmente cuando intento y concesionarios -generar una propiedad arrastrando mi ViewController desde IB, pero por lo que recuerdo, hacerlo crea una propiedad sin un ivar. También es posible arrastrar a la sección ivar y esto creará un ivar sin una propiedad. Esto sugiere que los puntos de venta solo de propiedad e ivar solo están de acuerdo con Apple.

Por lo tanto, en viewDidUnload necesitamos asignar nil a cualquiera de nuestros puntos de venta, pero ¿qué pasa con dealloc. Si hemos utilizado una propiedad sin un ivar, ¿cómo podemos liberar nuestro outlet dado que se supone que no debemos usar ningún accessors en un init o dealloc?

Me parece que el único patrón que nos permitiría liberar nuestra salida sin un acceso es utilizar una propiedad respaldada con un ivar, por lo que podemos liberar manualmente nuestro ivar en dealloc sin utilizar su acceso, sin embargo, este es el una opción que la generación de código de Apple no admite.

Respuesta

1

Como regla general, suelo crear accesos para IBOutlet s.

En ARC o proyectos no ARC que suelo hacer lo siguiente:

//.h (ARC) 
@property (nonatomic, weak) IBOutlet UILabel* myLabel; 

//.h (non-ARC) 
@property (nonatomic, retain) IBOutlet UILabel* myLabel; 

//.m 
@synthesize myLabel; 

De esta manera se puede dejar que el compilador para crear una variable de instancia para usted. Pero también puede declarar su variable de instancia y decirle al compilador que la use.

Luego puede usar esa variable de accesos/instancia donde quiera.

El Apple Memory Management guide dice que debe evitar los métodos de acceso en los métodos init o dealloc cuando tiene proyectos que no son ARC. Entonces, por ejemplo:

// (non-ARC) 
- (void)dealloc 
{ 
    [myLabel release]; myLabel = nil; // I'm using the instance variable here! 
    [super dealloc];  
} 

Esto es muy importante en proyectos que no son ARC. La razón es que, si no hay un descriptor de acceso, KVC asignará el objeto de plumín a la variable de instancia y pondrá un retener sobre él. Si olvida liberarlo, podría tener una pérdida de memoria. Usar un descriptor de acceso te obliga a liberar ese objeto al final.

Sugiero leer friday-qa-2012-04-13-nib-memory-management por Mike Ash. Es un artículo muy bueno sobre la administración de plumillas y memoria.

Espero que ayude.

+0

Gracias. Eso es claro y un buen enlace. – Undistraction

+0

@ 1ndivisible De nada. Envíe o marque como respondido si lo desea. Aclamaciones. –

+0

La llamada a super dealloc debe venir después del lanzamiento de la variable de instancia. –

1

Aquí está mi comprensión

Usar las propiedades de las variables que se accederá por otras clases, ya sea leer (captadores) o escrita (a) definidores. Ambos setters y getters se sintetizan para las propiedades.

Utilice ivars para las variables que serán utilizadas internamente por la clase propietaria solamente, es decir, otras clases no establecerán ni obtendrán sus valores.

Claro que puede usar propiedades en lugar de ivars, pero incurren en la sobrecarga de llamada de función cada vez que se acceden. Entonces, si tiene una variable interna a la que su clase tiene acceso MUCHO, las llamadas a función afectarán el rendimiento en tiempo real, y esto se puede evitar al declararlas como ivars.

Cuestiones relacionadas