Навигацијата што зависи од препишување на прокси во WebView треба да започне откако ќе се изврши слушателот за завршување на препишувањето. Неговото поставување и веднаш вчитување страница ја остава операцијата во трка со асинхроно ажурирање.

  1. Проверете WebViewFeature.isFeatureSupported(WebViewFeature.PROXY_OVERRIDE). Поддршката зависи од имплементацијата на WebView и библиотеката AndroidX WebKit, како и од нивото на API на Android. Дефинирајте што се случува кога го нема; тивкото директно поврзување може да ја обезмисли функцијата.
  2. Изградете го саканиот ProxyConfig со неговите документирани прокси правила, синтакса на крајна точка и однесување при заобиколување. За дозволена навигација до јавни страници, изберете кандидат од списокот со бесплатни прокси чиј протокол се совпаѓа со правило што го поддржува таа имплементација на WebView. PAC URL, SOCKS URI и гол хост се различни влезови.
  3. Повикајте ProxyController.setProxyOverride() со таа конфигурација, извршител и слушател за завршување. Започнете ја зависната навигација од патеката за завршување.
  4. Кога привременото препишување завршува, избришете го со clearProxyOverride() и обработете го и неговото асинхроно завршување.

Дајте му на овој животен циклус еден сопственик. Поставката се применува на WebView во целиот процес на апликацијата; повторливото менување не може да им даде на два истовремени прикази независни излези. Другите процеси и HTTP библиотеки имаат свои маршрути.

Овој поддржан интерфејс избегнува зависност од приватни слушатели за промена на прокси што се разликуваат меѓу изданијата на Android. Тој избира маршрутирање; прокси-акредитивите и довербата во сертификати сè уште ги користат своите поддржани механизми. Неуспехот при автентикација или TLS по изборот треба да се дијагностицира во таа фаза.

Поврзани статии