升級Mobile First 8 及 WKWebView問題條列與排除方法
前言
開發銀行專案常常會使用許多框架,在App方面多數銀行會採用 IBM 的 MobileFirst 開發(舊名 Worklight),而在MobileFirst 7.x版本升級到8.0時,棄用了MobileFirst原本的架構,改成一個Cordova Plugin,並依附在Cordova下面處理App初始化、與原生溝通等事情,原本的專案架構必須改為Cordova的專案架構,這有可能會導致許多問題,再加上同時將UIWebView換成WKWebView,也會遇到不少問題,這篇文章會描述我遇到的問題,供大家參考
MobileFirst
原本MobileFirst 7的檔案結構會分成common, android, iphone等平台的資料夾,裡面會放置各自的檔案。MobileFirst 8 改成 Cordova專案,所有操作都是照著Cordova的流程去使用,比如說修改web後,需要先執行cordova prepare,才能build到實體機上面。而MobileFirst 的指令改成command line執行,可以使用node安裝mfp-cli來執行app preview等相關功能。
♦. 不要使用 MobileFirst 協助工具
升級的第一步通常會不知道如何開始,上網稍微找一下會發現IBM有出一個轉換的協助工具,可以將MobileFirst 7 無痛換成 MobileFirst 8,或許很小的專案可以這樣置換,但是他的轉換並不完全,native的code要自己搬,專案內的設定檔運行起來會有很多錯誤。
這裡建議可以自己新增一個Cordova專案,新增Android & iOS的平台,再將www、Android、iOS的檔案丟到對應的位置,之後先參考加入cordova-plugin-mfp的方法 一步步更換檔案目錄或檔案內容,接著照著升級cordova-plugin-mfp的步驟來修改web資源,最後檢查雙平台的startup flow是否需要修改。
♦ Web注意事項
只要按照連結修改即可,WLJQ是MobileFirst 7的用法,記得一定要拿掉,也一定要將載入cordova.js的<script>放在載入js檔案之前
♦ Android注意事項
1. 會有數個資源可能會重複,比如說 mfp-strings.xml 及 splash.9.png,都是新增cordova-plugin-mfp時會自動新增進去的,若有出現錯誤可以檢查這幾 個檔案是否重複
2. 升級過後似乎必須使用AndroidX,若有使用android.support可以透過Android Studio轉換,不然會編譯失敗
3. 若有使用firebase analytics,並且開發環境因為客戶無法連接上外部網路時,有可能會遇到Android手機剛啟動app空白很久才進入起始頁,這個情況會因為手機關閉Wifi而消失,因為MobileFirst 8似乎有修改啟動app的流程,導致firebase會在app啟動時去嘗試連接,若有網路卻連接不到,就會等到逾時才會啟動app,可以嘗試著在程式裡判斷開發環境,連接不上外部網路就不要初始化firebase
♦ iOS注意事項
1. 如果你原本的專案有加入apple watch的功能,在升級成MobileFirst 8後,有可能會有編譯錯誤,推測是因為使用cordova專案,在執行cordova prepare指令時,iOS專案檔會抓成watch的,導致新增的cordova plugin依附在watch專案而編譯失敗,目前還沒有確定的解法,但網路上有找到一個cordova plugin跟watch有關,或許可以試試看
2. MobileFirst 7的CDVViewController是在AppDelegate的rootViewController的第一個child,MobileFirst 8改為rootViewController就是CDVViewController本身
♦ native plugin注意事項
如果你原本的專案原本有存在自己撰寫的cordova plugin,並且自行在各自的config.xml加入Class Name的對應,在升級MobileFirst 8時會遇到執行完cordova prepare之後,config.xml會被自動覆蓋掉,沒有辦法呼叫到自定義的plugin。比較正統的解決辦法,就是根據cordova官方文件定義的格式,把自定義的cordova plugin包裝起來,再使用cordova plugin add的語法加入專案內。而因為我遇到的專案規模比較大,一個個將plugin包裝起來太花時間了,所以我新增一個空的cordova plugin,裡面沒有native code,只有將我至今所有的設定檔都加在plugin.xml內,之後將他加進專案內,也可以成功使用之前寫的plugin
WKWebView
蘋果官方有發出聲明,之後使用UIWebView開發的app將不會審過,而改用WKWebView會遇到數個問題如下
♦ WKWebView的安全性做的更嚴謹,所以使用Web的XMLHttpRequest會遇到權限不夠而失敗,必須使用cordova-plugin-wkwebviewxhrfix這個plugin才能解決,另外經過交叉測試,有另一個cordova-plugin-wkwebview-xhr-fix的plugin不能使用,無法解決此問題,甚至會干擾wkwebviewxhrfix的執行
♦ 會無法使用ajax來跟後端做溝通,需要使用cordova-plugin-http來發送請求,而根據前後端約定參數格式,我遇到問題的順序是:
1. 若原本使用json來溝通,會因為使用AFHTTPRequestSerializer造成後端無法解析,所以修改plugin內的程式,把requestSerializer從原本的換成AFJSONRequestSerializer,才成功與後端串接成功
2. 而AFJSONRequestSerializer也遇到了另一個問題,在使用浮點數傳送時,後端會收到某些無法精確表示的浮點數,而有0.000000001的偏差,經過一番研究,才將requestSerializer改回AFHTTPRequestSerializer,並呼叫 setQueryStringSerializationWithBlock,將其參數的組法改成直接把NSDictionary轉字串,才沒有遇到其他問題
♦ 因為WKWebView對記憶體的控管比較嚴格,如果web使用的資源過多,在即將變成白畫面之前會重新整理頁面,在設計web的架構需要考慮被強制重整的情況
♦ WKWebView禁止了不經過使用者操作自動跳出鍵盤的行為,比方說在某個api完成後將鍵盤跳出,而在最新的cordova-plugin-wkwebview-engine已經有修復的程式,若無法避免這樣的設計,也無法更新到最新的版本,可以參考這裏
♦ UIWebView與WKWebView存放localStorage的地方不同,如果有重要資料還是建議存放在NSUserDefaults,若資料難以轉存,可以參考這個plugin
♦ iOS有個方便的功能,就是可以自動擷取簡訊內的驗證碼,並且一鍵填入,但是web畫面上的input如果沒有鎖定長度,有可能會觸發兩次填入,比如說驗證碼是1234,點擊填入1234,畫面上卻出現12341234,導致驗證碼錯誤,這只要鎖定輸入框的長度就可以解決,但是如果驗證碼每次的長度不一定,無法固定鎖定某個長度,可以監聽input事件,並判斷event內的inputType,來做鎖定長度的動作
♦ WKWebView與UIWebView對於iPhoneX、iPhone11這種有下巴的畫面呈現有些許不同,若app有footer而沒有考慮這點,有可能會有footer與iPhoneX底部重疊的問題,這可以朝著WKWebView的inset這個方向去動態切換高度
結語
更新框架版本是開發任何產品都會遇到的問題,遇到像MobileFirst這種從資料架構到使用方法大幅度改變的框架,一定會花費更多的心力與時間,這部分也是app開發初期決定框架的時候,必須考慮進去的事情,不然等到專案規模大到一個程度,就不是這麼容易調整的,希望大家在規劃專案的方向都可以考慮的更完善!