[圖解] 如何發佈行動應用程式
從 2012 年開始，我就從事行動應用程式開發（主要是 iOS App），至今已超過 10 年。當有人想知道我做什麼工作時，我必須短時間內說明清楚，只是一直沒找到好的描述方式，能讓外行的親友理解。
遇到神人做了這張圖，簡單描繪出我這些年來的工作日常～😎
行動應用程式發布過程的典型階段：
- 註冊與開發
- 建置和測試
- 品質保證
- 內部審核
- 應用程式商店優化
- 應用程式提交至商店
- 發布
Archive for the ‘研究’ Category
[圖解] 台灣電視媒體立場觀察
2024 年總統大選即將來到，各大媒體無不在為選戰做準備。🙃
2020 年以前，我沒有什麼在注意媒體的立場，在餐廳吃頓飯，電視播什麼新聞就接受，比較不會去調查核實事情真相。
2020 年以後，才開始小心看待每則新聞，特別是跟政治有關的部分，以免又被媒體用扭曲事實來洗腦而隨風起舞。
看了這張台灣電視媒體立場觀察，關於政治議題，就知道要看哪一新聞台了～🤔
（繼續閱讀…）初學工程師偏好開發 Web 或 App
雖說我的立場是偏好開發 App，也已經有 10+ 年經驗，但還是想分析一下，對於初學者來說，如何做選擇會比較恰當。
大概在 2010 年前後，我有短期開發網頁應用程式，確實上手門檻較低，不需要額外硬體或軟體支援，便可以馬上寫簡單的程式。
但其實，若我一天有 48 小時，我會希望 Web 和 App 都能開發～😛
最終，我選擇 App 開發，那會是最貼近生活的一種開發工作。
（繼續閱讀…）QUIC 網路傳輸層協議
由於 App 需要加快連線速度，於是我研究了 QUIC 網路傳輸層協議。基本上，我對底層技術不那麼有興趣，畢竟人家早已決定好，大家都在用且行之有年，開發者還有機會能改變什麼嗎？🤔
不過，倒是可以去了解為何會出現 QUIC，它之所以被發表出來，肯定有其時空背景所催。
QUIC (Quick UDP Internet Connections) 是 Google 提出的新一代傳輸層協定，QUIC 唸作 quick。這說明了整個協定只為了一個目的，盡可能從多個不同層面讓 QUIC 可以更快的建立連線，更快地開始傳送資料，以應對現代許多講求低延遲的應用場景，在試圖降低延遲的時候，往往 TLS + TCP 的限制會成為效能瓶頸。
TCP 協定因為多年的發展還有歷史包袱註定了這個技術不能改頭換面，解決一些設計之初沒有考慮到的缺陷，所以 QUIC 只能另尋他路，將整個協定建構在 UDP 之上。
（繼續閱讀…）成為 App 工程師需要注意的四件事
一個月前，有位公職人員來信詢問，想知道一些關於 App 工程師職務的議題，在此我便以 10 年左右的經歷，來整理出主要可以參考的方向。
我是個從還是個資訊工程學系研究生時，就決定開始寫 iOS App，一寫至今，已經超過十個年頭，當時 Apple 才剛釋出 iOS 6，現在已將要發佈 iOS 17。
經過十個年頭，我依然堅持走這條路，因為這工作實在太好玩了，執行力夠強的話，一個人就可以完成一個 App，實在很符合我的個人特質－自幹。
智慧手機與平板電腦日益普及，程式語言和開發工具與時俱進，讓研發的過程更有效率，最後成果的體感越來越友善且優異。我陸續學習原生 Objective C、Swift，甚至嘗試跨平台 Xamarin、Ionic。如今更是期待 Flutter 能有長足的進步與發展。這樣一來，我想要同時開發 iOS 和 Android 就能輕鬆實現啦～😄
論技術能力我沒有到極強，只要能應用在產品與專案上，任何技術都能接納，特別是面向使用者，我追求 UI/UX 盡可能做到極致。🤗
（繼續閱讀…）
Crashlytics loadLibrary
最近一個月，湧入上萬用戶使用我們家的 App，特別是 Android 手機用戶佔了大部分。當然用戶一多，就會出現不預期的狀況，這在開發 App 是很普遍發生的狀況。
特別是 Android 系統，相比 iOS 較為不穩定，因為是開放系統，讓各家軟硬廠商有較多的彈性去調整系統。於是乎，會遇到不預期的崩潰狀況，是理所當然之事。
這次來記錄一下，Crashlytics 記錄最多崩潰的事件：FlutterJNI.loadLibrary。
（繼續閱讀…）Crashlytics ANR
最近我負責的產品 App 流量大增（至少成長十倍），各種崩潰數據也跟著多了起來，尤其是 Android App，出現了一堆我壓根沒見過的問題，畢竟過去十年我都在做 iOS App，這下子得趁這一波學習一下啦～
我在 Firebase Crashlytics 後台上見到一些議題，先截個圖來看看多麽嚴重刺激！？😃
語法糖式開發 (Syntactic Sugar Development)
語法糖 (Syntactic Sugar) 有點像是「炫技」的概念，把淺顯易懂的東西包裝成複雜華麗的樣貌，藉此吸引人的眼光。或是說，隱藏物件複雜的內容，僅顯露簡單的表面，然後大家都能輕易使用。😎
寫程式的過程中，時常會需要寫判斷 IF ELSE，如果每次都要打這六個字，有時候真的會很煩～
那麼該怎麼簡化此寫法，於是我便常用：
expression ? option1 : option2
現在只要兩個符號？和：，即可搞定兩種判斷。不過簡化也需要看狀況，以免未來看到還要花時間去推敲理解。
（繼續閱讀…）
逍遙文工作室 
HappyMan・迴響