年終歲末

實作超久的dark mode

終於準備要上線

但是計畫總是趕不上變化

當我把檔案上到TestFlight

PM用自己的手機測試時

發現在iOS 13會有個致命bug

就是底下六個頁籤的Tab bar

放太久就會自動縮水

變成4個tab bar加上一個more的tab

看到當下真的是傻眼

想了想和前一次build版

唯一有差異的就是升級IDE

用Xcode 11.2Build版

查遍stack overflow的資料

一個一個試

希望能夠趕在星期五上版前

把這個bug修好

但是這個bug觸發時間常常要等待一小時以上

所以發現解決方法不行時

通常都兩個小時過去了

最後一樣痛定思痛

強忍悲傷跟原生tab bar說掰掰

老老實實的自己刻一個

現在想一想

其實自己也是很皮

因為大部分解答都說

如果要用六個tab

請自己實作

iOS原生就是不鼓勵五個以上的tab

但我就是心存僥倖

看有沒有辦法鑽一些漏洞

畢竟在Xcode 10以前都可以

沒想到只是浪費更多時間

學到最寶貴的一課    

不過還好最後還是趕在過年前

把dark mode上線

另外一個重要的功能

就是徽章系統的實作

簡單來說

就是模仿遊戲的頭銜機制

只要達到特定條件

就可以獲得徽章

乍聽之下不難

但是這次API開的方式

跟之前比較不一樣

概念上比較像是後端資料庫中

用PK去做Mapping的概念

所以必須把六七道單獨的API

整合成前端需要的資料結構

這個部分一樣不難

比較麻煩的是

在每一篇文章以及留言的地方

都必須顯示作者的徽章

就類似臉書的頭號粉絲稱號的功能

偏偏後端開的API

並沒有把徽章資訊夾帶在原本的文章當中

而是需要前端針對使用者的ID

去拿每個人穿戴的徽章

再自行放進文章的物件當中

這個其實也沒有比較好的解法

就是拿完文章的資訊後

再針對文章內作者或是回應者的ID

去要他們穿戴徽章的ID

取得後存在快取

再通知頁面做table reload

在Code Review也詢問過同事的意見

不過似乎都沒有比較好的做法

只能很粗暴的在每一道取文章的方法當中

再多添加一個取徽章的API

達成需求

另外還有一個要解決的事情是

由於徽章功能上線後

使用者第一次開啟App時

會跳出所有他獲得的徽章的彈窗

不過又因為彈窗會跑動畫

被壓在下面的彈窗

必須等上一個彈窗消失後

才可以開始跑動畫

原本還煩惱不知道怎麼實作

後來突然想到這不就是link list嗎

讓彈窗物件多一個next的欄位

指向下一個彈窗

當自己關閉時

呼叫next彈窗跑動畫

看了那麼多次的link list

終於有派到用場了

覺得欣慰

接著就是快樂的尾牙啦

不過今年還多了一個意外

獲選最佳員工獎

這是公司第一屆舉辦的獎項

大約十人獲獎

名單由各個主管推薦

表揚團隊內的績優員工

記得剛進入公司時

仍然每天在自我懷疑

是不是一個合格的工程師

還真的沒有想到可以拿到最佳員工獎

不過得獎原因

當然不是因為技術方面超厲害

而是願意突破工程師的框架

針對團隊的難題

主動提出解決方案

並且實作該功能

以及提出有趣的需求

像是去年的聖誕節活動

不過也是因為都能準確估算工時

沒有太多的delay

或是後修時間

才有時間去想一些有的沒的

相比去年這個時候

還在跟閃退奮戰

這一年真的收穫滿滿

用獎盃結束這一回合~~

IMG_20200308_213818.jpg