Visualizzazioni Web in Xamarin.iOS

  • Articolo

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

iOS 11 ha introdotto nuove modifiche sia a che SFSafariViewControllera WKWebView . Per altre informazioni su questi elementi, vedere la guida alle 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. Questo è dovuto, in parte, al fatto che WKWebView usa il motore Nitro Javascript, lo stesso motore usato da Safari mobile. WKWebView deve essere sempre usato su UIWebView, se possibile a causa di prestazioni migliorate, movimenti intuitivi predefiniti e facilità di interazione tra la pagina Web e l'app.

WKWebView può essere aggiunto all'app in modo quasi identico a UIWebView, tuttavia lo sviluppatore ha molto più controllo sull'interfaccia utente/esperienza utente e funzionalità. La creazione e la visualizzazione dell'oggetto visualizzazione Web visualizzeranno 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 un oggetto WKWebView nell'app Xamarin.iOS:

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

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

È importante notare che WKWebView si trova nello spazio dei WebKit nomi, quindi è necessario aggiungere questa direttiva 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 ricetta 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 differenza di UIWebView o WKWebView, SFSafariViewController è un controller di visualizzazione e quindi non può essere usato con altre visualizzazioni. Dovrebbe essere presente SFSafariViewController come nuovo controller di visualizzazione, nello stesso modo in cui si presenterebbe qualsiasi controller di visualizzazione.

SFSafariViewController è essenzialmente un "mini safari" che può essere incorporato nella tua app. Come WKWebView usa lo stesso motore Nitro Javascript, 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 mobile. L'interazione tra l'utente e l'oggetto SFSafariViewController 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 di inoltrare e indietro i pulsanti di spostamento, consentendo all'utente di spostarsi attraverso uno stack di pagine Web. Inoltre, fornisce all'utente una barra degli indirizzi che dà loro la tranquillità 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 SFSafariViewController è ideale da usare come browser predefinito se l'app vuole presentare una pagina Web senza alcuna personalizzazione.

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

var sfViewController = new SFSafariViewController(url);

PresentViewController(sfViewController, true, null);

In questo modo viene visualizzata la visualizzazione Web seguente:

An example web view with SFSafariViewController

Safari

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

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

UIApplication.SharedApplication.OpenUrl(url);

In questo modo viene visualizzata la visualizzazione Web seguente:

A web page presented in Safari

Lo spostamento degli utenti dall'app a Safari dovrebbe in genere essere sempre evitato. La maggior parte degli utenti non prevede la navigazione all'esterno dell'applicazione, quindi se si esce dall'app, gli utenti potrebbero non restituirlo, essenzialmente uccidendo l'engagement.

I miglioramenti di iOS 9 consentono all'utente di tornare facilmente all'app tramite un pulsante Indietro fornito 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, tra cui come implementarlo nell'app, vedere la Guida alla sicurezza del trasporto app.

Deprecazione di UIWebView

UIWebView è il modo legacy di Apple di fornire contenuti Web nell'app. È stato rilasciato in iOS 2.0 ed è stato deprecato a partire dalla versione 8.0.

Importante

UIWebView è stato deprecato. Le nuove app che usano questo controllo non verranno accettate nell'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 UIWebView Apple suggerisce invece che le app devono usareWKWebView.

Per le risorse relative all'avviso di deprecazione (ITMS-90809) durante l'uso UIWebView di Xamarin.Forms, vedere la documentazione di WebView di Xamarin.Forms.

Gli sviluppatori che hanno inviato applicazioni iOS negli ultimi sei mesi (o così via) potrebbero aver ricevuto un avviso dall'App Store, in merito UIWebView alla deprecazione.

Le deprecazioni delle API 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 dall'App Store di Apple in fase di invio.

Purtroppo, la rimozione del UIWebView tipo da Xamarin.iOS.dll è una modifica binaria che causa un'interruzione. Questa modifica interromperà le librerie di terze parti esistenti, incluse alcune che potrebbero non essere più supportate o anche ricompilabili (ad esempio, origine chiusa). Ciò creerà solo problemi aggiuntivi per gli sviluppatori. Pertanto, non viene ancora rimosso il tipo.

A partire da Xamarin.iOS 13.16 sono disponibili nuovi strumenti e rilevamento per facilitare la migrazione da UIWebView.

Rilevamento

Se di recente hai inviato un'applicazione iOS all'App Store di Apple, potresti chiederti se questa situazione si applica alle tue applicazioni.

Per scoprirlo, è possibile aggiungere --warn-on-type-ref=UIKit.UIWebView agli argomenti mtouch aggiuntivi del progetto. Verrà visualizzato un avviso relativo a qualsiasi riferimento all'oggetto deprecato UIWebView 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 gli altri, possono essere trasformati in errori usando -warnaserror:. Ciò può essere utile se si vuole assicurarsi che una nuova dipendenza a UIWebView non venga 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 del collegamento preliminare/post non sono utili. Ad esempio:

  • -nowarn:1502non segnalerà avvisi se vengono trovati riferimenti negli assembly pre-collegati.
  • -nowarn:1503non segnalerà 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 usato. Gli scenari più comuni sono i seguenti:

  • Non esiste alcun uso all'interno dell'applicazione UIWebView . Tutto va bene. Non devono essere visualizzati avvisi durante l'invio all'AppStore. Niente altro è necessario per te.
  • Utilizzo diretto dell'applicazione UIWebView . Per iniziare, rimuovere l'uso di UIWebView, ad esempio, sostituirlo con i tipi più recenti WKWebView (iOS 8) o SFSafariViewController (iOS 9). Una volta completato, il linker gestito non dovrebbe vedere alcun riferimento a UIWebView e il file binario dell'app finale non ne avrà 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à risolta in una versione più recente. In caso contrario, contattare i gestori 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 usando UIWebView) in modo che venga rimosso, se non viene fatto riferimento. Questo risolverà il problema, ma potrebbe richiedere ulteriori operazioni per rendere sicuro il linker del codice.
  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, Don't link), il UIWebView simbolo rimarrà nell'app binaria che si invia ad Apple e potrebbe essere rifiutato.

Una soluzione forzata consiste nell'aggiungere --optimize=force-rejected-types-removal agli argomenti mtouch aggiuntivi del progetto. In questo modo verranno rimosse le tracce dell'applicazione UIWebView . Tuttavia, qualsiasi codice che fa riferimento al tipo non funzionerà correttamente (si aspettano 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 è raggiungibile tramite l'analisi statica).

Supporto per iOS 7.x (o versioni precedenti)

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

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

Applicazioni non inviate ad Apple

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