UISplitViewController e la gerarchia vista complessa

StackOverflow https://stackoverflow.com/questions/2640225

Domanda

che sto facendo un demo tecnologico iPad e sto correndo in un problema tecnico serio.

Ho un concetto di app che sfrutta UISplitViewController, ma non come il controller primario per l'intera applicazione.

Il flusso app potrebbe essere descritta approssimativamente come questo:

schermata Home (UIViewController) Lista-> Dettaglio "Catalogo" (UISplitViewController) Super Screen Dettaglio (UIViewController ma potrebbe concepibile anche essere un figlio di SplitView).

Il problema è nel flusso tra casa e catalogo. Una volta che una vista UISplitViewController viene aggiunto alla UIWindow, comincia a lanciare attacchi sibilante.

Il problema può essere riassunta in questo modo:

Quando un UISplitView genera una vista popover, sembra poi essere agganciato alla sua vista primaria. Al momento di rimuovere l'UISplitView dalle subviews UIWindow, si otterrà un'eccezione CoreGraphics e la vista mancherà di essere rimosso.

Quando si aggiungono altre viste (presumibilmente in questo caso, nella schermata iniziale per il quale si sta tornando), loro non AutoRotate, invece, l'UISplitView, che non è riuscito ad essere rimosso a causa di un'eccezione CG, continua a rispondere alle la rotazione, invece, causando errori di rendering orribili che non può essere solo "affrontato". A questo punto, l'aggiunta di vista, anche ri-aggiungendo lo SplitView, provoca una cascata di rendere bug.

Poi ho cercato semplicemente di lasciare lo SplitView sempre presente come la vista "dal basso", e mantenendo l'aggiunta e la rimozione della schermata principale da su di esso, ma questo non riesce, come SplitView domina le chiamate cambiare l'orientamento, e schermata iniziale non lo farà rotazione, anche se si chiama [homescreen becomeFirstResponder]

Non si può mettere SplitView in una gerarchia come UINavigationController, si ottiene un errore di runtime a titolo definitivo, in modo che l'opzione è fuori dal tavolo. Modali basta guardare male e sono scoraggia comunque.

La mia presunzione in questo momento è che l'unico modo corretto per affrontare questo problema è così in qualche modo "Disarm" UISplitViewController in modo che possa essere rimosso dal suo punto di vista genitore senza un'eccezione non gestita, ma non ho idea di come.

Se volete vedere un app che fa esattamente quello che ho bisogno di fare, check out Gilt Groupe in App Store per iPad. Hanno tirato fuori, ma sembra che abbiano programmato un intero set visualizzazione personalizzata di transizione.

Aiuto sarebbe molto apprezzato.

È stato utile?

Soluzione 2

Ho risolto questo per me ... in realtà ha lavorato in giro ... con la presentazione di tutte le altre viste possibili a schermo pieno come modali del SplitView ...

Questo è un modo sgradevole di fare le cose nel mio libro, ma le foglie di Apple si poca scelta se si desidera sfruttare uno SplitView solo "qualche volta" all'interno di un app.

Altri suggerimenti

stati :

  

Il punto di vista di vista di controllo divisa   deve sempre essere installato come radice   vista della finestra dell'applicazione. voi   non dovrebbe mai presentare una vista combinata   all'interno di una navigazione o di scheda bar   interfaccia.

Questo non significa che dovrebbe essere vista radice e visualizzazione secondaria di un'altra vista. Anche se si aggiunge:

  

Non si dovrebbe mai presentare una visione spaccatura all'interno di un'interfaccia di navigazione o scheda bar

Questo non significa che è possibile aggiungere come una visualizzazione secondaria di qualsiasi altro controller sia. (Sorry)

Ho la sensazione che ciò che si sta verificando è il sottoprodotto di provare a farlo. Sono in realtà sorpreso che Gilt Groupe 's app non ha ottenuto respinto. Apple ha una tendenza a far rispettare queste linee guida HIG piuttosto strettamente ultimamente. Essi (cui è stato trovato già fuori) causa un errore di runtime piuttosto sgradevole quando si tenta di aggiungere a un navigationController.

Ho avuto un certo successo con la creazione di un secondo UIWindow. Mi associo l'UISplitViewController con quello, e passare fuori con la finestra principale quando voglio mostrare lo SplitView. Sembra funzionare essi come avrei voluto, ad eccezione di un leggero ritardo nelle rotazioni e un messaggio di log di "wait_fences".

A meno che il vostro sviluppo per i dispositivi carcere-rotto poi piegando le regole mele / desideri non è una buona idea. Come Jann e Jasconius stato sopra ciò significa mantenere una vista radice controllore SplitView, non eccessivamente utilizzando modali (vago) e non utilizzando più finestre.

Inoltre, il Gilt applicazione è disponibile solo negli Stati Uniti

I'v cercato di trovare una soluzione troppo e hanno finito per programatically rimozione vista dalla finestra come Tuannd parla, ma il bug di rendering paesaggio è imperdonabile.

@Jasconius, Qual è il numero massimo di modali sono si sta presentando in qualsiasi momento?

Io sono alle prese con lo stesso problema. Ho provato varie cose che colpiscono al UISplitViewController come una scatola nera e vedere come reagisce.

mi sembra di avere venire con una soluzione per il mio caso, che sembra funzionare in modo soddisfacente.

La chiave sembra essere che la prima vista aggiunta al UIWindow è l'unico visualizzare correttamente inizializzata. Tutti i problemi che ho avuto tendono a derivare da notifica non corretta del l'orientamento del dispositivo. Il primo punto di vista aggiunto, a quanto pare ha questo configurato correttamente.

Nel mio caso io non volevo l'UISplitView come la prima vista. Il seguente sta lavorando per me.

L'applicazione delegato app: didFinishLaunching metodo è speciale. Aggiungendo la vista UIWindow deve avvenire qui. Se è fatto altrove non venga configurato correttamente.

In sostanza, la salsa di magia, è avere la vista suddivisa essere il primo punto di vista aggiunto alla finestra. La sua quindi su OK per rimuovere il più a lungo si mantiene l'UISplitViewController. Da allora in poi si può scambiare altre viste dentro e fuori, tra cui l'UISplitView e la maggior parte le cose sembrano essere ok.

Ho ancora imbattersi in alcuni problemi. Popovers su viste diverse visualizzare le due parti sono confusi sulle viste cornici e posizione dei pulsanti della barra degli strumenti e visualizzeranno nella posizione sbagliata. Metto quindi in una posizione specifica e che sembra gestire questo caso.

Se un popover sulla vista divisa è ancora visualizzato, e si tenta di visualizzare un'altra vista, l'orientamento della seconda vista è confusa e si presenta lateralmente. Se questo punto di vista si accede prima della visualizzazione del pop-up, tutto va bene. Ho risolto questo mio respingendo manualmente il popover prima di passare a qualsiasi altra vista.

Ecco il codice se aiuta. Tutti i controllori sono variabili di AppDelegate

istanza 
- (BOOL)application:(UIApplication *)application didFinishLaunchingWithOptions:(NSDictionary *)launchOptions {
    // This also seems to work as good magic. Seems to set orientation and size properties that persist.
    [window addSubview:splitViewController.view];
    [splitViewController.view removeFromSuperview];

    [self switchToNewViewController:firstController];
    [window makeKeyAndVisible];
    return TRUE;
}

- (void)switchToNewViewController:(UIViewController *)newViewController {
    [popoverController dismissPopoverAnimated:FALSE];
    if (newViewController != currentViewController) {
        [currentViewController removeFromSuperview];
        currentViewController = newViewController;
        [window addSubView:newViewController.view];
     }
}

Volevo solo dire che stavo correndo in queste stesse questioni, ha trovato questo argomento del forum, e seguito i consigli da g051051 sopra. Questo è perfettamente funzionante per me. Io non vedo alcun problema tecnico, e nessun messaggio sulla wait_fences nella console del dispositivo.

Ho semplicemente usato IB per creare due oggetti UIWindow nel XIB principale, creato come normale l'UISplitViewController e poi anche un'istanza di mio altro controllore derivato da UIViewController (che sto usando per la visualizzazione a schermo intero). Ho semplicemente collegato fissando il RootViewController per ogni UIWindow al suo controllore appropriato.

In applicazione: didLaunch ...: metodo posso decidere quale finestra per inviare il metodo makeKeyAndVisible e quali set per nascosti. Quando l'utente vuole passare avanti e indietro devo semplicemente inviare makeKeyAndVisible a uno e impostare la proprietà nascosto dall'altra, è tutto quello che c'è da fare.

Come indicato tutti i messaggi relativi rotazione vengono inviati a ciascun controller appropriato, a prescindere da quale è associato con la finestra attualmente visibile.

In ogni caso, funziona alla grande per me, e in realtà abbastanza facile da configurare.

Autorizzato sotto: CC-BY-SA insieme a attribuzione
Non affiliato a StackOverflow
scroll top