前言
上一篇文章我们讲了okhttp的cookiejar和webview的使用的android cookieManager。这个设计确实不好,为啥三方库就不能基于系统进行扩展呢?
我的分析如下:首先okhttp并不只适用于android开发,java web开发在跨应用也有大量的使用常景。而内置与android.jar包下面的CookieManager跟android系统结合的特殊性,使得okhttp有自己的一套cookie运行,与cookie的本质和机制是差不多的。
问题描述
现实生活我们总能遇到奇奇怪怪,形形色色的需求。最近我就遇到了一个关于pdf的需求,android确实不太友好,webview也没有ios的webview那么功能丰富。绝大多数时候,我们只能通过一点一点的扩展。今天我便遇到了一个大坑!
我们有一个业务场景是接入老旧的OA系统,里面有一个页面上面有pdf等文档文件。要知道android内置的webview根本没有chrome那么强大,所以很多时候在pc上玩的六的东西,到手机全都翘辫子了!哈哈
所以我不得不开发一个pdf的插件来满足这个业务场景。
一开始我把pdf插件规划为以下几步!
1.webview拦截url,校验文件是文档类型,
2.根据url开始执行下载,保存到本地
3.使用地方放pdf查看库进行pdf加载
在不断的试错中,慢慢的把它们细分如下
1.webview拦截url,校验文件是文档类型,
public boolean shouldOverrideUrlLoading(WebView view, WebResourceRequest request) {
String url = String.valueOf(request.getUrl());
if (url.isEmpty()) {
return true;
}
if (!url.startsWith("http") && !url.startsWith("HTTP")) {
return true;
}
if(url.toLowerCase().endsWith(".pdf")){
return true;
}
view.loadUrl(url);
return true;
}
2.区分pdf和wps等文件
public static String getMIMETypeStr(String end) {
String type;
if (end.equals("pdf")) {
type = "application/pdf";
} else if (end.equals("m4a") || end.equals("mp3") || end.equals("mid") ||
end.equals("xmf") || end.equals("ogg") || end.equals(