IBOutlet debe ser débil?

Posible duplicado:
¿Debería ser IBOutlets fuerte o débil bajo ARC?

Leí brevemente sobre ARC y pensé bien, todo es fuerte y el delegado es débil.

Ahora estoy creando una vista en el generador de interfaces y haciendo IBOutlets, y la configuration pnetworkingeterminada de Xcode está configurada a débil.

Parece haber una razón para esta sugerencia, ¿hay alguna razón por la que la mayoría de IBOutlets querría una propiedad débil?

¿Eso es porque estas vistas (IBOutlets) ya están retenidas porque están adjuntadas a su supervisión? y rara vez reemplazamos los puntos de vista de IBOutlet?

Pero no veo ningún daño al establecerlo como fuerte, ¿hay algún problema?

Para una discusión sobre por IBOutlet references de IBOutlet deben ser débiles, consulte la Guía de progtwigción de resources: files de Nib . Cito de la guía:

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. Los puntos de venta que cree deberían por lo general ser débiles, porque:

  • Las salidas que se crean a las vistas subyacentes de la vista del controller de vista o de la window de un controller de window, por ejemplo, son references arbitrarias entre objects que no implican la propiedad.
  • Los puntos de venta fuertes se especifican con frecuencia mediante classs de frameworks (por ejemplo, la UIViewController de la vista de NSWindowController o la NSWindowController de la window de NSWindowController ).

Por mis propios dos centavos, hago las cosas strong si soy dueño de ella, o necesito una fuerte reference en caso de que el propietario se vaya y necesito que se retenga, ninguna de las cuales se aplica aquí. Entonces, en lugar de preguntar: "¿por qué no puedo hacerlo strong ?", Preguntaba "¿por qué querría hacerlo strong ?" Si no hay una buena razón para hacerlo, dejaría que Interface Builder lo hiciera y lo hiciera weak .

Es solo preference. La razón para debilitar o asignar es que las supervisiones, los controlleres, etc. mantendrán fuertes references durante la vida del object dentro de ese gráfico.

Personalmente, soy de la vieja escuela y apoyo las references fuertes, incluso en este escenario. A veces, usar references fuertes significa que es posible que necesites destruir explícitamente los componentes de los subgrafos de tus objects (por ejemplo, debes "romper" todas las dependencies circulares cuando desarmes). Solo uso débil en circunstancias muy excepcionales porque estoy a favor de la consistencia; Hay less variables en juego cuando / si algo va mal y cuando se leen progtwigs.