為何需要 Repository Design Pattern

在最近參與的專案當中，我們開始導入了 Repository Design Pattern，一句話總結它的用途就是「負責處理資料的新增、讀取、更新、刪除 (CRUD) 的角色」，建立這樣一個角色來負責處理資料能帶來什麼好處呢？

PHPickerViewController 是系統內建的一個照片選取工具，透過 PHPickerConfiguration 設定它，然後從它的 delegate function func picker(_ picker: PHPickerViewController, didFinishPicking results: [PHPickerResult]) 取得用戶選取的結果。看起來非常簡單直覺，直到我踩了坑...

以前的作法

在以前要用 Auto Layout 來設置 UIScrollView 的 sub views 並不是一件讓人愉快的事情，雖然不複雜，但步驟就是有點麻煩。因為 scroll view 自身的特性，所以必須設定它本身的位置與尺寸，然後設定 sub views 的位置與尺寸，最後算出 contentSize 的尺寸。總結來說大概分成以下幾步：

1. 設定 UIScrollView 本身的位置與尺寸
2. 建立一個 contentView 並加到 UIScrollView 的 sub view
3. 設定 contentView 的位置，通常是四邊都貼齊 UIScrollView
4. 可以滾動的 sub views 都加到 contentView，然後用 auto layout 設定這些 sub views 的位置與尺寸
5. 如果設定無誤的話，contentView 就可算出正確的尺寸，這就是 UIScrollView 的 contentSize

最讓人困惑且忽略的就是第三點，因為它很不自然，但在 UIScrollView 卻又是必須的。另外就是第四點，一定要有明確的位置跟尺寸，這樣才有辦法算出 contentSize 給 UIScrollView 使用。

現在的作法

從 iOS 11 開始，UIScrollView 多了 frameLayoutGuide 跟 contentLayoutGuide 這兩個方便的屬性，讓我們不必再用不自然的方式去設定 content 的 auto layout。

1. 可以使用舊有的方式或是使用 frameLayoutGuide 設定 UIScrollView 本身的位置與尺寸
2. 不需要額外的 contentView 了，直接把內容加到 sub view
3. 這些 sub views 與 contentLayoutGuide 建立 auto layout constraints

整個設定流程變得自然許多，也更不容易出錯。現在我們只要確定 sub views 有設好明確的位置與尺寸，讓系統能夠算出 contentSize 即可。

有的時候一些跨平台共用的頁面會使用網頁的方式打造，在 iOS 的世界裡我們可以使用 WKWebView 呈現網頁內容，除了單純的呈現之外，彼此的互動也是不可或缺的一環。這篇文章將會簡單介紹該如何達成網頁與 iOS 原生程式碼之間的雙向溝通。

這一篇主要是要紀錄如何設定 Apple Watch 的 Complication。

Complications 是錶面上可讓使用者選擇的小元件，需要使用 ClockKit 開發 (有些畫面可以用 SwiftUI 開發)，它的用途是在特定的時間，顯示相對應的資訊。

Apple Watch 內建數十種錶面，每種錶面支援的 complications 數量 / 位置 / 尺寸都不盡相同，根據不同的尺寸跟風格，定義了多種不同的 families，每個 familiy 支援不同的 templates，我們使用 template 來設定要顯示的文字、圖片、或儀表圖。各種不同 families 的長相可以參考這份文件。

這一篇筆記主要是要記錄如何在 iPhone app 跟 watchOS app 之間傳遞資料。

iPhone 跟 Apple Watch 的溝通方式

iPhone app 跟 Watch app 可以透過設定相同的 App Group 共享檔案，也可以透過 WatchConnectivity 溝通，App Group 的方式沒什麼好說的，所以來紀錄 WatchConnectivity 的作法。它主要分為兩種方式：