軟體主廚的程式料理廚房

上一篇文章提到依賴，依賴也無所不在，而 DIP 要我們將依賴做「反轉」，是要反轉什麼？反過來依賴嗎？　當然不是，而是解除直接依賴的關係轉而去依賴於抽象介面，使得位於較低層次的類別依賴關係的方向反了過來，大致上看起來就會像這樣。

DIP - Dependency Inversion Principle（依賴反轉原則）說：

1. 高層次的模組不應該依賴於低層次的模組，兩者都應該依賴於抽象介面。
2. 抽象介面不應該依賴於具體實現。而具體實現則應該依賴於抽象介面。

如果是初次接觸到這段說明的朋友可能會有一個感覺，就是裡面每個字都看得懂，但是它在講什麼？要了解 DIP 要先清楚它這邊提到的依賴是什麼？我就以我個人的理解來分享我的心得。

Isolate Scope 使用在重用的組件是非常適合的，如果只是單純地想在 Directive 中避免直接操作 Controller 範圍的屬性或方法，希望定義一些別名在 HTML Element 中與 Controller 的屬性或方法織在一起，應該避免使用 Isolate Scope。

用 AngularJS 開發程式很少不用額外撰寫 Directive，如果我們在 Directive 裡面使用 Isolate Scope 並且從 Controller 指定了一個 function 為觸發函式（&），好死不死這個 function 是需要丟參數給它的，按照一般正常的丟法是不會 work 的，想要丟參數給觸發函式需要一點迂迴的做法。

憶起第一次執行自己寫的程式的感動，到現在都還記得，當時用的語言是 VB，在 IDE 上開了一個 Form 拉了一個 Button，按下去之後跳出 MsgBox 顯示 "Hello World"，內心不斷地給自己鼓掌「哇！我也會寫程式了。」，至今有沒有曾經後悔過走這條路已經忘記了，但是程式設計「賜我吃、賜我穿、賜我借錢可以還。」是個事實，講這些跟這篇文章的主題有什麼關係？

開發 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 屬性對消費者端的存取。」??????　它在說什麼？我們來舉個例子。