Visualizzazioni Web in Xamarin.iOS

Nel corso della durata di iOS Apple ha rilasciato diversi modi per gli sviluppatori di app di incorporare funzionalità di visualizzazione Web nelle proprie app. La maggior parte degli utenti usa il Web browser Safari predefinito nel dispositivo iOS e pertanto si aspetta che la funzionalità di visualizzazione Web di altre app sia coerente con questa esperienza. Si aspettano che gli stessi movimenti funzionino, che le prestazioni siano uguali e che la funzionalità sia la stessa.

iOS 11 ha introdotto nuove modifiche a WKWebView e SFSafariViewController . Per altre informazioni, vedere la guida Web changes in iOS 11 (Modifiche Web in iOS 11).

WKWebView

WKWebView è stato introdotto in iOS 8 consentendo agli sviluppatori di app di implementare un'interfaccia di esplorazione Web simile a quella di Safari per dispositivi mobili. Ciò è dovuto, in parte, al fatto che usa il motore Javascript Nitro, lo stesso motore usato WKWebView da Safari per dispositivi mobili. WKWebView deve essere sempre usato su UIWebView, laddove possibile, a causa dell'aumento delle prestazioni, dei movimenti descrittivi incorporati e della facilità di interazione tra la pagina Web e l'app.

WKWebView può essere aggiunto all'app in modo quasi identico a UIWebView, ma lo sviluppatore ha un maggiore controllo sull'interfaccia utente/esperienza utente e sulle funzionalità. La creazione e la visualizzazione dell'oggetto visualizzazione Web visualizzano la pagina richiesta, ma è possibile controllare come viene presentata la visualizzazione, come l'utente può spostarsi e come l'utente esce dalla visualizzazione.

Il codice seguente può essere usato per avviare WKWebView un nell'app Xamarin.iOS:

WKWebView webView = new WKWebView(View.Frame, new WKWebViewConfiguration());
View.AddSubview(webView);

var url = new NSUrl("https://docs.microsoft.com");
var request = new NSUrlRequest(url);
webView.LoadRequest(request);

È importante notare che si trova nello spazio dei nomi , quindi sarà necessario aggiungere questa direttiva WKWebViewWebKit using all'inizio della classe.

WKWebView può essere usato anche nelle app Xamarin.Mac ed è consigliabile usarlo se si sta creando un'app Mac/iOS multipiattaforma.

La recipe Gestire gli avvisi JavaScript fornisce anche informazioni sull'uso di WKWebView con JavaScript.

SFSafariViewController

SFSafariViewController è il modo più recente per fornire contenuto Web dall'app ed è disponibile in iOS 9 e versioni successive. A UIWebView differenza di o , è un controller di visualizzazione e pertanto non può essere usato con altre WKWebViewSFSafariViewController visualizzazioni. È necessario presentarsi come un nuovo controller di visualizzazione, nello stesso modo in cui si SFSafariViewController presenterebbe qualsiasi controller di visualizzazione.

SFSafariViewController è essenzialmente un "mini safari" che può essere incorporato nell'app. Analogamente a WKWebView, usa lo stesso motore Javascript Nitro, ma offre anche una gamma di funzionalità aggiuntive di Safari, ad esempio riempimento automatico, lettore e la possibilità di condividere cookie e dati con Safari per dispositivi mobili. L'interazione tra l'utente SFSafariViewController e non è accessibile all'app. L'app non avrà accesso ad alcuna delle funzionalità predefinite di Safari.

Inoltre, per impostazione predefinita, implementa un pulsante Fine, che consente all'utente di tornare facilmente all'app e i pulsanti di spostamento avanti e indietro, consentendo all'utente di spostarsi in una pila di pagine Web. Inoltre, fornisce all'utente una barra degli indirizzi che gli dà la mente di essere nella pagina Web prevista. La barra degli indirizzi non consente all'utente di modificare l'URL.

Queste implementazioni non possono essere modificate, quindi è ideale da usare come browser predefinito se l'app vuole presentare una pagina SFSafariViewController Web senza alcuna personalizzazione.

Il codice seguente può essere usato per avviare SFSafariViewController un nell'app Xamarin.iOS:

var sfViewController = new SFSafariViewController(url);

PresentViewController(sfViewController, true, null);

In questo modo si ottiene la visualizzazione Web seguente:

Visualizzazione Web di esempio con SFSafariViewController

Safari

È anche possibile aprire l'app Safari per dispositivi mobili dall'interno dell'app usando il codice seguente:

var url = new NSUrl("https://docs.microsoft.com");

UIApplication.SharedApplication.OpenUrl(url);

In questo modo si ottiene la visualizzazione Web seguente:

Una pagina Web presentata in Safari

È in genere consigliabile evitare di passare gli utenti dall'app a Safari. La maggior parte degli utenti non si aspetta la navigazione all'esterno dell'applicazione, quindi se si passa dall'app, gli utenti potrebbero non restituirla mai, in sostanza con un impegno insoddibile.

I miglioramenti di iOS 9 consentono all'utente di tornare facilmente all'app tramite un pulsante Indietro disponibile nell'angolo superiore sinistro della pagina safari.

ATS (App Transport Security)

App Transport Security, o ATS, è stato introdotto da Apple in iOS 9 per garantire che tutte le comunicazioni Internet siano conformi alle procedure consigliate per la connessione sicura.

Per altre informazioni su ATS, inclusa la modalità di implementazione nell'app, vedere la guida app Transport Security.

Deprecazione di UIWebView

UIWebView è il modo legacy di Apple di fornire contenuto Web nell'app. È stato rilasciato in iOS 2.0 ed è stato deprecato a data 8.0.

Importante

L'oggetto UIWebView è deprecato. Nuove app'uso di questo controllo non verrà accettato nel App Store a partire da aprile 2020 e gli aggiornamenti delle app che usano questo controllo non verranno accettati entro dicembre 2020.

La documentazione di Apple suggerisce invece che le app devono WKWebView usare .

Se si stanno cercando risorse relative all'avviso di deprecazione (ITMS-90809) durante l'uso di Xamarin.Forms, vedere la documentazione di WebView di UIWebViewUIWebView

Gli sviluppatori che hanno inviato applicazioni iOS negli ultimi sei mesi (circa) potrebbero aver ricevuto un avviso dal App Store, relativo alla UIWebView deprecazione.

Le api deprecate sono comuni. Xamarin.iOS usa attributi personalizzati per segnalare tali API (e suggerire sostituzioni quando disponibili) agli sviluppatori. Ciò che è diverso questa volta e molto meno comune è che la deprecazione verrà applicata dal servizio apple App Store in fase di invio.

Sfortunatamente, la rimozione del tipo UIWebView da è una modifica di Xamarin.iOS.dllUIWebView Questa modifica interromperà le librerie di terze parti esistenti, incluse alcune che potrebbero non essere più supportate o persino ricompilare (ad esempio, l'origine chiusa). Ciò creerà solo problemi aggiuntivi per gli sviluppatori. Di conseguenza, il tipo non viene ancora rimosso.

A partire da Xamarin.iOS 13.16 sono disponibili nuovi strumenti e rilevamento che consentono di eseguire la migrazione da .

Rilevamento

Se di recente è stata inviata un'applicazione iOS ad Apple App Store, ci si potrebbe chiedere se questa situazione si applica alle applicazioni.

Per scoprirlo, è possibile aggiungere agli argomenti --warn-on-type-ref=UIKit.UIWebView--warn-on-type-ref=UIKit.UIWebView In questo modo verrà visualizzato un avviso per qualsiasi riferimento all'oggetto deprecato all'interno dell'applicazione (e a tutte le relative dipendenze). Vengono usati avvisi diversi per segnalare i tipi prima e dopo l'esecuzione del linker gestito.

Gli avvisi, come altri, possono essere trasformati in errori usando -warnaserror: . Ciò può essere utile se si vuole assicurarsi che una nuova dipendenza a UIWebView non sia stata aggiunta dopo le verifiche. Ad esempio:

  • -warnaserror:1502 segnala errori se vengono trovati riferimenti negli assembly pre-collegati.
  • -warnaserror:1503 segnala errori se vengono trovati riferimenti negli assembly post-collegati.

È anche possibile disattivare gli avvisi se i risultati di pre/post-collegamento non sono utili. Ad esempio:

  • -nowarn:1502 non -nowarn:1502 avvisi se vengono trovati riferimenti negli assembly pre-collegati.
  • -nowarn:1503 non -nowarn:1503 avvisi se vengono trovati riferimenti negli assembly post-collegati.

Rimozione

Ogni applicazione è univoca. La rimozione UIWebView dall'applicazione può richiedere passaggi diversi a seconda di come e dove viene usata. Gli scenari più comuni sono i seguenti:

  • Non è possibile usare UIWebView all'interno dell'applicazione. Tutto è a posto. Non dovrebbero essere visualizzati avvisi durante l'invio all'AppStore. Non sono necessarie altre informazioni.
  • Utilizzo diretto di UIWebView da parte dell'applicazione. Per iniziare, rimuovere l'uso di , ad esempio sostituirlo con i tipi più nuovi UIWebViewWKWebView (iOS 8) o SFSafariViewController (iOS 9). Al termine, il linker gestito non dovrebbe visualizzare alcun riferimento a e il file binario dell'app finale non avrà UIWebView alcuna traccia.
  • Utilizzo indiretto. UIWebView può essere presente in alcune librerie di terze parti, gestite o native usate dall'applicazione. Per iniziare, aggiornare le dipendenze esterne alle versioni più recenti perché questa situazione potrebbe essere già stata risolta in una versione più recente. In caso contrario, contattare il sistema di manutenzione delle librerie e chiedere informazioni sui piani di aggiornamento.

In alternativa, è possibile provare gli approcci seguenti:

  1. Se si usa Xamarin.Forms,leggere questo post di blog.
  2. Abilitare il linker gestito (nell'intero progetto o, almeno, nella dipendenza che usa ) in modo che possa essere rimosso, se non UIWebView vi si fa riferimento. UIWebView Questo risolverà il problema, ma potrebbe richiedere lavoro aggiuntivo per rendere il codice sicuro dal linker.
  3. Se non è possibile modificare le impostazioni del linker gestito, vedere i casi speciali seguenti.

Le applicazioni non possono usare il linker (o modificarne le impostazioni)

Se per qualche motivo non si usa il linker gestito (ad esempio, Non collegare ), il simbolo rimarrà nell'appbinaria che viene inviato ad Apple e potrebbe essere rifiutato.

Una soluzione efficace consiste nell'aggiungere agli argomenti aggiuntivi di mtouch del progetto. In questo modo le tracce di UIWebView verranno rimosso dall'applicazione. Tuttavia, qualsiasi codice che fa riferimento al tipo non funzionerà correttamente (si prevedono eccezioni o arresti anomali). Questo approccio deve essere usato solo se si è certi che il codice non sia raggiungibile in fase di esecuzione (anche se era raggiungibile tramite analisi statica).

Supporto per iOS 7.x (o versioni precedenti)

UIWebView fa parte di iOS dalla versione 2.0. Le sostituzioni più comuni WKWebView sono (iOS 8) e SFSafariViewController (iOS 9). Se l'applicazione supporta ancora versioni precedenti di iOS, è consigliabile prendere in considerazione le opzioni seguenti:

  • Impostare iOS 8 come versione di destinazione minima (una decisione in fase di compilazione).
  • Usare solo WKWebView se l'app è in esecuzione in iOS 8+ (decisione di runtime).

Applicazioni non inviate ad Apple

Se l'applicazione non viene inviata ad Apple, è consigliabile passare dall'API deprecata perché può essere rimossa nelle versioni future di iOS. Tuttavia, è possibile eseguire questa transizione usando un orario personalizzato.