[iOS] 判斷兩影像是否一樣
前一個版本實作判斷相片是否被修改,是拿相片最後修改時間來比較,不過卻發生異常狀況,使得就算用戶沒有修改過相片,還是會跑到有修改過相片的流程,這讓我們家負責客服的同事哀嚎了一下⋯⋯大概讓我們損失好幾萬美元的營收。😳
透過PHAsset拿到相片資料中的modificationDate,也就是相片的最後修改時間,照理說應是沒有問題才是⋯⋯
前一個版本實作判斷相片是否被修改,是拿相片最後修改時間來比較,不過卻發生異常狀況,使得就算用戶沒有修改過相片,還是會跑到有修改過相片的流程,這讓我們家負責客服的同事哀嚎了一下⋯⋯大概讓我們損失好幾萬美元的營收。😳
透過PHAsset拿到相片資料中的modificationDate,也就是相片的最後修改時間,照理說應是沒有問題才是⋯⋯
記得在偉大的港商上班時,我們有三個iOS開發者,共同開發維護一個產品。此產品歷經1.5年開發,最後沒有上線,產品還直接被停掉。
當時我們每隔一週就要發布一個測試版本,後來主管指示此過程要全面自動化,於是我們帶頭的同事捲起袖子,把Jenkins 與 Gitlab串接起來,成為幾乎自動化的發佈過程!🤠
此圖是我統整所有過程,寫出來的四大部分和五大行為。未來可給大家參考用囉!
香港的同事負責送審,他會指定發佈到「獅子山」這個國家,我還以為他在開玩笑,查詢之後真有這個國家呢!😛
為什麼還沒開發完就要送審?因為我們要確保臨時要上架是沒有問題的!所以送審的頻率一個禮拜一次,而且都只上架到獅子山。
在港商上班最大的收穫之一,是跟香港同事合作,並見識到同年紀的香港CEO和CTO如何處理部屬~😏
技術上的精進比較沒太多可以著墨,因為是產品開發元老的架構為基礎往上開發,離開公司後那些複雜的流程不怎麼好用啦⋯⋯
總之,我還是認為,一個人就能開發App,是最過癮且最有成就感的事啦!💪
多虧Firebase Crashlytics的幫助,讓我曉得用戶發生哪些崩潰,在後台記錄得非常詳細,可以清楚讓我知道哪一個Class中的哪一行Code是崩潰關鍵!
可看到最近一週,有10次崩潰,影響10個用戶。
IDFA 全稱為Identity for Advertisers,即廣告標識符。用來標記用戶,目前最廣泛的用途是用於投放廣告、個性化推薦等。
關於IDFA在iOS的重要性,可以見我先前文章:IDFA、IDFV、UUID。
(繼續閱讀…)看標題還不知道要做什麼,那麼就直接來寫程式!
其實一張圖多顏色 (One Image Multi Color),就是想要只提供一張圖片,就能呈現多樣顏色,這有什麼好處?就不用設計師出許多不同顏色的圖囉!
又到了一年一度更新推播憑證的時候!因為先前僅有初次產出推播憑證經驗,但沒有更新推播憑證的經驗,以為會有多難,沒想到就跟初次一樣的步驟。🧐
發現舊有的憑證無法更新期限,那麼就如同第一次建立新的推播憑證吧!此次推播憑證更新:2020/10/05,期限:2021/11/04,有效期間為13個月。
由於時代不停的變遷,使得必須從Fabric Crashlytics遷移Firebase Crashlytics。
自從2017年Google收購Fabric,我之前所整合的Answers和Crashlytics就逐漸被整合到Firebase。遙想2017年我還在看Fabric後台,很有成就感地看著我開發的HiLife和Nissan。文章:Fabric Crashlytics 崩潰紀錄。
還記得2020年底前,必須把UIWebView全面改成WKWebView,這些也在這篇文章提及:棄用API的使用情況 (Deprecated API Usage)。並且我在最近把第三方套件中的UIWebView移除。
由於開發能量有限,想要直接把Web的內容鑲嵌在App之中,可以怎麼做比較好呢?其中之一的方式就是使用SafariViewController,幾乎等同於Safari App的效果。
原本還想說Web的內容在手機上呈現效果奇差無比,假如Web沒有把響應式網頁設計(Responsive Web Design)寫好,確實在手機小畫面中呈現不佳。但我畢竟不是Web工程師,難播出時間去調整Web內容。
一直以來我很喜歡地圖應用,可以大範圍看到資訊的廣度,像是垃圾車經過的地點或微笑單車租借站的地點。
最近想要在地圖上繪製路徑,研究過後發現非常簡單,將有經緯度的資料準備好,透過MapKit來繪製即可!
HappyMan・迴響