Riutilizzo di UIViewController per situazioni modali e non modali

Question

Ho un UIViewController & # 8212; chiamiamolo " FormController " & # 8212; che è semplicemente una forma che modifica un oggetto. Voglio usarlo in 2 diverse situazioni:

1. Creazione di un nuovo oggetto & # 8212; & nbsp; utilizzando l'utilizzo del presentModalViewController di UINavigationController: metodo .

2. Modifica di un oggetto esistente & # 8212; & nbsp; spingi il controller di visualizzazione nello stack UINavigationController, non usando un metodo di dialogo.

C'è una leggera differenza in questo nella situazione modale vorrei avere una barra degli strumenti con " Annulla " e "Fatto" pulsanti, mentre nella situazione dello stack vorrei solo avere la barra di navigazione fornita da UINavigationController.

Questo sarebbe simile all'applicazione Contatti in cui il " Nuovo contatto " e il " Modifica contatto " le schermate sembrano utilizzare lo stesso controller di visualizzazione, ma il modulo Nuovo contatto viene presentato in modo modale mentre la schermata Modifica viene inserita nello stack di navigazione.

La mia domanda è: qual è il modo migliore per gestire entrambe le situazioni senza dover scrivere 2 controller di visualizzazione separati, ma per lo più identici?

Ho pensato di creare un " ModalFormController " che incapsula il nudo "FormController" attraverso la composizione e aggiunge una barra degli strumenti, ma ho letto da qualche parte nei documenti che Apple non consiglia di nidificare i controller di visualizzazione.

Answer 1

Quello che faccio (a volte) è impostare un enum che specifica il tipo di controller di visualizzazione.

Ad esempio, potresti avere due tipi: un tipo Modifica e un tipo Aggiungi (" nuovo ").

Il tipo Aggiungi viene implementato tramite un controller di visualizzazione modale, mentre il tipo Modifica viene inserito in uno stack di navigazione esistente.

Nel metodo -viewDidLoad: del controller di visualizzazione, faccio semplicemente un albero switch / case che imposta il titolo e altre caratteristiche dell'aspetto a seconda dell'enumerazione del tipo sopra specificata .

La cosa bella di questo è che è facile aggiungere un nuovo tipo. Il rovescio della medaglia è che l'albero condizionale per la gestione di questa enumerazione può complicarsi rapidamente, a seconda di quanto diversi siano i tipi.

Ma l'albero switch / case rende molto più facile la gestione.

Quindi, dipende da cosa stai cercando di fare con i due tipi. Ma è sicuramente fattibile.

Answer 2

Perché non utilizzare la sottoclasse? Rendi ModalCreateFormController una sottoclasse di EditFormController e gestisci gli elementi specifici del modale nella sottoclasse.

Answer 3

Oltre ad avere una proprietà esplicita sul view controller (come suggerisce Alex Reynolds), altri due approcci che mi vengono in mente sono:

1. Se hai qualche tipo di oggetto modello che stai modificando, chiedigli lo stato corrente. Se è mai stato salvato, sei in modalità modifica. Altrimenti, sei in modalità di creazione.

2. Guarda il valore della proprietà parentViewController del controller. Se è un'istanza di UINavigationController , allora sei nello stack di navigazione. Se ti viene mostrato in modo modale, sarà un'istanza del controller dell'elenco.

Answer 4

Ug, odio gli extra di avorio & # 8230;

Uso questo invece:

if([[self.navigationController viewControllers] objectAtIndex:0] == self){

        //Modal

    }else{

        //Pushed

    }

È un po 'un trucco, ma stiamo usando la logica che se il controller di vista offensivo è il primo nello stack, non puoi tornare indietro. In realtà stiamo ignorando il fatto che venga visualizzato modalmente.

Answer 5

Ho dovuto farlo un sacco di volte nella mia app e dopo aver provato un paio di modi diversi di farlo, tra cui sottoclassi modali e amp; classi helper modali riutilizzabili che utilizzavano forwardInvocation. Ho scoperto che il modello migliore era creare un metodo contenenteModalViewController per ogni controller di visualizzazione che (di solito) crea e restituisce un UINavigationController che il chiamante può utilizzare con presentModalViewController.

Nella maggior parte dei casi questo metodo crea e restituisce un UINavigationController con self come controller della vista principale (con ripetute chiamate al metodo che controlla self.navigationController e lo restituisce invece se non è nullo). In altri casi ho creato prima un fittizio controller di root e ho premuto auto sul secondo per ottenere un pulsante Indietro. Quindi un trucco può essere usato per catturare il pulsante Indietro: http: // smallduck .wordpress.com / 2010/10/05 / intercettando-UINavigationController /

In alcuni casi la vista non ha bisogno di una barra di navigazione e quindi questo metodo regola solo alcuni flag e restituisce self. Ho anche scoperto che in alcuni casi che necessitavano di una barra di navigazione era più semplice fare in modo che quel metodo invocasse self.view, quindi modificare la gerarchia della vista per aggiungere un UINavigationBar e restituire nuovamente self. Ma in ogni caso, l'installazione spesso è isolata da quel metodo e il chiamante lo gestisce in ogni caso.

Answer 6

Apple spiega come l'applicazione contatti funziona sotto il cofano:

  

Per consentire a una classe di controller di visualizzazione personalizzata di essere utilizzata per visualizzare e modificare il contenuto, sovrascrivere il metodo setEditing: animato: .

Ottieni alcune funzionalità gratuitamente, ad es. Pulsante Modifica / Fine .