Perché Apple non consente la sottoclasse di UINavigationController? E quali sono le mie alternative alla sottoclasse?

Question

Attualmente sto sviluppando un'applicazione iPhone a schede in cui il controller di visualizzazione di ciascuna scheda è un'istanza di UINavigationController e dove ogni sottocontrollo di ognuna delle istanze è un'istanza di UITableViewController. Idealmente, mi piacerebbe creare sottoclasse UINavigationController in modo che il controller per ogni scheda sia una sottoclasse di UINavigationController che (oltre ad avere tutte le funzionalità standard UINavigationController, ovviamente) funge da origine dati e delegato per ciascuna delle viste tabella associate a i suoi subcontrollori. Cercare di farlo sembra interrompere la funzionalità di base UINavigationController nella sottoclasse.

Visto che Apple dice nella loro documentazione iPhone che non si deve sottoclasse UINavigationController, e le cose sembrano rompersi quando si fa, mi chiedo come devo fare per estendere UINavigationController's funzionalità senza sottoclasse, e in generale, come si dovrebbe lavorare attorno alle limitazioni delle sottoclassi durante lo sviluppo del cacao.

Grazie!

Answer 1

Per riferimento, si noti che da iOS 6, UINavigationController può essere sottoclasse legalmente.

Questa classe è generalmente utilizzata così com'è, ma può essere sottoclasse in iOS 6 e versioni successive. UINavigationController Class Reference

Naturalmente, questo non significa che si dovrebbe sempre. Ma tu puoi.

Answer 2

Perché vogliono evitare l'incoerenza dell'interfaccia utente che affligge ogni altra piattaforma.

Answer 3

Perché mai vuoi che lo UINavigationController agisca come origine dati per la tabella? L'intero punto di UITableViewController consiste nel suddividerlo in sottoclasse e funge da origine dati per lo UITableView che inserisce e riempie anche la vista padre.

Answer 4

Come ho capito, la sottoclasse non è incoraggiata perché l'Objective C consente a una sottoclasse di accedere troppo ai meccanismi interni della sua superclasse.

L'alternativa suggerita per scrivere una sottoclasse è scrivere un delegato, in questo caso un UINavigationControllerDelegate. È quindi possibile incapsulare il comportamento specifico che si desidera estendere a questa classe delegata e collegarlo a UINavigationController ogni volta che ne avete bisogno.

Answer 5

Se la gerarchia del controller disponibile non soddisfa le proprie esigenze in termini di gestione dei dati (supponendo che non si sappia perché si desidera che un oggetto sia l'origine dati per più viste), è sempre possibile creare ulteriori dati e/o classi di controller (sottoclassi di NSObject almeno).

È possibile mantenere un dato o un altro oggetto durante la modifica delle viste in vari modi. (1) una proprietà della classe di delega dell'applicazione. Qualsiasi oggetto nella vostra applicazione può ottenere l'istanza delegato app con

[[UIApplication sharedApplication] delegate] 

Utilizzare questa parsimonia dal momento che è essenzialmente la creazione di variabili globali.

(2) È possibile passare dati o altri oggetti dal controller al controller mentre si passano le sottoclassi di visualizzazione del controller o le si richiamano all'interno delle schede.

(3) I dati di base sono un altro modo, ma richiede un sacco di cacao sotto la cintura, e devi ancora gestire le istanze di contesto.

Answer 6

Vado avanti e dico che la tua idea ha qualche merito, se ad ogni livello stai veramente utilizzando lo stesso tipo di dati e ogni livello ha forse un diverso delegato per gestire la creazione di celle.Fondamentalmente non c'è ragione per cui non si possa sottoclasse il controllore di UINavigation per aggiungere un livello di dati totalmente ortogonale in cima, perché non ha nulla a che fare con l'interfaccia utente o il comportamento che UINavigationController sta gestendo (che è ciò che Apple è preoccupato di fare casino con). Per chi si oppone all'idea, pensala come un archivio dati per scheda che tutte le pagine in una scheda possono accedere al posto di ogni pagina del sistema che deve andare su AppDelegate o avere un gruppo di singleton. Beh, fondamentalmente è un singleton, ma almeno uno che è già lì e ottiene automaticamente il riferimento passato.

Detto questo, terminerò con una proposta di progettazione alternativa. Penso che probabilmente vorrai eseguire il drill down su più livelli riutilizzando lo stesso codice per generare celle e in modo tale da avere lo stesso tipo di dati a ogni livello. Un approccio migliore per gestire è quello di avere un controller di visualizzazione che si alimenta il sottoinsieme di dati da visualizzare, e quando un utente esegue il drill down crea semplicemente un'altra istanza dello stesso controller di visualizzazione con quel nuovo sottoinsieme di dati. Questo approccio è molto meglio dell'idea di avere il controller di navigazione come delegato di tavolo per ogni livello, perché dovresti fare un sacco di ricablazioni in movimento avanti e indietro e richiederebbe ancora più lavoro per ricordare la posizione di scorrimento ad ogni livello livello per l'avvio. È per questo che si desidera mantenere drill-down utilizzando più istanze di controller di visualizzazione, ma più istanze non devono significare più classi.