iphone - para - ¿Se permite que la[liberación automática] controle la vida útil del objeto?

liberar iphone gratis

Question

Quiero crear un objeto en Objective C pero no tengo una referencia a él.

¿Se permite que el objeto controle su propia vida llamando a [auto release]?

En caso de que se esté preguntando por qué necesito esto: quiero crear un objeto que se suscriba a algunas notificaciones, pero después de un tiempo, el objeto ya no es necesario y debería desaparecer.

Entonces, ¿se permite lo siguiente?

- (void) destroyMyself {
 [[NSNotificationCenter defaultCenter] removeObserver:self];
[self release];
} 

Answer 1

Bueno, parte del protocolo es que si envías la publicación a sí mismo, también deberías haber enviado retener una vez, lo que supongo que sí. Entonces no hay nada sospechoso. Me refiero a que el código de asignación debe poder controlar la vida útil de su instancia; el mismo solo puede prolongar su vida útil, nunca hacerlo más corto (ya que al hacerlo más corto, de repente dejaría al propietario asignador de la instancia con un puntero no válido).

Answer 2

Es legal, pero ten cuidado. Desea estar seguro de que nada más le enviará un mensaje después de que se libere.

He hecho este tipo de cosas para un esquema de fallas antes de que tuviéramos CoreData.

Answer 3

Las reglas son simples. Solo debes liberar un objeto si lo tienes. es decir, el objeto se obtuvo con un método que comienza con "nuevo" o "alloc" o un método que contiene una copia.

Reglas de gestión de memoria de cacao

Por lo tanto, un objeto no debe hacer [autoexclusión] o [auto autoreleración] a menos que haya hecho previamente [auto retención].

Answer 4

Para citar a la gran filósofa Alicia Silverstone, " tuve una sensación abrumadora de asco " cuando leí eso. Pero realmente no podría decirte por qué.

Creo que usaría autorelease lugar de un simple release ya que todavía estás ejecutando el código cuando lo llamas, pero, aparte de eso, no puedo pensar en ninguna razón técnica por la que no funcionaría.

Answer 5

Si ve esto en el código, es probable que esté mal. Sin embargo, hay una respuesta legítima para él en ciertas circunstancias que se pueden defender. (Así que asegúrate de que lo estás haciendo por las razones correctas).

Un buen ejemplo de cuándo esto tiene sentido, es cuando creas un objeto que se dispara para descargar una URL. El objeto permanece en la memoria mientras descarga la url, luego envía un mensaje a su delegado diciendo que los datos están listos (o que no se pudo descargar la url). Una vez que su mensaje ha sido enviado, se destruye a sí mismo ya que ya no es necesario. En esta situación, es posible que el código / función que creó el ''descargador de url'' ya no esté en la memoria, es decir, si se llamó en respuesta a una selección de usuario, un elemento de menú o una acción en un controlador de vista que ya no está en la pantalla .

Esto es útil cuando al código que crea el objeto de "descarga" no le importa si la descarga se completa o no.

Answer 6

Y usaré [auto autorelease] en lugar de [self release]. Porque normalmente se llama en

- (void)aMethod
{
[self.delegate aDelegateMethod:self];
[self release];
//If you add code related to self here, after [self release], you are making a huge mistake.
}

Si uso [auto autorelease], todavía puedo hacer algo después de autorelease.