前言 第一個進行的 issue 是「里程定位與地圖顯示」，先用 VS code 來看一下這兩份 CSV(省道與國道)長什麼樣子： 我們現在的目標是，讀取 CSV 檔案，然後將其轉成我們定義好的物件類型。 Git 分支規劃 從 main 分出 develop 再從 develop 分出 feature/parse-csv 分支 於 feature/parse-csv 分支進行開發 資料結構 依據 CSV 欄位，定義我們需要的結構： struct ProvincialMileageMarker { let roadNumber: String // 公路編號 let county: String // 隸屬縣市 let wgs84Lon: Double // 坐標-E-WGS84 let wgs84Lat: Double // 坐標-N-WGS84 let township: String // 隸屬鄉鎮 let location: String // 設置位置 let content: String // 牌面內容 let condition: String // 現況 let direction: String // 牌面方向 } struct HighwayMileageMarker { let roadNumber: String // 國道編號 let county: String // 隸屬縣市 let wgs84Lon: Double // 坐標X-WGS84 let wgs84Lat: Double // 坐標Y-WGS84 let display: String // 牌面內容 let direction: String // 方向與備註 } 資料讀取與顯示 搭配 Combine，建立 RoadDataManager，實作資料背景讀取與在 Day 9 介紹過的 Combine 來自動更新畫面： ...

前言 今天我們來畫 App 畫面草圖，有了草圖，之後才有辦法按圖施工～ 手繪 Wireframe or AI 工具？ Wireframe 一般來說，最初會從手繪草圖開始。你只需要一支筆和一張紙（或平板），可以快速畫出多種版本的設計，不滿意就立刻劃掉重來，幾乎沒有任何時間和金錢成本。 這個階段，我們完全不用考慮顏色、字體或精美的圖示。所有的精力都集中在「畫面上該放什麼元件？」、「按鈕應該在哪裡？」以及「使用者如何從 A 畫面跳到 B 畫面？」這些核心問題上。它能幫助你將腦中模糊的想法具體化，並檢查流程是否順暢。這樣的好處是，你的思考是自由的，你不會被工具的功能或好看的的 icon 分心。 手繪草圖其實就是 Wireframe (線框圖) 的一種形式。Wireframe（線框圖）是 App 的低保真度設計原型，像是 App 的骨架或藍圖。它通常由簡單的線條和方框組成，用來呈現： 內容佈局：各個區塊（如圖片、文字、列表）在畫面中的位置。 核心元件：包含哪些按鈕、輸入框、導航欄等。 資訊架構：如何組織畫面上顯示的資訊。 Wireframe 主要著重於功能，而非視覺設計，同時也確保開發者和設計師在動手前對 App 的樣貌和流程有一致的理解。 AI 工具的新可能 現在有一些 AI 工具，可以讓你用文字描述你想要的畫面，然後自動生成視覺設計稿或 Wireframe，甚至直接給你完整的 UI 設計。這類工具（如 Figma AI 等）非常適合作為初期發想的輔助，幫助你快速探索不同的設計方向。若你的 App 很簡單，或是只是想快速做個 MVP，那或許很適合直接請 AI 幫你產出畫面設計。 但不論是自己全手動繪製，或是請 AI 產出，本質上你都還是得必須先透過自己思考你的 UI 佈局，畢竟請 AI 產，你還是得給予具一定精準度的提示，否則產出結果可能不如預期。 而且，AI 產出的設計需要專業評估。你需要檢查功能完整性，是否涵蓋所有必要功能？流程是否符合使用者習慣？設計是否能實際開發實現？或是否符合你的 App 定位？ 我的實際嘗試 手繪先行 先手繪基本流程，用平板快速勾勒頁面架構。 搜尋畫面：國道/省道、道路選擇、地圖。 追蹤元件：這個頁面會顯示正在被監控的地理圍欄點，且包含： 里程標資訊： 例如「台19線 89公里」。 當前狀態： 顯示該點目前是「在範圍內」還是「在範圍外」。 停止追蹤/啟用追蹤功能 AI 設計的評估與調整 接著，試著請 AI 來產一份 UI 設計，看看成果如何。 ...

前言 在我們開始繪製使用者介面之前，我們將先聚焦在使用者流程 (User Flow)。 這就好比建築師在蓋房子前，不會先煩惱沙發要買什麼顏色，而是會先畫出整棟建築的平面圖與動線規劃。使用者流程圖幫助我們釐清，使用者為了達成某個特定目標，需要依序經過哪些畫面、點擊哪些按鈕。 預先規劃好完整的流程，再針對每一個環節去設計對應的畫面，才能確保 App 的功能環環相扣，既不會做出無用的設計，也不會遺漏掉關鍵的操作步驟。 什麼是使用者流程圖？ 使用者流程圖（User Flow Diagram）它描繪了使用者為達成特定目標時，從進入 App 開始到完成任務的完整路徑。流程圖聚焦在： 使用者如何在不同畫面/功能之間移動 每個操作觸發的系統反應與後續分支 各種異常或錯誤狀況下的備援流程 決策點與不同選擇導致的結果 它與 Wireframe 不同在於，流程圖專注於流程的邏輯性與連貫性，而 Wireframe 則專注於畫面的佈局與排版。 流程圖的價值 當你在規劃流程圖時，你會用使用者的角度去看待操作過程，同時會意識到過程中的可能的瑕疵或邏輯不順的地方。如果沒有事先思考就開始開發，你很可能開發到一半才發現有問題，例如「啊，使用者從這個頁面要怎麼回到上一頁？」或是「等等，如果使用者沒登入，這個按鈕按下去會發生什麼事？」 此時修改的成本可能會相當地高，最慘甚至可能導致整個功能必需重新設計。 而從另一個角度來看，事先進行這個過程，同時也會思考如何提升使用者體驗，確保每個使用者路徑都有清楚的起點、過程與結果，讓使用者在使用 App 時感到順暢自然。 工具 - draw.io 我通常使用 draw.io 這個工具來建立流程圖，它是免費、功能完整且支援多種匯出格式的流程圖工具。流程圖的圖示皆有代表的意義，例如： 圓角矩形（開始/結束）：代表流程的起點與終點 矩形（畫面/動作）：代表具體的畫面或使用者動作 菱形（決策點）：代表需要判斷或選擇的節點 箭頭（流向）：表示流程的方向與順序 流程圖的重點是釐清邏輯，而不是畫得漂亮。就算一開始用筆和紙在便條紙上畫草稿也完全沒問題。工具只是輔助，能幫助我們把腦中的邏輯具象化，才是最重要的。 規劃專案 App 的流程 在我們的 App 構想中，包含了地理圍欄通知、搜尋歷程等功能，但在本篇文章中，我們將以核心功能公路里程搜尋為例，從頭到尾走一遍使用者流程圖的規劃過程。掌握了這個概念，實作其他功能的流程圖時，原理都是一樣的。 範例：搜尋特定里程點 App 最基本的功能流程，這裡我就使用 draw.io 來繪製： 可以輸出成圖片： 流程從綠色的「開始」到紅色的「結束」。頁面與動作 (矩形)則代表使用者看到的畫面或執行的操作。抉擇點 (菱形)則為使用者需要做選擇，且不同的選擇會導向不同結果的地方。 開始 → 主畫面 使用者打開 App，看到地圖及上方的搜尋欄。 點擊「道路類型」→ 抉擇：國道或省道？ 這是使用者的第一個岔路，根據使用者的選擇（國道／省道），系統會載入不同的道路列表。 顯示列表 → 道路選擇 + 里程輸入 使用者從列表中選定一條具體的道路（如：國道一號），並在下方的欄位輸入里程數字。 ...

前言 在 Day 1 的時候有提到，在我剛進公司時，公司正好在導入 Azure DevOps 作為專案管理工具。這讓我有機會從零開始學習如何使用這個工具，並且在實際的工作中應用它，也因此體會到了專案管理工具對於軟體開發的重要性與價值。例如，它能幫助團隊更清楚地了解專案進度、分配任務、追蹤 Bug 等等。在還沒有工具之前，我們可能常常用 Excel、Trello 或甚至是口頭溝通，結果就是「欸，那個功能上次是誰說要做的？」或是「這個 Bug 修好了嗎？」之類的對話層出不窮，資訊非常分散。每一個工作項目都能被清楚地記錄與追蹤，讓整個開發流程變得更有條理；每一個工作項目都能被清楚地記錄與追蹤，讓整個開發流程變得更有條理。而原本今年鐵人賽想單純撰寫 SwiftUI App 的計畫，但想了一下，或許我可以嘗試把我使用 Azure DevOps 的經驗也融入其中，也是個不錯的結合。 什麼是 Azure Boards? Azure Boards 是一個基於網頁的服務，讓團隊可以一起規劃、追蹤和討論整個開發過程的工作，並且支援敏捷式方法。它提供了可自訂的平台來管理各種工作項目，讓團隊能夠有效協作並簡化工作流程。 如果用更白話的方式來說，Azure Boards 就像是「專案進度白板」的進化版。想像你和同事要一起做一個 App，大家會把要做的事情（像是設計畫面、寫程式、修 bug）一條一條寫在便利貼上，貼在牆上，然後每天早上一起討論誰要負責什麼、做完了沒。Azure Boards 就是把這種「便利貼牆」搬到網路上，而且還加了很多自動化和追蹤功能。 舉個實際例子，假設你們團隊要開發一個新的功能，大家可以在 Azure Boards 上建立一個「Issue」，分配給負責的人，設定截止日期，還能隨時更新進度。如果有 bug，直接開一個新的工作項目，標記為「Bug」，讓大家都知道目前有什麼問題需要解決。你可以根據專案規模選擇不同的流程（像是 Basic 或 Agile），小型團隊可以用最簡單的方式管理，大型團隊則能用更細緻的分工。 總結來說，Azure Boards 就是幫助團隊把所有待辦事項、進度、問題都集中管理，讓大家不會漏掉重要的事，也能清楚看到專案的整體進展。 依據團隊與專案的不同，Azure Boards 提供四種流程選擇： Agile：使用敏捷式規劃方法時使用，適合追蹤 User Story，並可選擇性地在面板上追蹤 Bug。 Basic：適合小型團隊或個人專案，簡化工作項目結構，讓管理更直觀。 Scrum：適合正式執行 Scrum。 CMMI：當小組遵循更正式的專案方法時選擇。 詳細可參考微軟說明。 我們公司是使用 Agile 流程，但在這個專案中，我會使用 Basic 流程來進行管理。因為這個專案的規模較小，且我主要是個人開發，所以 Basic 流程就足夠了。如果用 Agile 或 Scrum，會多出像 User Story、Feature、等這些工作項目類型，對我一個人來說反而有點太複雜了，Basic 的三層架構（Epic → Issue → Task）對我來說最直覺。如果想要進一步了解差異，可以參考微軟官方文件。 ...

前言 在昨天的內容中，我們學會如何利用 Core Location 搭配 MapKit 即時取得並標記用戶的位置。今天，我們將實作地理圍欄（Geofencing）技術，它不僅能偵測使用者是否進入或離開特定區域，還能結合本地通知即時提醒，我們的 App 之後也會用到這個技術。 什麼是 Geofencing？ Geofencing（地理圍欄）是一種以座標為中心、半徑為範疇的虛擬區域，透過 Core Location 框架自動監控使用者是否進入或離開該範圍，並能觸發事件通知，例如打卡、到站提醒、商圈推播都跟這個技術相關。 實作 介面設計 首先在 ContentView.swift 設計一個簡單的輸入區，供使用者自訂要監控的目標緯度與經度。 @State private var latitudeText: String = "" @State private var longitudeText: String = "" @State private var isMonitoring = false // 依據是否監控中，UI 隨之改變 // ... // MARK: - Geofencing 輸入介面 private var geofenceInputSection: some View { VStack(spacing: 12) { Text("設定地理圍欄") .font(.headline) HStack { TextField("緯度 (例: 25.033964)", text: $latitudeText) .keyboardType(.decimalPad) .textFieldStyle(.roundedBorder) TextField("經度 (例: 121.564468)", text: $longitudeText) .keyboardType(.decimalPad) .textFieldStyle(.roundedBorder) } HStack(spacing: 12) { Button(isMonitoring ? "正在監控中" : "建立地理圍欄") { startGeofencing() // 開始監控，待後面實作 } .disabled(isMonitoring || latitudeText.isEmpty || longitudeText.isEmpty) .buttonStyle(.borderedProminent) if isMonitoring { Button("停止監控") { stopGeofencing() // 停止監控，待後面實作 } .buttonStyle(.bordered) .foregroundColor(.red) } } if isMonitoring { Text("正在監控半徑100公尺的地理圍欄") .font(.caption) .foregroundColor(.secondary) } } .padding() .background(Color(.systemGray6)) .cornerRadius(12) } 為了讓 body 不要太肥，我們把這個輸入區域包在一個 geofenceInputSection computed property 裡，之後再只要像用變數一樣取用geofenceInputSection，直接把它放在 body 裡。 ...