Segues y borrar históricos ViewControllers de la memory

Tengo una aplicación para iPad que tiene muchas pantallas y muchas opciones segue. Por el momento, simplemente estoy usando performSegueWithIdentifier para iniciar estos segues, y mi temor es que estoy ocupando mucha memory a medida que el usuario realiza más y más segues. He visto que las personas recomiendan usar la function popToRootViewControllerAnimated: si se usa un UINavigationController, pero el problema es que no estoy usando uno. ¿Cómo puedo detener el número de proliferación de VC? La forma en que funciona la aplicación, el usuario vuelve constantemente al VC raíz, efectivamente una pantalla de búsqueda. Por lo tanto, si pudiera borrar la stack de VC cuando se necesita una segue, eso resolvería mi problema, creo, pero no tengo idea de cómo hacerlo. Gracias por cualquier sugerencia.

Cuando usa segues, el flujo se mueve hacia atrás y hacia adelante. Cuando el usuario se mueve hacia atrás (es decir, presiona "atrás"), entonces no empujará hacia un nuevo VC, pero aparecerá en un VC que ya existía. Cuando se activa, el VC actual se elimina de la stack y la memory.

Si tiene que seguir retrocediendo en el flujo, esto está mal. Solo necesitas seguir para seguir adelante.

UN PREPARADO ADECUADO PARA LA SEGUIDA

En preparación para segue, nunca debe crear sus propios controlleres de vista y presionar hacia ellos. El guión gráfico está ahí para hacer todo esto por ti.

Un método de prepareForSegue apropiado debería parecerse a este …

- (void)prepareForSegue:(UIStoryBoardSegue*)segue { if([segue.identifier isEqualToString:"SomeSegue"]) { MyNewViewController *controller = segue.destinationViewController; controller.someProperty = "some value to pass in"; } } 

Eso es todo lo que necesitas. Tenga en count que solo necesita esto si tiene la intención de pasar alguna información al nuevo controller de vista. Si no está pasando nada adelante, entonces no necesita este método.

Cuando el método finalice, el nuevo storyboard será empujado a la pantalla por el file de storyboard.

DESLUMBRES DE RUTA

Si tiene un flujo aleatorio (como en su comentario), entonces puede usar desenrollar segues para lograr esto.

En el controller de vista 'A' tiene una function como …

 - (IBAction)someUnwindAction:(UIStoryboardSegue*)sender { //some action to run when unwinding. } 

Necesita recibir un object UIStoryboardSegue. Si se configura como una IBAction, también puede acceder a ella desde Interface Builder.

Ahora cuando quieres ir A> B> C> B> A, simplemente usa el empuje y el pop estándar (desde el button de retroceso y el button de retroceso).

Cuando quiera ir A> B> C> A, puede usar la function desenrollar del controller C.

Si tiene un button de cancelación o algo en el controller C y esto está en el generador de interfaces y esto debería llevarlo de vuelta al controller A. Entonces, en el generador de interfaces debajo del controller C, tendrá un pequeño cuadrado verde con una puerta y una flecha apuntando fuera de el. Simplemente señale la acción del button cancelar a este símbolo y elija "someUnwindAction". (Nota, unwindAction está en A, el button está en C.) XCode luego lo usa para abrirlo todo de return a A y se ocupa de eliminar cualquier memory y esas cosas. Si lo desea, puede enviar información adicional a A también.

Si desea acceder a este desenrollar segue desde C mediante progtwigción, puede ejecutar …

 [self performSegueWithIdentifier:"someUnwindAction" sender:nil]; 

Esto también volverá a aparecer en A.

imho No veo ningún problema con el uso de segues, es mucho más simple que cualquier otra cosa. Si te preocupas por la memory consumida, simplemente perfila tu aplicación y observa cuánto come y con qué frecuencia se llama a tu "controller de presión de memory".

ok creo que lo he descubierto. Parece que funciona.

Dado que sigo volviendo a un VC común, estoy colocando el código en los lugares donde deseo volver a este VC 'root' para borrar la stack de VC.

Todavía realizo la segue real en mi código normal

 [self performSegueWithIdentifier:@"editBackToSearch" sender:self]; 

Sin embargo, en el método 'prepareForSegue:', ya no creo un nuevo object VC, sino que realizo cualquier trabajo que tenga sobresaliente (guarde mis datos) y luego borre la stack VC con el siguiente código.

 UIViewController *vc = self; while ([vc presentingViewController] != NULL) { vc = [vc presentingViewController]; } [vc dismissViewControllerAnimated:NO completion:nil]; 

Parece funcionar sin problemas y tiene el impacto deseado (confirmado a través del perfilador) de liberar la memory de que estos VC son absorbidos.

Un último comentario: por alguna razón no pude animar el command de rechazo, esto pareció desencadenar un ciclo infinito y resultó en un EXC_BAD_ACCESS. Con la animation configurada en NO, funciona muy bien.

Gracias por tu ayuda.