Delegados en Objective-c

¿Es la práctica normal en el objective c usar el controller como el delegado para varias implementaciones de protocolo. Me refiero al uso del iOS SDK, ¿o es una buena idea tener classs separadas que se hagan cargo del rol de un delegado? ¿O es simplemente un caso de lo que mejor se adapta al escenario? Tengo mucha curiosidad por las mejores prácticas en Objective c, ya que estoy aprendiendo a codificarlo de forma aislada y no tengo un experto en "mundo real" al que recurrir.

"Controlador" se centra en la propiedad y Fachada. Los objects exteriores hablarán con el controller en lugar de con el controlado. El único object que generalmente debería hablar directamente con un UITableView es UITableViewController . El controller generalmente posee el object controlado y el controller debe tener al less una vida útil tan larga como la controlada.

"Delegado" se centra en el comportamiento, la estrategia y el observador. Un object le pide a su delegado orientación sobre los comportamientos (¿debo mostrar estos datos? ¿De qué color debería ser? ¿Puedo hacer esta acción?). Un object le dice a su delegado cuándo suceden cosas interesantes (me toqué. Estoy a punto de terminar algo. Tuve un problema). Un tipo especial de delegado contesta preguntas de datos (¿qué datos van en la línea 3?). Esas son llamadas fonts de datos.

Cuando es común que el rest del sistema hable con un "controller", generalmente no es apropiado hablar con un "delegado". Por lo tanto, por lo general, es apropiado tener un puntero a un UITableViewController y enviarle posts desde otros lugares del sistema. No es apropiado tener un puntero a la tableView del controller; deberías estar trabajando en el controller. Por otro lado, si tiene un puntero a un object, generalmente no es apropiado solicitar su delegate . Si es necesario, probablemente haya diseñado algo incorrectamente. (El ejemplo más notable es [[NSApplication shanetworkingApplication] delegate] que casi siempre es algo incorrecto. AppDelegate es el delegado de la aplicación, no un terreno de dumping para los globals).

Si un object tiene un controller, el controller casi invariablemente es el delegado. A mis reglas anteriores con las que hablas, cuando un object es controller y delegado, entonces es un controller.

Es posible que un único object sea el delegado de varias cosas, particularmente si la mayoría de las cosas son de corta duración (vistas de alerta, por ejemplo). No es raro que UIViewController se delegue en algunas cosas.

  1. Mantener a los delegates como classs separadas hace que el código también sea limpio y portátil. Puede volver a usar esas classs delegadas para algún otro propósito simplemente copiándolas y pegándolas y haciendo pequeños cambios.

  2. Existe la ventaja de mantener a los delegates en la misma class por mantenerlos en classs separadas. Puede acceder fácilmente a las variables / objects privados en la class, lo que no es posible en el primer caso.

  3. Si mantiene separados a los delegates y desea pasar algún valor a la class principal, es posible que deba crear otro delegado 🙂 o agregar observadores o debe pasarlos utilizando algunas properties.

Respuesta corta: Sí, es muy común que un controller de vista sea el delegado de una vista (o más de una vista) que administre.

Ejemplos: UITableViewController es una class diseñada para administrar una instancia de UITableView, e implementa los protocolos de fuente de datos delegates y de vista de tabla (una fuente de datos es otro tipo de delegado). Del mismo modo, sería natural que un controller de vista sea el delegado para una vista del selector, barra de búsqueda, campo de text, etc.

Justificación: las opiniones realmente no deben saber dónde proviene la información que muestran, pero sí los controlleres, por lo que es natural que proporcionen datos y tomen decisiones sobre cómo debería comportarse una vista determinada. Lo mismo puede ser cierto para otros types de objects, pero debes usar algo de sentido común. La aplicación tiene su propio object de delegado que generalmente es responsable de crear al less algunos de los controlleres de vista y, a menudo, el model de datos, por lo que obviamente no tendría sentido que un controller de vista juegue ese rol.

La mejor práctica es depender tanto del requisito como del código. La mejor práctica más utilizada es MVC Pattern. Obtendrás la idea una vez que la implementes. También hay algunos patrones de layout que puedes leer. Pero para iPhone prefiero MVC. Y para los delegates sí, es la práctica normal en el objective-c usar el controller como delegado. El objective-c está diseñado de esta manera.

Si planea transmitir información a varias partes de su aplicación, NSNotification es una buena opción (incluso si hace que las cosas sean un poco complicadas de entender por otros).

En otros casos, tener un delegado asociado con un protocolo es una buena opción para dejar las cosas claras y aisladas en términos de código.

KVC también es otra forma de implementar interacciones en su código: http://developer.apple.com/library/mac/#documentation/Cocoa/Conceptual/KeyValueCoding/Articles/KeyValueCoding.html

Dependiendo de lo que planees hacer, una solución podría ser mejor que otra, lo mejor es jugar con cada solución para aprender más sobre ellas … Te ayudará a tomar la decisión correcta cuando diseñes tu próximo iOS request !

Aquí voy:

Supongamos que tiene una class A y otra B.

"a" es el object de la class A

En "a" si instancies B, como "b" y le pasas a sí mismo, es decir, "a"

Ahora puedes desencadenar fácilmente el método de esa variable "a" u simplemente pasaste a "b" porque tienes acceso a ese object. Pero el esgulp comienza cuando termina la class B y comienza a lanzar "b". Ahora, debido al uso de "a", toda la memory asignada para "b" se liberará pero no se liberará y se ennetworkingará siempre que no se libere "a". Dios te salve si estás usando recursivamente la instanciación de class B.

Por lo tanto, mediante el uso de delegado, puede utilizar todos los methods deseados de class A y mantenerse alejado de este problema también.