前言：使用者在查詢頁選完條件後，這些條件如何被送進 ViewModel？

前一篇文章介紹到了 RoomRush 的首頁 Activity－MainActivity.kt ，除了負責載入首頁畫面之外，它還負責設定大樓下拉選單，並根據按鈕把使用者帶到查詢流程或管理者登入流程。

而今天的檔案就是要了解查詢頁的 UI 控制器－QueryResultActivity.kt ，它要負責接收首頁傳來的大樓條件、顯示星期/時段/樓層選單、把使用者選擇交給 ViewModel，再去做後面的處理。

在進入關鍵的查詢頁前，我們先劃分好邊界：現代 Android 開發強調「畫面（View）」與「商業邏輯（ViewModel）」的分離。
因此，今天登場的 QueryResultActivity.kt 只專注於 UI 呈現與選單互動；至於後台資料如何篩選、UI 狀態如何更新，這些綁定在 ViewModel 的邏輯不會在今天這篇提到，我們會留到下一篇文章處理。

一開始我認為

一開始設計查詢頁面時，我認為把大樓、星期、節次放在上方，提供使用者方便篩選自己的需求。下方顯示查詢結果，用 RecyclerView 呈現，讓 ViewModel 算出的空教室列表可以顯示出來，看起來更直覺（RecyclerView 的詳細內容會在下下一篇聊）。
其中 UI 設計了資料變動時會隨即更新列表，這功能花了很多時間和心力去完善，也是我認為最複雜的地方。

UI 畫面	操作流程

實際讀完後，QueryResultActivity.kt 負責什麼

和 Hermes 一起重讀檔案後，我理解到這個檔案是負責查詢頁 UI、Spinner、RecyclerView、點擊事件，以及和 ViewModel 連接。

這檔案負責三個查詢頁中關鍵的問題：

1. MainActivity 傳來的 building，是怎麼進到 ViewModel 的？

private val viewModel: QueryResultViewModel by viewModels {
    QueryResultViewModelFactory(
        (application as EmptyRoomFinderApp).appContainer.classroomScheduleRepository,
        this,
        intent.extras
    )
}

• 主要傳遞：MainActivity 傳來的資料在 intent.extras → 交給 Factory → ViewModel 再用 SavedStateHandle 拿到 building

2. 使用者選星期、時段、樓層後，Activity 如何交給 ViewModel？

viewModel.selectedDay.value = daySpinner.selectedItem.toString()
viewModel.selectedTime.value = timeSpinner.selectedItem.toString().substringBefore(" ")
viewModel.selectedFloor.value = floorSpinner.selectedItem.toString()

• 技術細節：Activity 讀取畫面目前選到的值，寫進 ViewModel 的查詢狀態。Spinner 是 UI，ViewModel 才是保存查詢條件與計算結果的地方。

3. ViewModel 算出 emptyRooms 後，Activity 如何更新畫面？

viewModel.emptyRooms.observe(this, Observer { rooms ->
    emptyRoomAdapter.updateRoomsAndAddHeaders(rooms)
})

• 技術細節：當 ViewModel 的 emptyRooms 改變時，Activity 收到資料變動通知，交給 Adapter 更新列表（RecyclerView）。

它接在哪一條流程上

前往 QueryResultActivity 後，之後的流程可以簡化成：

QueryResultActivity.kt
    ↓
接收 building
    ↓
建立 QueryResultViewModel
    ↓
使用者選擇 星期 / 時段 / 樓層
    ↓
更新 ViewModel 的查詢條件

Hermes Agent 幫我檢查出的重點

QueryResultActivity 是 RoomRush 查詢頁的 UI 控制器。它接收首頁傳來的大樓條件，設定星期、時段、樓層三個 Spinner，並在使用者改變選項時，把目前選到的值寫進 QueryResultViewModel。

• 真正的空教室計算不在 Activity 裡，而是在 ViewModel 裡。
• Activity 只負責觀察 emptyRooms，當結果變動時呼叫 Adapter 更新 RecyclerView。
• 當使用者點擊某間空教室時，Activity 會用 Intent 開啟 RoomDetailActivity，並把教室名稱傳到詳細頁。

小結

讀到 QueryResultActivity 時，我開始看見 Android 專案裡 UI 和資料邏輯的分工。
這個 Activity 看起來很忙：它要設定星期、時段、樓層三個下拉選單，也要設定 RecyclerView，還要處理點擊教室後跳到詳細頁。
但仔細拆開後會發現，它真正負責的是「收集使用者操作」和「更新畫面」，不是直接計算哪些教室是空的。

用一句話總結這檔案，我會說：

QueryResultActivity 負責收集查詢條件與更新畫面，真正的空教室計算交給 QueryResultViewModel。

下一篇預告：空教室到底怎麼算？我從 ViewModel 找答案

讀完 RoomRush 的核心畫面之後，接下來就要帶到前言所提到的核心－ 查詢頁背後的狀態與查詢邏輯中心－QueryResultViewModel.kt 。

一個 UI 介面設計得再精美，如果沒有背後的邏輯支撐，充其量只是一個無法互動的靜態外殼。

下一篇，我們將深入剖析這些在介面上選好的「星期、時段、樓層」條件，到底是如何被送進 ViewModel，並一步步轉化為精準的空教室查詢結果。