2016-04-14 41 views
7

In iOS 9.2, un WKWebView che restituisce HTML con tabelle a larghezza fissa più grandi della larghezza del dispositivo potrebbe essere detto di ridurre il contenuto per adattarlo aggiungendo un tag viewport come questo:WKWebView viewport shrink-to-fit che non funziona su iOS 9.3

<meta name="viewport" content="width=device-width, shrink-to-fit=YES"> 

Questa linea causato la WKWebView per diminuire efficacemente la finestra in modo che l'intera pagina fit resi in frame vista senza la necessità di barre di scorrimento. Ad esempio, si consideri il codice seguente, quando eseguito in viewDidLoad in una vaniglia un'unica vista app:

WKWebViewConfiguration *wkWebConfig = [[WKWebViewConfiguration alloc] init]; 
WKWebView *newWebView = [[WKWebView alloc] initWithFrame:CGRectMake(0,40,self.view.frame.size.width, self.view.frame.size.height - 40) configuration:wkWebConfig]; 
NSString *toRender = @"<head><meta name=\"viewport\" content=\"width=device-width, shrink-to-fit=YES\"></head><body><table width=700 style='background-color: blue; color:white; font-size=20px'><tr><td>this is some text that is long enough to exceed the width of the iphone 6 unless shrink-to-fit is applied</td></tr></table></body>"; 
[newWebView loadHTMLString:toRender baseURL:nil]; 
[self.view addSubview:newWebView]; 

Il contenuto rende in questo modo:

enter image description here

Tuttavia, questo comportamento è cambiato al punto 9.3. Il codice identico in esecuzione in 9.3 rende in questo modo:

enter image description here

(Anche se non si può vedere nello screenshot, v'è una barra di scorrimento orizzontale)

Ricerca altre domande su StackOverflow e altrove, sembra che la maggior parte delle altre persone preferisca il comportamento 9.3. Tuttavia, ho bisogno del comportamento 9.2, di shrink-to-fit. Quindi, la mia domanda è: qualcuno sa come ottenere lo stesso comportamento strizzacervelli in 9,3? E qualcuno sa se questo cambiamento è intenzionale o un bug che verrà corretto nelle versioni successive?

mio codice di prova può essere trovato alla https://github.com/nsolter/NSWebViewShrinkTest, specificamente https://github.com/nsolter/NSWebViewShrinkTest/blob/master/NSWebViewShrinkTest/ViewController.m

risposta

6

ho presentato un bug report con Apple, e questa è la risposta:

"No, non vogliamo mantenere shrink-to -funzionalità. La soluzione alternativa consiste nell'utilizzare un meta tag viewport che descrive correttamente la larghezza del contenuto. "

Ho provato questo. Se, nel tag viewport, si specifica una larghezza della larghezza effettiva del codice html dopo il rendering, verrà visualizzato correttamente sulla larghezza del dispositivo. Nel mio esempio sopra, con una larghezza di tabella di 700, se si specifica: <meta name=\"viewport\" content=\"width=700, shrink-to-fit=YES\">

Quindi la pagina verrà visualizzata senza barre di scorrimento orizzontali.

Nota che non è possibile specificare una proprietà di visualizzazione su scala iniziale. Quindi non viene visualizzato con la larghezza corretta.

Questo ovviamente non è l'ideale, perché generalmente non si conosce la larghezza dell'Html renderizzato fino a quando non lo si esegue. La mia soluzione attuale è renderla una volta con width = device-width, quindi renderla di nuovo con width = X, dove X è la larghezza effettiva della pagina renderizzata la prima volta.

+0

Sto anche usando width = device-width e affrontando lo stesso problema. Stai ricaricando la pagina con width = X ?? – anoop4real

+0

In sostanza, sì. In realtà lo sto visualizzando in una nuova WKWebView che non è attualmente visualizzata e quindi si scambia in quella nuova webview. –

+1

Avete alcuni campioni? – anoop4real