Por qué algunos puntos de venta se hacen fuertes references incluso difíciles la documentation especifica que los puntos de venta deberían ser de reference débil

Hola, soy novato en la progtwigción de iOS. Sé lo que es una reference fuerte y débil . Pero me confunde qué tipo de reference usar cuando tengo que lidiar con puntos de venta. Después de revisar la documentation que dice que

Las salidas generalmente deberían ser débiles, excepto las del Propietario del Archivo a los objects de nivel superior en un file de nib (o, en iOS, una escena de storyboard) que debería ser fuerte.

Entonces, lo que entendí después de pasar por la statement anterior es que las salidas que creamos deberían ser típicamente débiles de forma pnetworkingeterminada .

Pero mientras estudia algunos tutoriales, he encontrado el código donde las personas han declarado una salida como una reference sólida . Por ejemplo, considere el siguiente código:

@interface AboutViewController : UIViewController @property (nonatomic, strong) IBOutlet UIWebView *webView; @end 

El código :

 @property (nonatomic, strong) IBOutlet UIWebView *webView; 

dice que nuestro AboutViewController tiene un object UIWebView .

Pero, ¿por qué necesitamos una fuerte reference aquí para el object UIView ? Como dice el documento, ¿no debería ser una reference débil?

También explique en la statement de documentation que he citado anteriormente, ¿qué significa el Propietario del file para los objects de nivel superior ?.

He pasado por muchas de las preguntas similares en este website, pero ninguno de ellos me ayudó a aclarar mi duda. Entonces, por favor ayuda. Gracias por adelantado 🙂

Solutions Collecting From Web of "Por qué algunos puntos de venta se hacen fuertes references incluso difíciles la documentation especifica que los puntos de venta deberían ser de reference débil"

Qué usar para los elementos GUI que no son de nivel superior, fuertes o débiles, depende de cómo usará sus puntos de venta. Si tienes una reference débil

 @property (nonatomic, weak) IBOutlet UIWebView *webView; 

luego después del método de llamada

 [webView removeFromSupeview]; 

su webView será nula y será imposible restaurar UIWebView simplemente agregando

 [self.view addSubview:webView]; 

Si esto es apropiado para usted, es mejor usar débil porque liberará la memory de webView cuando no la necesite.

Por otro lado, en caso de una strong reference después

 [webView removeFromSupeview]; 

webView todavía tendrá referenceCount> 0 y webView será desasignado solo si el propietario lo liberará explícitamente

 self.webView = nil; 

o en el propietario

 - (void)dealloc 

junto con el propietario mismo.

Por lo general, no hay diferencia si tiene una GUI estática. Si desea eliminar (no esconder) algunas vistas, agregue más tarde, se deben usar references fuertes.

Los objects de nivel superior deben mantenerse fuertes. Me gusta

 @property(nonatomic,retain) UIView *view; 

en UIViewController.

Por lo general, no hace daño usar una reference fuerte en lugar de una débil en el caso de salidas como esta. Y en algunos casos, necesita una reference sólida.

La idea es que algo tenga que mantener una fuerte reference al object en todo momento o podría desaparecer. Si el object es una vista que es una subvista de otra vista, entonces esa supervisión mantendrá una fuerte reference a ella y, por lo tanto, puede usar una reference débil. Pero, si va a hacer algo más con esa vista, como eliminarla de su supervisión por algún motivo (tal vez para reutilizarla en otro lugar, o algo así), entonces querrá usar una propiedad fuerte para que siempre haya algo sosteniéndolo con fuerza.

Con respecto al problema del propietario del file, eso se debe a que el object de nivel superior (muy probablemente una vista) no tiene una vista de supervisión que se aferre a él, por lo que debe utilizar una propiedad sólida para que se aferre a ella.

La respuesta simple es que a less que esté apoyando iOS 5, los puntos de venta siempre deben ser fuertes.

El propósito de las salidas débiles era que en iOS5, si el sistema descargaba la vista del controller de vista para ahorrar memory, cualquier salida que apuntara a las subvenciones sería liberada automáticamente.

En iOS 6 y posteriores, el sistema nunca descarga la vista del controller de vista (viewDidUnload nunca se llama) porque Apple encontró una manera de liberar la mayor parte de la memory utilizada por una vista sin liberar la vista misma.

En consecuencia, las tomas de stream en un controller de visualización nunca necesitarán liberarse hasta que se libere el controller de visualización en sí, en cuyo caso ARC limpiará todas las tomas de todos modos.

Así que solo usa fuerte para todas tus salidas y no tendrás que preocuparte por errores obscuros o advertencias del comstackdor debido al uso del tipo de reference incorrecto.

Citando la Guía de Progtwigción de Recursos de Apple,

Cada vez que solicita a la class NSBundle o NSNib que cargue un file de nib, el código subyacente crea una nueva copy de los objects en ese file y los devuelve. Debe asegurarse de mantener el nuevo gráfico de object todo el time que sea necesario, y renunciar a él cuando haya terminado con él. Por lo general, necesita references sólidas a los objects de nivel superior para asegurarse de que no se desasignen; no necesita references fuertes a los objects más abajo en el gráfico porque son propiedad de sus padres, y debe minimizar el riesgo de crear ciclos de reference fuertes.

En el caso de classs marco como UIViewController el object de nivel superior para el file NIB es la propiedad view . Si revisa la documentation , se declara como retain (similar a strong ).

 @property(nonatomic, retain) UIView *view 

Por lo tanto, cualquier subvención a esta view contenedor debería ser propiedad de ella automáticamente. Si declara que estos puntos de venta de subview son tan strong , crearán un ciclo strong y causarán pérdidas de memory cuando el marco trate de limpiar la view contenedor. Para evitar estos ciclos fuertes, todas las subvenciones (o los objects no de nivel superior) deben declararse como properties weak .

¿Cuándo puede declarar que IBOutlet es tan strong

Los puntos de venta deben cambiarse a fuertes cuando se deba considerar que el punto de venta posee el object referencedo:

  • Como se indicó anteriormente, este suele ser el caso de los objects de nivel superior del propietario del file en un file de nib, a menudo se consideran propiedad del propietario del file.
  • En algunas situaciones, es posible que necesite un object de un file de nib para que exista fuera de su contenedor original. Por ejemplo, puede tener una salida para una vista que puede eliminarse temporalmente de su jerarquía de vista inicial y, por lo tanto, debe mantenerse de forma independiente.

webView verificar su código si el object webView califica para case2 como se indicó anteriormente. Si no, el tutorial tiene este mal y en realidad debería ser weak .

¡Espero que ayude!