【Android】WebView:onReceiveError的应用与变迁

onReceiveError是WebViewClient提供的方法,用于网页产生错误时进行回调处理。

1. 旧版的onReceiveError

在API23之前,该方法的签名是:

public void onReceivedError(WebView view, int errorCode,String description, String failingUrl);

文档是:

Report an error to the host application. These errors are unrecoverable (i.e. the main resource is unavailable). The errorCode parameter corresponds to one of the ERROR_* constants.

简单来说,onReceivedError只有在遇到不可用的(unrecoverable)错误时,才会被调用)。
比如,当WebView加载链接www.barryzhang.com时,"不可用"的情况有可以包括有:

而下面的情况则不会被报告:

  • 网页内引用其他资源加载错误,比如图片、css不可用
  • js执行错误

2. 应用:显示个自定义ERROR界面

基于以上特性,所以它可以用来处理网页加载不出来的情况,比如显示一段友好的提示语、一个重试按钮等。
比如像这样:

@Override
public void onReceivedError(WebView view, int errorCode, String description, String failingUrl) {
    super.onReceivedError(view, errorCode, description, failingUrl);
    layoutError.setVisibility(View.VISIBLE); 
    textViewErrorMessage.setText("(错误码:" + errorCode + "  " + description + ")"  );
}

——这么做的还有一个原因是,虽然默认的网页错误样式每个ROM都可能不一样,但是却是一样的丑……,来个对比图感受一下,从左到右依次是:MIUI(Android5.0.2)、Nexus5X(Android7)、以及自定义之后的效果:

对比图

3. 新版的onReceiveError

So far so good, but~
API23(Android6),Google对onReceiveError进行了一次改版重载,并且把老版本的废弃了,ㄒoㄒ~~
签名改成了这样:

public void onReceivedError(WebView view, WebResourceRequest request, WebResourceError error);

文档改成了:

Report web resource loading error to the host application. These errors usually indicate inability to connect to the server. Note that unlike the deprecated version of the callback,the new version will be called for any resource (iframe, image, etc), not just for the main page. Thus, it is recommended to perform minimum required work in this callback.

新版的onReceiveError能接收到的错误更多,不再局限于之前的"不可用"的情况——好像是比之前更强大了。
但是,这时候如果我们依然用使用旧版本的方式来使用新版,像这样:

@Override
public void onReceivedError(WebView view, WebResourceRequest request, WebResourceError error) {
    // !!在新版的onReceivedError中,沿用之前的处理逻辑(这是错误的示例!!)
    super.onReceivedError(view, errorCode, description, failingUrl);
    layoutError.setVisibility(View.VISIBLE); 
    textViewErrorMessage.setText("(错误码:" + error.getErrorCode() + "  " + error.getDescription().toString() + ")"  );
}

这会导致的问题是:在Android6以上的机器上,网页中的任意一个资源获取不到(比如字体),网页就很可能显示自定义的错误界面。尤其是如果Html用了本地化技术,'ERR_FILE_NOT_FOUND'开始变得特别常见。

4. 如何像在老版本一样工作?

4.1 继续用老版本呢?

Bingo!可以,起码从目前来看,测试结果表明至少在Andoid6以及Android7上是可以工作的。
然而,终究,使用已废弃的API终究是不太优雅——说不定哪个版本就突然不能用了,仿佛像个定时炸弹一样。

4.2 isForMainFrame

我们注意到新版的onReceivedError跟老版相比,多了一个WebResourceRequest参数,而WebResourceRequest有一个方法叫做isForMainFrame,描述为:

Gets whether the request was made for the main frame
获取当前的网络请求是否是为main frame创建的.

加上这个条件判断是来试试?

    @Override
    public void onReceivedError(WebView view, WebResourceRequest request, WebResourceError error) {
        super.onReceivedError(view, errorCode, description, failingUrl);
        if(request.isForMainFrame()){// 在这里加上个判断
            // 显示错误界面
        }
    }

实验证明这个方法是有效的。

4.3 当然,也还有其他方法

可以这样,直接上代码:

@Override
public void onReceivedError(WebView view, WebResourceRequest request, WebResourceError error) {
    super.onReceivedError(view, errorCode, description, failingUrl);
     if (request.getUrl().toString() .equals(getUrl())) {// 在这里加上个判断
        // 显示错误界面
    }
}

原理是:用请求的url来判断,如果出错的url跟webView当前加载的url一致,就显示错误页面。
↑↑经测试,也能通过~

总结

总而言之,最终的代码这样写,可以同时兼容新旧版本:

    // 旧版本,会在新版本中也可能被调用,所以加上一个判断,防止重复显示
    @Override
    public void onReceivedError(WebView view, int errorCode, String description, String failingUrl) {
        super.onReceivedError(view, errorCode, description, failingUrl);
        if(Build.VERSION.SDK_INT >= Build.VERSION_CODES.M){
            return;
        }   
        // 在这里显示自定义错误页
    }

    // 新版本,只会在Android6及以上调用
    @TargetApi(Build.VERSION_CODES.M)
    @Override
    public void onReceivedError(WebView view, WebResourceRequest request, WebResourceError error) { 
        super.onReceivedError(view, request, error);
        if (request.isForMainFrame()){ // 或者: if(request.getUrl().toString() .equals(getUrl()))
            // 在这里显示自定义错误页
        }
    }

Also in:
http://www.barryzhang.com/
https://barryhappy.github.io/

最后编辑于
©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 203,547评论 6 477
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 85,399评论 2 381
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 150,428评论 0 337
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 54,599评论 1 274
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 63,612评论 5 365
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 48,577评论 1 281
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 37,941评论 3 395
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 36,603评论 0 258
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 40,852评论 1 297
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 35,605评论 2 321
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 37,693评论 1 329
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 33,375评论 4 318
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 38,955评论 3 307
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 29,936评论 0 19
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 31,172评论 1 259
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 43,970评论 2 349
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 42,414评论 2 342

推荐阅读更多精彩内容

  • Spring Cloud为开发人员提供了快速构建分布式系统中一些常见模式的工具(例如配置管理,服务发现,断路器,智...
    卡卡罗2017阅读 134,585评论 18 139
  • Android 自定义View的各种姿势1 Activity的显示之ViewRootImpl详解 Activity...
    passiontim阅读 171,400评论 25 707
  • Spring Boot 参考指南 介绍 转载自:https://www.gitbook.com/book/qbgb...
    毛宇鹏阅读 46,724评论 6 342
  • 作一首诗,难以提字。 说为情意,难以开口。 七情六欲,都是浮云。(试练) 至古到今,都是炼狱。(他笑)
    小叶童阅读 270评论 0 0
  • 时隔14年,王菲和谢霆锋的锋菲恋终于画上了圆满的句号。很多网友都在感慨:虽然几度沉浮,虽然年过40,但王菲风采依旧...
    戒咖啡cxj阅读 384评论 0 0