"ShouldOverrideUrlLoading" est-il vraiment obsolète? Si oui, que puis-je utiliser à la place?
Il semble que le ciblage d'Android NshouldOverrideUrlLoading
soit obsolète et que je dois faire fonctionner une application depuis l'API 19 jusqu'à la dernière en ce moment qui est Android N (bêta), j'utilise certaines fonctionnalités qui sont nouvelles dans Android N (comme l'économiseur de données), donc le ciblage Marshmallow n'aidera pas à résoudre le problème car je dois utiliser ces nouvelles fonctionnalités, voici la partie du code que j'utilise:
public boolean shouldOverrideUrlLoading(WebView webview, String url) {
if (url.startsWith("http:") || url.startsWith("https:")) {
...
} else if (url.startsWith("sms:")) {
...
}
...
}
Et voici le message que m'a donné Android Studio:
Remplace la méthode obsolète dans «android.webkit.WebViewClient» Cette inspection signale où du code obsolète est utilisé dans la portée d'inspection spécifiée.
Google ne dit rien de cette dépréciation .
Je me demande si l'utilisation @SuppressWarnings("deprecation")
me permettra de travailler sur tous les appareils depuis l'API 19 jusqu'à la dernière version d'Android N Beta (et sa version finale lors de sa sortie), je ne peux pas le tester moi-même, je ne l'ai jamais utilisé et je dois être sûr que cela fonctionne, alors, tout le monde peut le dire?
Réponses:
Non, ça ne l'est pas.
Celui qui est nouveau dans N Developer Preview a cette signature de méthode:
Celui qui est pris en charge par toutes les versions d'Android, y compris N, a cette signature de méthode:
Remplacez celui qui est obsolète, celui qui prend a
String
comme deuxième paramètre.la source
String
. Par exemple, cet exemple d'application , compilé avec le niveau d'API 19, fonctionne correctement, comme sur un Nexus 5 sous Android 6.0String
comme deuxième paramètre. Par exemple, l'exemple d'application que j'ai lié à, qui remplace le rappel obsolète, fonctionne bien sur un Nexus 6 exécutant le N Developer Preview 1.getUrl()
car la nouvelle méthode ne sera appelée que pour 24+Documenter en détail pour les futurs lecteurs:
La réponse courte est que vous devez remplacer les deux méthodes. La
shouldOverrideUrlLoading(WebView view, String url)
méthode est obsolète dans l'API 24 et lashouldOverrideUrlLoading(WebView view, WebResourceRequest request)
méthode est ajoutée dans l'API 24. Si vous ciblez des versions plus anciennes d'Android, vous avez besoin de l'ancienne méthode, et si vous ciblez 24 (ou une version ultérieure, si quelqu'un le lit dans un avenir lointain) il est également conseillé de remplacer cette dernière méthode.Ce qui suit est le squelette sur la façon dont vous pourriez accomplir cela:
Tout comme
shouldOverrideUrlLoading
, vous pouvez proposer une approche similaire pour lashouldInterceptRequest
méthode.la source
@RequiresApi
à la place de @TargetApi ici pour une utilisation futureshouldInterceptRequest
, est que sur les appareils Android N +, elles sont toutes les deux appelées et vous gérerez chaque uri deux fois! Pour remédier à cela, j'ai ajouté uneBuild.VERSION.SDK_INT < Build.VERSION_CODES.N
condition dans la version obsolète.super. shouldOverrideUrlLoading(view,request)
la méthode non obsolète, alors oui, la méthode non obsolète et la méthode obsolète seront invoquées. Cela est dû au fait que l'implémentation par défaut de la méthode non obsolète consiste à appeler en interne la méthode obsolète. Jetez un œil auWebViewClient.shouldOverrideUrlLoading(WebView view, WebResourceRequest request)
. Assurez-vous donc de ne pas appelersuper.shouldOverrideUrlLoading()
.Utilisation
la source
Implémentez les méthodes obsolètes et non obsolètes comme ci-dessous. Le premier consiste à gérer le niveau d'API 21 et plus, le second est inférieur au niveau d'API 21
la source
Uri.parse
etparseUri
. Les nouvelles réponses devraient ajouter de nouvelles informations utiles et de nouvelles perspectives sur le sujet.