不同 App 之間原本是無法溝通的，但是可運用一些技術來達到效果，運用場景像是同一間公司出的 App 可以互通登入狀態，或是 App 需要與 App Extension 共用資料等等。 官方文件Apple 有官方文件解釋到相關技術 - Sharing Access to Keychain Items Among a Collection of Apps 兩隻 App 間無法共用資料的狀況 兩隻 App 間共用資料的狀況 共用資料的方式UserDefaults + suiteName + App Groups Project > Signing & Capabilites > Add App Groups ( 請自定義一個 suiteName ) 在需要存取資料的地方使用 UserDefaults 的 suiteName 寫法，suiteName = 上一步建立的 suiteName 123let groupUserDefaults = UserDefaults.init(suiteName: "group.pink.compan ...

當開發 App 完成功能後，有時需要驗證產品流程正確性，或是尋找其他問題，除了 Console 的方式顯示訊息外，有沒有其他方式可以顯示一些偵錯訊息呢？也可以讓非開發者也能一同協助呢？ 目標 讓 非開發者 能夠協助驗證流程或是尋找問題 驗證 使用者行為的紀錄 (ex. Flurry、FirebaseEvent) 驗證 Api呼叫的狀況 (ex. 呼叫次數、回應時長) 解決方式因此我們需要一個隨時可以顯示在畫面上的元件，並且可顯示任何偵錯訊息！ 這裡直接附上專案連結 DebugTool 初始化方式 ( 宣告靜態的 DebugTool 並且顯示它 ) 123456789101112131415import DebugToolclass SceneDelegate: UIResponder, UIWindowSceneDelegate { var window: UIWindow? static var debugTool: DebugTool? func scene(_ scene: UIScene, willConnectTo sessi ...

建立 CI 流程除了需要建立 Runner 以外，另一部分就是需要設定好 CI 腳本，下面我們就根據 iOS 的專案來建立一個 CI 腳本，未來也可依照不同需求不同平台的專案，建立出專屬自己的腳本！ 基本設定 請先在 Repo 的根目錄下建立一個檔案，檔名為 .gitlab-ci.yml，並且打開後編輯它 首先要先設定有哪些 stages 狀態，這些狀態會對應在 pipeline 上的每個步驟，如下圖 這裡列出範例的狀態，請依照需求自行調整。 start: 開始 CI 流程，可以執行通知 Slack 等等的腳本 lint: 跑靜態檢查器，可以跑 swiftlint 或 swiftformat build: 編譯程式碼 unittest: 跑單元測試 archive: 可以在打 tag 時進行發版到 testflight ( 此處先略過，如果需要發版可呼叫 fastlane 的指令 ) tracing: 追蹤某些程式碼狀況或版號 end: 結束 CI 流程 12345678stages:- start- lint- build- unittest# - arch ...

CI/CD 一直一來都是前端和後端共同的話題，因為自動化流程不管是應用在哪個領域用途都是相當大的，會節省相當多的時間和人力，如果結合軟體開發流程，甚至衍生出 DevOps 等等規範，而本篇則是用 GitLab Runner 建立一套 CI 流程。 工具選擇在選擇工具前，還是先知道我們要做什麼？所以說明一下什麼是 CI/CD CI: Continuous integration 持續集成，程式碼上傳後會自動編譯和測試和靜態檢查等等 CD: Continuous delivery 持續交付，CI 確認成功後自動發佈到正式環境 網路上有太多優秀介紹 CI/CD 的文章，這裡只留 GitHub 和 GitLab 的官方解釋 GitHub - CI/CD explained GitLab - What is CI/CD? 想要為你的產品做一套 CI 流程，考慮因素很多，例如你的程式碼放哪裡？你的產品是網站、App還是服務？專案數量？共同的開發人員數量？金錢預算？因此其實沒有最佳解，找到適合自己公司或產品才是重要的。網路上也有相當多的線上服務，例如：Bitrise、TravisCI、C ...

問題情境 如何產生一個 Struct 所對應資料的 Schema 呢？ 一開始我們有個資料結構如下，有包含名稱、年紀、標籤清單、網站資訊、訊息列表。 12345678910111213141516171819{ "name": "pink", "age": 18, "tags": ["iOS", "Apple", "Swift"], "webInfo": { "title": "pinkpika github", "url": "https://github.com/pinkpika" }, "posts": [ { "time": 1671321786, ...

前陣子接收到很有趣的程式碼，基本上就是一個很大的 enum 有多達 30 個以上的 case，還有一個 4000 行 Factory 類別，Factory 裡面都是依照 enum 做各種處理，當初這類別相當複雜，有些處理會呼叫 Api、有些讀取 DB、每個 case 的步驟也都不相同，但通通都在這個類別處理，導致程式碼快 4000 行。 下面先簡化成三個 case 的 enum CakeType.swift12345enum CakeType{ case strawberryCake case cheeseCake case chocolateCake} CakeFactory.swift1234567891011121314151617181920class CakeFactory{ /// 取得價格 func getPrice(cakeType: CakeType) -> Double{ switch cakeType{ case .strawberryCak ...

近期在開發過程中 ssh 連線時驗證公鑰指紋 ( public key fingerprints )，發生過兩次的衝突案例，希望在此記錄下來，以便未來回顧之用。 衝突案例ssh 連線常用於 git 操作或是遠端連線伺服器，身份驗證可以使用”公鑰私鑰交換”或是”用戶帳密”來進行身份驗證，正好下面提到的兩個案例各有一個。 案例1: 某天晚上公司 MIS 幫大家換內部自建的私有 GitLab 機台，當然換的過程有完整備份，最後連線的 ip 也是相同沒有更換，但隔天大家要使用 git ssh 的方式發動遠端操作，例如 push pull …，結果失敗 🤯 案例2: 某天我將公司 CI 機進行更換，換成另一台硬體性能比較好的機器，一樣有做完整轉移和設定，但最後我使用終端機發動遠端連線 ssh user@192.168.ooo.xxx，結果失敗 🤯 問題原因進行 ssh 連線有一個漏洞需要進行防範，就是中間人攻擊 ( Man-in-the-middle attack )，可以用惡意的攔截封包軟體，並且在發送資料前後進行解密和重新加密，為了保護 ssh 連線，因此在第一次連線 ...

SwiftUI 官方文件已經有相當完整的元件用法和清單，可以自行查閱，這裡先簡單列出一些常用的。其實跟 UIKit 一樣每個元件都有預設的實作和樣式，都是符合 Human Interface Guidelines，但是如果產品需求就是無法用原生元件達成，就需要自己建立客製化元件了。 User Interface Elements最基礎使用者介面的單元，可以直接給予用戶訊息的元件，像是文字圖片等等。 Text & ImageControl & IndicatorShape & Canvas Text: 單行或多行的唯讀文字 1Text("Hamlet").font(.title) Label: 帶有圖片的文字 1Label("Lightning", systemImage: "bolt.fill") TextField: 一般輸入框 1234TextField( "User name (email address)", text: $username) SecureField: 密碼 ...

Apple 在 2019 年的 WWDC 發布 SwiftUI 和 Combine，這兩套新的開發方式給我們很多新想法和驚喜，也為 Swift 的生態系注入新的活力，最近會開始慢慢接觸它，這是第一篇文章，未來會再持續記錄下去。 前言以前開發 App 是基於 Objective-C 編寫程式的方式，加上 Cocoa Design Patterns 例如 target/action、delegate/protocol、KVO、NotificationCenter，並且使用 AppKit 和 UIKit 的 UI 系統和 MVC 的程式架構，而 Swift 基本上也是將上述用法原封不動地封裝成自己的接口，發展出更簡化更安全的呼叫方式，由於近代程式語言的演進和趨勢，同時前端各種語言和框架的興起 ( React Native 和 Flutter … )，Swift 也進而演化出 SwiftUI 和 Combine。 這邊要先提及另一個名詞叫做”程式範式”，一般來說”程式範式”（ Programming Paradigm ) 會直接影響寫程式的思考方式和邏輯，有些程式語言只為一種範式而設計、有 ...

API 指的是應用程式之間溝通的介面，而本篇主題其實是前端呼叫後端 Web API 的設計，前端使用 Web API 可以拿到遠端的資料，也可依照不同用戶提供他們不同的內容，因此如何設計前端 Web API 層的邏輯變得很重要，需要兼具共用性和擴充性。 本篇所提及的 Web API 設計版本，其實是用來 紀錄自己曾經使用過的設計方式，未來也可能會再增加，所以內容有大量自身使用過的感想，不代表絕對的好壞，依照專案需求或架構會有更適合的設計方式。 Web API 設計的邏輯在實作 Web API 層的邏輯前，可以把它分成三段流程 🔵 Part1 組合 Request 流程 如何組成 Request ? 發送前需要設定好各項參數，可能包含有下列項目 URL: 請求的網址，包含 scheme、host、 port、path、query … 等等 ex. https://www.ios.com/api/user?id=9999&type=1 HTTP method: 請求的方法，通常能反應出此 API 的目的 ex. get、post、put、patch、delete ...