12月的前兩週
仍然在跟新的App奮戰
雖然換成語法簡潔的kotlin
不過Android有時候還是會「起乩」
Debug的時間仍然少不了
像是Websocket的套件
會把所有在接受訊息過程中
發生的例外Try Catch
並忽略例外之後的程式碼
被這個坑了好幾次
遇到時總是要逐行執行
才會知道是錯誤源頭在哪裡
另外一個有關套件的問題
就是mpchart一直閃退
這次專案必須處理即時K棒資料
兩筆資料進來的間隔時間
最短可能僅有數十毫秒
如果執行緒處理得不好
往往就是爆出索引超出陣列的例外
最後的解決辦法
還是祭出大絕招
有關chart圖的方法
全部run on UIThread
才讓程式比較穩定
當程式可以穩定不閃退後
又出現新麻煩
就是兩個平台的App
計算出來的數據不一樣
這就牽涉到當初的架構規劃
一開始我們擔心高頻的資料傳遞
加上繁複的運算工作
會造成server延遲的狀況
所以把大部分計算交由client
因此同一套邏輯
Android和iOS必須要各寫一次
理論上照著PM給的文件
應該要算得一樣
但往往總是這邊少1那邊多2
甚至和電腦版不一樣
一份數據三種結果
後來和公司後端主管討論
認為這樣不好維護
因為萬一計算邏輯有錯
照我們目前的架構
客戶必須要更新App
也就是要再經過上架、審查的流程
相反的
如果把計算邏輯寫在Server
手機端純粹顯示資料
維護時就只要改一份code
Client端也不要重新安裝程式
痛定思痛後
花了將近三天的時間
就把計算全部交給Server端算好後
再經由websocket直接傳給手機
一勞永逸解決算不準的問題
(感謝負責寫後端的黃逵~)
投資老師的App告一個段落後
由第二屆戰鬥營學員組成的「四人小組」
也到了解散的時候
主管Stan將我們四人
併回公司的手機大組
並且各和一位前輩搭配
以兩人為單位
共同開發和維護App
我被分配到iOS
正式和Android說再見
不過我這組負責的專案
大部分是用Xamarin寫的
第一次碰非原生語言
多少有點緊張
好險Xamarin的iOS
就是看起來很像Swift的C#
舉凡AppDelegate viewController等物件
命名方式都一模一樣
C#又算是我的母語(?)
可以算是無痛上手
時間主要是花在是了解程式邏輯
這也是我第一次接別人的程式碼
終於體驗到coding style的好處與重要性
有了共通的寫作規定
就算是是不同人寫的code
專案的程式碼仍保有一致性
閱讀起來也比較容易理解
相比我們自己寫的專案
其他支App都使用到大量的委派
雖然學了好久
這一段還是覺得很陌生QQ
找資料找半天
最後看到比較好的濃縮結論:
委派就是類別
方法就是委派的實體
而C#提供的泛型委派類別
就是Action
簡單來說就有點像List
我們不會一個物件的List就宣告一種型別
而是單純用List<T>來表示
Action也是同樣道理
不用再額外定義委派的類別
除了Xamarin
也有接到用objective C的案子
這個專案比較特殊
是別人外包給我們維護
加上架構又很大
一打開檔案真的是頭昏眼花
(一個CS檔6000多行，能不眼冒金星?)
面臨到傳說中的恐怖的OC
第一步還是熟悉語法
中括號執行function
+-號代表類別方法或實體方法
屬性的宣告方式等等
跟之前的碰過的語言差異頗大
其實在了解語法規則之後
感覺OC沒有想像中恐怖
但可以更深刻理解
為什麼Swift會被開發出來
(OC連索引為負數都檢查不出來...)
拉哩拉雜說了這麼多
還是要說原生的溫暖阿
一種語言寫雙平台聽起來很好像酷
但在找資料的時候
就會發現Xamarin的資源真的少了很多
在stack overflow的問題集
感覺只有OC 或是Swift的十分之一
即使Xamarine也有問題論壇
但是討論量依舊沒有原生來的多
另外一個遇到問題的就是
google play回報閃退的問題時
由於不是原生
無法顯示在哪個Activity閃退
造成除錯上的困難
另外一個遇到問題的就是
google play回報閃退的問題時
由於不是原生
無法顯示在哪個Activity閃退
造成除錯上的困難
未來傾向把Xamarin的專案
用kotlin和swift重寫一遍
結論就是現階段
非原生依舊弊大於利
省的時間大概三分之一
遇到問題卻要付出加倍
甚至更多的心力去處理
併組的這兩週
專案的交接上多少有點混亂
從下個月開始
就會正式進入TFS專案管理
以及固定小組code review
還有實施gitflow、githubFlow
一個月的內容真的頗多的
就先寫到這邊
下個月待續
留言列表
