軟體主廚的程式料理廚房

開發 iOS 的 App 想上架到 App Store 送審被拒絕個幾次可說是稀鬆平常的，即使我們把 App Store Review Guidelines 讀得滾瓜爛熟，還是有被拒絕的可能，而且被拒絕的理由百百種，有跟 Apple 審核團隊交手過的朋友應該就有 fu，我就我這次 App 送審被 Apple 退件拒絕的經驗做個記錄。

Apple 在審查我們的 App 的時候會在 IPv4 跟 IPv6 環境底下去測試，我們的 App 應該要能在 IPv6 的網路環境執行，如果我們手邊有 macOS 就可以建立一個 NAT64 的網路環境來測試看看我們的 App 在 IPv6 的環境底下 work 不 work？

用 Xamarin 開發好 iOS App 後，如果我們的開發環境是 Visual Studio 照著官方的步驟一步一步做，用 Application Loader 上傳完畢想說應該 OK 了，但是在 iTunes Connect 遲遲不見剛剛建置版本上傳，檢查信箱收到了一封信：

開發完成的 Android App 如果想打包成 APK 檔，Visual Studio 已經提供了方便使用的介面讓我們將 Android App 輸出成 APK 檔案，打包好的 APK 檔案我們可以用來上傳到 Google Play、也可以複製給其他人安裝使用。

TaskCompletionSource 這個玩意兒是我在 InAppBillingPlugin 這個 GitHub 儲存庫發現的，查了一下 MSDN 它說「代表未與委派繫結之 Task<TResult> 的生產者端，可提供透過 Task 屬性對消費者端的存取。」??????　它在說什麼？我們來舉個例子。

Apple 在審核我們的 App 的時候會看一個東西，那就是我們的 App 內提供的對外連結是否具有引導消費的功能，消費的項目如果被認定踩中了 App 內購買的類型，比如說我在我的 App 放了一個按鈕，按下去之後用瀏覽器開啟我準備好的網頁，使用者在網頁中可以付費升級專業版，這樣的話有極大的機率會被 Apple Reject，然後叫我們用他們家的 In-App Purchases，不過實作上也不算太難。

Firebase Clound Messaging（FCM）的 Notification Payload 裡面有一個 click_action，顧名思義就是當推播訊息被使用者點擊之後，App 跟隨著要做什麼樣的反應動作，最常見的就是 App 依據 click_action 跳至與通知相關的頁面，我們就來看看如何透過 click_action 來控制顯示不同頁面。

Task 是從 .NET 4.0 開始就有的東西，用它來取代傳統的 Thread、ThreadPool 還挺便捷的，但有時候有一些有時效性的 Task，當它執行超過我們規定的時間時我們需要知道，Task.Wait() 可以帶入 millisecondsTimeout 參數，不過它是同步的。

SQL Server 的 PIVOT 及 UNPIVOT 運算子用來將資料表中的欄轉置為列、列轉置為欄，將資料表中指定的欄位做旋轉，因為經常用到的時候就要再 Google 一次，所幸就自己寫一篇記錄一下，而且在轉置的過程中還順便彙總，一個常看到的範例就是計算銷售人員 1 ~ 12 月的銷售金額，並將 1 ~ 12 月當做欄位名稱 SELECT 出來，除此之外還可以拿來對付一些特別的設計。

Redis 的效能有體驗過的朋友應該都是有目共睹的，最近遇到一個一次要寫入 16 萬筆資料的場景，測試環境的 VM 規格都是最基本的，在測試環境測試一筆一筆寫入要大概將近 20 分鐘，而且還會 Timeout，心想即使規格不高 16 萬筆應該也不至於這麼慢吧，爬了一下文大概找到了兩種解法。