Android 開發經驗

最後更新日期：2026 年 8 月 10 日

Aline（com.wwwaline.calendar）是我第一個 Android 應用程式， 由我一人從後端、Android 用戶端到部署架構獨立開發，目前仍在開發與封閉測試階段。 以下說明這個 App 的實際技術組成與開發過程——比起列出頭銜，我認為直接交代做了什麼、 在 Android 平台上踩過哪些具體問題，更能說明我的開發經驗。

一、應用程式概述

Aline 解決的問題是：約時間幾乎都發生在 LINE 對話裡，但沒有人會回頭把它抄進行事曆。 這個 App 由三個部分組成——一個接收 LINE 訊息的 Bot 後端、一套把自然語言對話轉成結構化行程的擷取流程， 以及一個給使用者確認、檢視與管理行程的 Android 用戶端。

Android 用戶端

Flutter（Dart），約 56 個 Dart 原始檔、15 個功能頁面，含月曆／日檢視、待確認收件匣、搜尋、設定與訂閱頁

後端

Node.js + Express + Prisma ORM + PostgreSQL，共 16 個功能模組（認證、行程、衝突偵測、通知、匯出、訂閱等）

外部整合

LINE Messaging API（Webhook 收訊與簽章驗證）、Firebase Cloud Messaging（推播）、LLM 服務（對話擷取）

開發規模

2026 年 8 月起持續開發，逾 100 次版本提交；後端 15 組測試套件、Android 用戶端 28 支 widget／單元測試

二、Android 平台相關的實作

推播通知與通知頻道

App 使用 Firebase Cloud Messaging 傳送四種通知：行程提醒、行程異動、每日摘要，以及其他系統通知。 這四種在 Android 端分屬四個獨立的 Notification Channel，使用者可以在系統設定裡分別關閉某一類， 而不是只能全部關掉。後端依訊息的 data.type 指定要落在哪個頻道； AndroidManifest.xml 另外宣告了一個 catch-all 預設頻道， 避免將來新增通知型別而前後端尚未對齊時，訊息掉進系統的 fcm_fallback_notification_channel—— 那個頻道的顯示名稱是「Miscellaneous」且預設靜音，使用者會完全收不到。

通知點擊的深層連結

點擊推播不是只把 App 打開，而是直接跳到對應的那一筆行程。這需要處理三條不同的進入路徑： App 在前景時、在背景被喚醒時，以及完全終止後由通知冷啟動時——最後一條要在啟動流程中 主動去取「開啟 App 的那則通知」，否則導向資訊會遺失。三條路徑都已在實機上逐一驗證通過。

建置設定

本地通知函式庫相依於 java.time，在 minSdk 低於 26 的裝置上必須啟用 core library desugaring 才能建置成功，否則建置階段就直接失敗。 專案因此開啟 isCoreLibraryDesugaringEnabled 並加入 desugar_jdk_libs 相依，同時將 Java／Kotlin 目標統一在 JVM 17。

版面與相容性

行事曆這類資訊密度高的畫面在窄螢幕上特別容易出問題。開發過程中修過 AppBar 在窄寬度下的 RenderFlex 溢位，之後補上針對窄視窗的 widget 測試，讓同一類版面問題在提交前就被擋下。 App 同時支援淺色與深色主題。

三、開發與驗證方式

• 實機驗證，不只看單元測試通過。推播管線在實體 Android 裝置上完整驗證過： 前景接收、背景喚醒、四個通知頻道各自的行為，以及點擊後的導向。 這個過程實際找出了四個單元測試不可能發現的缺陷。
• 對外部行為以實測為準。LINE Webhook 的訊息結構（貼圖、表情符號、群組事件） 以實際收到的封包為準來實作，而不是依照文件推測；過程中修正過數個原先寫在設計文件裡的錯誤假設。
• 本地開發環境可對外收訊。透過 Cloudflare Tunnel 將本機後端接上正式網域， 讓 LINE 平台的 Webhook 能打到開發中的程式碼，取得真實請求進行除錯。
• 每個功能變更都要測試全綠再提交。後端與 Android 用戶端兩邊的測試套件都要通過， 才視為完成，並以獨立的一次提交收尾。

四、目前進度與後續規劃

後端功能、Android 用戶端主要畫面與推播管線均已完成並可運作，Android APK 可正常建置與安裝。 接下來的工作是完成訂閱與付費流程、將後端從本地開發環境遷移到正式主機與代管資料庫， 並依 Google Play 的要求完成封閉測試後再申請正式上架。