Tap2Go：我人生中第一個做的 App

Tap2Go 是我去年暑假練習 Flutter 時做的小作品，也是我人生第一個自己做出來的 App。

它不是一個一開始就打算完整上架的 App，也沒有很複雜的產品規劃。比較準確地說，它是我當時用來熟悉 Flutter 開發流程、介面組成、頁面切換、元件拆分與互動效果的練習專案。

回頭看，Tap2Go 對我來說最重要的地方，不是它做了多厲害的功能，而是它讓我第一次比較完整地走過一次 App Demo 的開發流程。

它讓我從「看 Flutter 教學」往前走了一步，開始真的自己組出一個可以操作、可以切換、也能跑進手機裡的 App。

專案起點：光是裝環境就卡很久

當時會做 Tap2Go，主要是因為我想真正理解 Flutter App 是怎麼組成的。

但在真正開始寫之前，光是環境安裝就花了我大概 2 到 3 個月。

那時候不像現在可以直接問 AI，遇到錯誤訊息也不太知道要怎麼拆。看書常常看不懂，網路上的資料也沒有現在這麼多、這麼好找。

更麻煩的是，我剛好一開始就遇到 Flutter 這種對新手不算太友善的前端框架。不是說 Flutter 不好，而是對當時的我來說，從 SDK、Android Studio、模擬器、環境變數，到裝置偵測，每一關都像在解任務。

所以 Tap2Go 對我來說不只是第一個 App，它也是我第一次真正體會到：寫程式以前，先把開發環境裝好本身就是一場硬仗。

如果只是看教學照著打，其實很容易覺得自己好像懂了。但真的要自己把畫面組起來時，才會發現很多細節不是看過就會。

例如 AppBar 要怎麼跟頁面狀態連動、底部導覽列怎麼切換頁面、Drawer 和 EndDrawer 要怎麼放進整體外殼、PageView 又該怎麼跟目前選中的頁面同步。

這些元件單獨看都不難，但把它們組成一個像樣的 App 首頁，就開始需要理解整個畫面的結構。

所以 Tap2Go 的目標很單純：

• 熟悉 Flutter 常見 UI 元件
• 練習 App 頁面切換
• 嘗試拆分畫面與共用版面
• 加入簡單互動回饋
• 完成一次 Android APK Release 流程

它不是為了解決某個很大的使用者問題，而是為了讓我把 Flutter 的基本開發流程真的跑過一遍。

從 C 到 Dart：第一次接觸 OOP

做 Tap2Go 的時候，我其實才剛學過 C。

那時候寫的程式碼大多很小、很短，比較像是練習變數、迴圈、條件判斷、函式這些基礎概念。

結果一碰到 Flutter 和 Dart，畫風完全不一樣。

Flutter 的程式碼常常是一層包一層，Widget 裡面還有 Widget，大括號、括號和縮排一直往下疊。現在知道那是宣告式 UI 和 widget tree，但當時看起來真的很像被無限巢狀大括號包圍。

說實話，一開始滿崩潰的，但也有一種很奇怪的療癒感。因為畫面是靠這些結構一層一層堆出來的，只要順利跑起來，就會覺得：「哇，原來這一大坨真的會變成 App 畫面。」

這也是我第一次接觸到比較完整的物件導向程式語言。

以前在 C 裡面，我比較常思考的是資料怎麼傳、函式怎麼寫。但到了 Dart，我開始碰到 class、object、constructor、override、state 這些概念。

Tap2Go 讓我第一次感受到，寫 App 不只是把指令照順序寫完，而是要把畫面、狀態和物件之間的關係組織起來。

核心功能：多頁面切換

Tap2Go 的核心功能是多頁面切換。

我使用 BottomNavigationBar 搭配 PageView，讓使用者可以在首頁、用戶、訊息、分類、設定等頁面之間切換。

這個功能看起來很基本，但對剛開始學 Flutter 的我來說，其實是很好的練習。因為它不是只把幾個頁面放出來而已，還要處理目前頁面的狀態、導覽列選中的項目，以及畫面切換時的同步問題。

我也讓 AppBar 和底部導覽列的顏色跟著不同頁面變化，讓切換時有一點動態感，而不是只是把內容換掉。

這讓我開始理解 UI 不是只有「畫面有沒有出現」，狀態變化和視覺回饋也會影響使用者對 App 的感覺。

互動回饋：讓操作有感覺

除了頁面切換，我也加入了音效互動。

例如點擊按鈕或切換頁面時，App 會播放簡單的音效。這個功能本身不算大，但它讓我第一次開始注意到「操作回饋」這件事。

以前做畫面時，我可能只會在意按鈕按下去有沒有反應、頁面有沒有切過去。

但加入音效後，我開始意識到使用者操作 App 時，感受到的不只是畫面變化，也包含聲音、動畫、延遲、按鈕回饋這些細節。

一個 App 好不好用，不只取決於功能有沒有完成，也取決於使用者操作時有沒有得到清楚的回饋。

這件事對後來做其他 Flutter 專案也有幫助。因為我開始比較會思考：使用者按下這個按鈕之後，畫面應該怎麼回應？狀態要不要變？需不需要提示？會不會讓人以為沒有反應？

專案結構：開始練習拆分程式碼

Tap2Go 也讓我開始理解 Flutter 專案的基本結構。

當時我有嘗試把不同功能拆到不同資料夾，例如：

• pages：放主要頁面
• layout：放共用外殼與整體版面
• utils：放音效相關工具
• assets：放音效與其他靜態資源

現在回頭看，這個結構一定還有很多可以改進的地方。像是狀態管理、路由管理、元件命名、資料夾邊界，都還可以更清楚。

但以當時的學習階段來說，這是一個很重要的起點。

因為我不再只是把所有東西塞在同一個檔案裡，而是開始思考哪些東西可以共用、哪些東西應該拆出去、哪些功能應該有自己的位置。

這個專案讓我開始從「能跑就好」慢慢轉向「程式碼要能整理、能閱讀、也能繼續改」。

第一次跑進手機裡

Tap2Go 還有一個對我來說滿重要的部分，就是我有把它打包成 Android APK。

雖然只是練習作品，但從開發到 release，整個流程走完一次，感覺和只在模擬器上跑起來不太一樣。

當 App 真的被包成一個可以安裝的檔案時，我會更明確感受到：這不是只有一段程式碼，而是一個可以被拿來操作的 App Demo。

第一次看到 Tap2Go 真的跑進手機裡時，我超級興奮。

那種感覺跟在電腦上看結果完全不同。手機螢幕上出現自己寫出來的 App，按下去會切頁、會有反應、還會播放音效，那一刻真的會覺得前面卡環境、看不懂文件、被大括號轟炸都值得了。

後來我還把它裝到很多家人的手機裡。

雖然現在回頭看，那只是很早期的練習 App，但對家人來說，他們看到我竟然可以做出一個能安裝在手機上的東西，反應都滿驚訝的。甚至會覺得我好像潛力無窮。

現在想起來有點好笑，但那個肯定感對當時的我很重要。

第一次把自己寫的 App 裝進真實手機裡，會讓「我正在學寫程式」突然變成「我真的做出了一個東西」。

這個過程也讓我開始接觸到 Flutter build、Android 設定、APK 輸出等流程。即使當時理解還不深，但至少知道一個 App 從開發到可安裝檔案，中間還有一段需要處理的發布流程。

專案反思：它完成了學習任務

Tap2Go 對我來說不是成熟產品，而是一個學習紀錄。

如果用現在的角度回頭看，它當然還有很多可以改進的地方。

例如 UI 設計可以更一致、頁面功能可以更完整、狀態管理可以更正式、路由系統也可以用更清楚的方式處理。

但我不覺得這代表它沒有價值。

因為 Tap2Go 在當時完成了它最重要的任務：讓我第一次比較完整地把 Flutter App 從環境安裝、畫面、互動、資料夾結構，到 APK Release 都走過一遍。

它不是一個成熟產品，但它是我開始把 Flutter 從「教學內容」變成「自己可以動手做」的重要練習。

如果現在重新做一次

如果現在要重新做一次 Tap2Go，我可能會調整幾個方向。

首先，我會讓 UI 設計更有一致性。包含顏色、間距、字級、圖示風格和頁面層級，都會先整理出比較清楚的設計規則。

再來，我會加入更正式的狀態管理與路由系統。當頁面數量變多時，只靠簡單的變數和頁面切換邏輯，很容易讓程式碼變得難維護。

我也會更重視元件拆分，不只是把頁面拆出去，而是把可以重複使用的 UI 元件整理成更清楚的 component。

但即使現在有更多想法，我還是覺得 Tap2Go 很適合放在作品集裡當作早期學習紀錄。

它不是用來證明我已經做出多完整的產品，而是用來記錄我當時怎麼開始理解 Flutter App 的基本架構。

技術重點

• Flutter / Dart
• Dart OOP 基礎
• Material Design UI
• PageView 多頁面切換
• BottomNavigationBar 底部導覽列
• Drawer / EndDrawer 側邊欄
• AppBar 動態變色
• audioplayers 音效互動
• Android APK Release

結語：第一個完整 Demo 的意義

Tap2Go 是一個很早期、也很單純的 Flutter 練習專案。

它沒有複雜後端，也沒有完整產品策略，但它讓我第一次真的把 App 的畫面、導覽、互動、結構和打包流程串起來。

這對當時的我來說很重要，因為它是我人生第一個自己做出來、真的可以安裝到手機裡的 App。

因為從那之後，我在做其他 Flutter 專案時，對畫面組件、頁面切換和 App 架構有了更清楚的概念。

Tap2Go 最大的價值，不是它本身有多完整，而是它讓我跨過了從「學 Flutter」到「用 Flutter 做出東西」的那一步。