Ang pag-navigate na umaasa sa proxy override ng WebView ay dapat magsimula pagkatapos tumakbo ang completion listener ng override. Ang pagtatakda nito at agad na pag-load ng pahina ay nag-iiwan sa operasyon na nakikipagkarera sa isang asynchronous na pag-update.

  1. Tingnan ang WebViewFeature.isFeatureSupported(WebViewFeature.PROXY_OVERRIDE). Ang suporta ay nakasalalay sa implementasyon ng WebView at sa AndroidX WebKit library gayundin sa antas ng API ng Android. Tukuyin kung ano ang mangyayari kapag wala ito; ang tahimik na direktang pag-connect ay maaaring makasira sa feature.
  2. Buuin ang nilalayong ProxyConfig gamit ang mga dokumentadong panuntunan ng proxy, syntax ng endpoint at pag-uugali ng bypass. Para sa pinahihintulutang pag-navigate sa mga pampublikong site, pumili ng kandidato mula sa listahan ng libreng proxy na ang protocol ay tumutugma sa isang panuntunang sinusuportahan ng implementasyong iyon ng WebView. Ang PAC URL, SOCKS URI at hubad na host ay magkaibang input.
  3. Tawagin ang ProxyController.setProxyOverride() gamit ang configuration na iyon, isang executor at isang completion listener. Simulan ang nakadependeng pag-navigate mula sa landas ng completion.
  4. Kapag natapos ang pansamantalang override, i-clear ito gamit ang clearProxyOverride() at pangasiwaan din ang asynchronous na completion nito.

Bigyan ang lifecycle na iyon ng isang may-ari. Nalalapat ang setting sa mga WebView sa buong proseso ng application; ang paulit-ulit na pagbabago nito ay hindi makapagbibigay ng independiyenteng labasan sa dalawang sabay na view. Ang ibang proseso at HTTP library ay may kani-kanilang ruta.

Iniiwasan ng sinusuportahang interface na ito ang pag-asa sa mga pribadong proxy-change listener na nag-iiba sa pagitan ng mga release ng Android. Pinipili nito ang routing; gumagamit pa rin ang proxy credentials at certificate trust ng kanilang mga sinusuportahang mekanismo. Ang pagkabigo sa authentication o TLS pagkatapos ng pagpili ay kailangang ma-diagnose sa yugtong iyon.

Kaugnay na mga artikulo