แผนการเรียนรู้
/
Flutter Mobile Dev | Week 11 • Part 1

ยินดีต้อนรับสู่การพัฒนามือถือครึ่งเทอมหลัง

🎯 สารบัญหมวดที่ 1: แนะนำวิชาและเป้าหมายหลังกลางภาค

💡 คำชี้แนะ: คลิกที่เมนูเพื่อเลือกศึกษาแต่ละสไลด์ หรือใช้ปุ่มควบคุมด้านล่างเพื่อไล่ดูเนื้อหาทีละหน้า
Slide 1 • Introduction

ยินดีต้อนรับสู่ครึ่งเทอมหลัง!

ในครึ่งเทอมแรก นักศึกษาได้เรียนรู้พื้นฐานการออกแบบหน้าจอและ Widget เบื้องต้นใน Flutter มาแล้ว สำหรับครึ่งเทอมหลังนี้ เราจะก้าวไปอีกขั้นสู่ "การพัฒนาแอปพลิเคชันระดับมืออาชีพ"

🚀 สิ่งที่เราจะมุ่งเน้นนับจากนี้:

  • การจัดการสถาปัตยกรรมแอปพลิเคชันขนาดใหญ่ด้วยสไตล์ MVVM ของทีมงาน Google
  • การต่อเชื่อมระบบหลังบ้านจริงด้วย Django REST Framework
  • การรักษาความปลอดภัยขั้นสูงด้วยระบบ JWT Token Rotation
🎓

เป้าหมายหลัก

พัฒนานักศึกษาจากการเขียนโค้ดหน้าจอเดี่ยว สู่การออกแบบระบบแอปพลิเคชันที่สามารถเชื่อมต่อ API และทำงานร่วมกันในทีมได้จริง

Slide 2 • Curriculum Roadmap

เส้นทางการเรียนรู้ 5 สัปดาห์

1
สัปดาห์ที่ 1 (วันนี้): ทบทวนพื้นฐาน Flutter & เจาะลึกการแบ่งเลเยอร์สถาปัตยกรรมแอป
2
สัปดาห์ที่ 2: พัฒนาหลังบ้าน Django REST Framework + ระบบล็อกอิน JWT Secure Rotation
3
สัปดาห์ที่ 3: ลุยเขียน Data Layer ฝั่ง Flutter สื่อสารผ่าน REST API & จัดการเก็บ Token ถาวร
4
สัปดาห์ที่ 4: พัฒนา UI Layer แบบ MVVM เต็มขั้น ทำความเข้าใจและเขียนชุดคำสั่ง Command Pattern
5
สัปดาห์ที่ 5: ประกอบวงจรด้วย Dependency Injection (DI), ทำชุดทดสอบจำลอง (Test Fakes)
5-Week Flutter & Django Learning Roadmap
🗺️ แผนภาพแสดงเส้นทางการเรียนรู้ตลอด 5 สัปดาห์ถัดจากนี้
Slide 3 • Target Project

แอปเป้าหมาย: Compass App

โปรเจกต์หลักของเราคือ Compass App (แอปบันทึกตารางการเดินทางและการจองทริป) ซึ่งดัดแปลงโครงสร้างมาจากแอปพลิเคชันต้นแบบระดับ Production ของทีมผู้พัฒนา Flutter เพื่อให้มั่นใจว่านักศึกษาจะได้จับงานที่ใกล้เคียงการทำงานจริงที่สุด

🔧 คุณสมบัติเด่นของแอปพลิเคชัน:

  • การสลับสภาพแวดล้อมจำลอง (Local JSON / Background Server API)
  • ฟังก์ชันการทำงานครบวงจร: ตารางทริป, คลังกิจกรรม และตารางจอง
  • รองรับสถาปัตยกรรมแบบแยกเลเยอร์เพื่อเพิ่มระดับการทำ Test Coverage
📁 ตรวจสอบโปรเจกต์บน GitHub (คลิกเพื่อเปิด)
Compass App UI Mockup
หน้าตาและส่วนหน้าต่างแสดงผล UI ของแอปพลิเคชัน Compass (แอปเป้าหมาย)
Flutter Mobile Dev | Week 11 • Part 2

ทบทวนพื้นฐาน Flutter & UI State

🎯 สารบัญหมวดที่ 2: ทบทวนพื้นฐาน Flutter & UI State

💡 คำชี้แนะ: คลิกที่เมนูเพื่อเลือกศึกษาแต่ละสไลด์ หรือใช้ปุ่มควบคุมด้านล่างเพื่อไล่ดูเนื้อหาทีละหน้า
Slide 4 • StatelessWidget vs StatefulWidget

ความแตกต่างของโครงสร้างหน้าจอ

ในการพัฒนาอินเตอร์เฟซด้วย Flutter ส่วนประกอบของหน้าจอจะถูกประกอบขึ้นจาก Widget ซึ่งถูกออกแบบให้มีขนาดเล็กและสามารถนำมาใช้งานซ้ำได้ . โดยระบบแบ่ง Widget พื้นฐานออกเป็นสองประเภทหลัก:

🔵 StatelessWidget

หน้าจอที่ทำงานแบบไร้สถานะ (Immutable) โดยข้อมูลที่ถูกกำหนดผ่านทาง Constructor จะไม่สามารถเปลี่ยนแปลงค่าได้ตลอดอายุการทำงาน . เหมาะสำหรับหน้าจอแสดงผลคงที่ .

🟡 StatefulWidget

หน้าจอที่มีการเปลี่ยนแปลงข้อมูลภายในตัวแอปพลิเคชัน (Mutable State) ซึ่งเมื่อมีการเปลี่ยนแปลงข้อมูลใด ๆ ระบบจะทำการวาดหน้าจอใหม่ (Rebuild) ทันที .

🔗 ศึกษาข้อมูลเพิ่มเติมได้ที่: https://docs.flutter.dev/development/ui/widgets
StatelessWidget vs StatefulWidget Infographic
แผนภาพจำลองการทำงานและสิทธิ์การเปลี่ยนแปลงค่าภายในของ Widget ทั้งสองระบบ
Slide 5 • Declarative UI Concepts

แนวคิด UI is a function of state

Flutter ทำงานอยู่บนแนวคิดเชิงประกาศ (Declarative UI) ซึ่งหมายความว่าระบบจะทำงานโดยการสะท้อนสถานะ (State) ล่าสุดออกมาเป็นภาพอินเตอร์เฟซบนหน้าจอ .

เมื่อสถานะหรือชุดข้อมูลหลักมีการอัปเดตเกิดขึ้น ตัวแอปพลิเคชันจะกระตุ้นคำสั่งการ Rebuild หน้าจอส่วนที่เกี่ยวข้องทั้งหมดขึ้นมาทดแทนส่วนเดิม .

สมการที่เป็นหัวใจหลักในการวาดหน้าจอของ Flutter ถูกนิยามไว้คือ:

UI = f(State)

นอกจากนี้ การออกแบบให้เลเยอร์ตัวกลางส่งผ่านสถานะที่เป็นข้อมูลประเภทที่ไม่สามารถเปลี่ยนแปลงค่าได้ (Immutable State) จะช่วยลดโอกาสเกิดบั๊กและปัญหาการแก้ไขข้อมูลที่ผิดรูปในระบบลงได้ .

🔗 ศึกษาข้อมูลเพิ่มเติมได้ที่: https://docs.flutter.dev/data-and-backend/state-mgmt/declarative
UI is a function of state Infographic
การป้อนข้อมูลสถานะ (State) เข้าสู่ฟังก์ชันประมวลผลเพื่อแปลงเป็นหน้าต่างผู้ใช้งานแบบอัตโนมัติ
Slide 6 • Internal State & setState

การจัดการสถานะภายในด้วย setState

การใช้งานฟังก์ชัน setState เป็นกลไกเริ่มต้นและง่ายที่สุดในการบริหารจัดการสถานะชั่วคราว (Ephemeral State) ที่ทำงานอยู่เฉพาะตัวแปรภายในหน้าจอคอมโพเนนต์เดี่ยว .

1

เมื่อคำสั่งถูกเรียกใช้เพื่อแก้ไขสถานะหรือค่าพารามิเตอร์ภายใน ตัวแอปพลิเคชันจะกระตุ้นคำสั่งการ Rebuild โดยสั่งรันเมธอด build ของ Widget นั้น ๆ อีกครั้งทันที .

⚠️

ข้อจำกัดสำคัญ: เมื่อแอปพลิเคชันมีขนาดใหญ่และเริ่มแบ่งเป็นโครงสร้างหน้าจอซ้อนกันลึก ๆ การนำสถานะภายในไปแบ่งปันข้อมูลให้กับ Widgets ตัวอื่นที่อยู่ภายนอกจะทำได้ยากและทำให้โค้ดพันกันอย่างยุ่งเหยิง .

🔗 ศึกษาข้อมูลเพิ่มเติมได้ที่: https://docs.flutter.dev/data-and-backend/state-mgmt/intro
Slide 7 • Why App Architecture?

ทำไมต้องออกแบบสถาปัตยกรรมแอปพลิเคชัน? 🏗️

เมื่อขนาดของโปรเจกต์เติบโตขึ้นเรื่อย ๆ การพัฒนาโดยปราศจากการควบคุมย่อมก่อให้เกิดผลเสียอย่างรุนแรง การนำ **สถาปัตยกรรม (Architecture)** มาประยุกต์ใช้งานจะช่วยป้องกันการเขียนโค้ดที่รกรุงรังและช่วยเพิ่มคุณภาพของโปรแกรมในแง่มุมต่าง ๆ :

🤝 Scalability

ช่วยกำหนดขอบเขตและหลักการแยกส่วนงาน (Separation of Concerns) ทำให้ทีมพัฒนาสามารถเขียนและแก้ไขระบบไปพร้อมกันได้โดยไม่เกิดปัญหาโค้ดชนกัน (Code Conflicts) .

🔄 Extensibility

แอปพลิเคชันจะมีความยืดหยุ่นสูง การเพิ่มความสามารถหรือฟีเจอร์ใหม่ ๆ เข้าไปภายหลังจะทำได้สะดวก รวดเร็ว และไม่มีความเสี่ยงที่จะพังระบบประมวลผลภายในส่วนอื่น ๆ .

🧪 Testability

เพิ่มขีดจำกัดในการวางชุดทดสอบ (Unit & Widget Tests) เพราะการจัดข้อมูลเป็นระบบชั้นทำให้คุณสามารถใช้ "ข้อมูลจำลอง" ทดสอบลอจิกแต่ละส่วนได้ทันทีโดยไม่ต้องเชื่อมต่อข้อมูลเน็ตเวิร์กของจริง .

🔗 ศึกษาข้อมูลเพิ่มเติมได้ที่: https://docs.flutter.dev/app-architecture
Flutter Mobile Dev | Week 11 • Part 3

สถาปัตยกรรม MVVM & โครงสร้าง Compass App

🎯 สารบัญหมวดที่ 3: สถาปัตยกรรมและการจัดรูปโฟลเดอร์

หลักการที่ 1: Separation of Concerns (การแยกหน้าที่ความรับผิดชอบ) :

การเขียนโค้ดที่ดีต้องแยกความรับผิดชอบออกจากกันอย่างชัดเจน โดยการแบ่งแอปพลิเคชันออกเป็น ชั้นเลเยอร์ (Layered Architecture) ซึ่งแต่ละเลเยอร์จะมีหน้าที่และขอบเขตการทำงานเฉพาะตัวที่ชัดเจน เพื่อไม่ให้ลอจิกของหน้าจอปนเปกับข้อมูลดิบ

🔗 ศึกษาหลักการสถาปัตยกรรมเพิ่มเติม: https://docs.flutter.dev/app-architecture/concepts
Slide 10 • SSOT & Unidirectional Data Flow

การไหลเวียนของข้อมูลแบบทิศทางเดียว (UDF)

เพื่อป้องกันไม่ให้ข้อมูลสถานะของแอปเกิดความซ้ำซ้อนหรือมีค่าไม่ตรงกัน สถาปัตยกรรมที่ถูกต้องจะต้องยึดหลักการจัดเก็บสถานะไว้ที่ "แหล่งความจริงที่หนึ่งเดียว" (Single Source of Truth - SSOT) ซึ่งสำหรับแอป Flutter แหล่งความจริงนี้จะกักเก็บอยู่ที่เลเยอร์ข้อมูล (Data Layer - Repositories) เสมอ

🔄 วงจรการไหลของข้อมูล (UDF Lifecycle) :

  1. ผู้ใช้งานกระตุ้น Event: เกิดการ swipe หรือกดปุ่มบนหน้าจอ View
  2. ViewModel รับคำสั่ง: View เรียกคำสั่งการทำงาน (Command) ของ ViewModel
  3. Repository อัปเดตข้อมูล: ViewModel สั่งให้ Repository ดำเนินการปรับแก้ข้อมูลดิบ
  4. ข้อมูลใหม่ไหลย้อนขึ้นมา: ข้อมูลที่อัปเดตแล้วถูกส่งกลับจากเลเยอร์ Data ไปยัง ViewModel เพื่อวาดหน้าจอ (Rebuild UI) ใหม่ด้วยสถานะที่ไม่สามารถแก้ไขค่าได้ (Immutable State)
Unidirectional Data Flow & MVVM in Flutter
🔄 แผนผังแสดงการไหลเวียนของสถานะขึ้นสู่หน้าจอ และการส่ง User Events ไหลลงสู่ Repository
Slide 11 • MVVM Pattern in Compass App

โครงสร้างโมเดล MVVM ของแอปพลิเคชัน Compass

แอปพลิเคชัน Compass ออกแบบตามโครงสร้าง Model-View-ViewModel (MVVM) ของผู้พัฒนา Flutter เพื่อสาธิตการพัฒนาในระดับที่ใช้งานได้จริง (Production-Grade):

🖼️ Views (UI Layer)

คือคลาสวิดเจ็ตต่างๆ ใน Flutter (เช่น HomeScreen) ทำหน้าที่เป็นผู้รับข้อมูลแสดงผลจาก ViewModel เพียงอย่างเดียว และเชื่อมผู้ใช้เข้ากับระบบด้วย UI ปราศจากการคำนวณทางตรรกะ

⚙️ ViewModels (UI Layer)

คือคลาสจัดการสถานะหน้าจอ เช่น HomeViewModel คอยแปลงข้อมูลดิบจากคลังเก็บให้อยู่ในสภาพพร้อมระบายบนจอ และเปิดคำสั่ง "Commands" ให้กับเลเยอร์ View เรียกใช้งาน

📦 Model (Data Layer)

คือคลาส Repositories และ Services ทำหน้าที่ดูแลฐานข้อมูลทริปการท่องเที่ยว เชื่อม API ดิบ และแปลงให้เป็นวัตถุของขอบเขตงานจริง (Domain Models) เพื่อเป็นแหล่งข้อมูลที่เชื่อถือได้แหล่งเดียว

🔗 เจาะลึกกรณีศึกษา MVVM บนเว็บบอร์ดหลัก: https://docs.flutter.dev/app-architecture/case-study
Slide 12 • Folder & Package Structure

การจัดโครงสร้างแฟ้มข้อมูลโฟลเดอร์สไตล์โปรดักชัน

lib/

├── data/ // จัดระเบียบตาม "ประเภทข้อมูล" (ไม่จำกัดฟีเจอร์)

├── model/ # ApiClient Models (e.g. UserApiModel)

├── repositories/ # (e.g. booking_repository_remote.dart)

└── services/ # Stateless Network clients (e.g. api_client.dart)

├── domain/ // สำหรับประเภทข้อมูลส่วนกลางของระบบแอป

└── models/ # Pure Domain Models (e.g. Booking, User)

├── ui/ // จัดระเบียบตาม "ฟีเจอร์การใช้งาน"

├── core/ # Shared Widgets & Brand Themes

└── <feature_name>/ # (e.g. home/ หรือ auth/)

├── view_models/ # (e.g. home_viewmodel.dart)

└── widgets/ # (e.g. home_screen.dart, logout_button.dart)

└── main.dart / main_development.dart / main_staging.dart

แอปพลิเคชันระดับใหญ่จะผสมผสานรูปแบบการจัดโครงสร้างแฟ้มข้อมูลสองประเภทเข้าด้วยกันอย่างเหมาะสม :

  • แบ่งตามประเภท (By Type): นำไปปรับใช้กับเลเยอร์ data/ เพราะคลังเก็บ (Repository) และ Services ต่างๆ ต้องพร้อมใช้งานแบบแบ่งปันกันข้ามไปยังหลายๆ ฟีเจอร์ทั่วแอปพลิเคชันได้
  • แบ่งตามฟีเจอร์ (By Feature): นำไปปรับใช้กับเลเยอร์ ui/ เพราะชุดแสดงผล View และตัวจัดการสถานะ ViewModel มักจะทำงานสอดรับเป็นคู่แบบจำเพาะเจาะจงกันเสมอ
Slide 13 • Rules of Engagement

กฎเหล็กการเชื่อมโยงและการสื่อสารระหว่างเลเยอร์

เพื่อรักษาหลักการแยกความรับผิดชอบ (Separation of Concerns) ไม่ให้โค้ดพันกันจนส่งผลเสียต่อการตรวจสอบและการบำรุงรักษา ทุกเลเยอร์ต้องเคารพกฎความสัมพันธ์ (Rules of Engagement) อย่างเคร่งครัด:

คอมโพเนนต์ กฎการเชื่อมโยงข้อมูล (Rules of Engagement)
View จะรู้จักและติดต่อผ่านทาง ViewModel ของตัวเองเพียงแค่ตัวเดียวเท่านั้น และต้องไม่ข้ามเลเยอร์ไปรู้จักหรือเรียกข้อมูลจาก Repository หรือ Service โดยตรงเด็ดขาด
ViewModel เชื่อมต่อและสื่อสารเข้ากับ Repository ตั้งแต่ 1 ตัวขึ้นไป ผ่านทางคอนสตรักเตอร์ของตัวเอง แต่ตัวมันจะไม่มีวันรู้จักกับเลเยอร์ View ที่คอยอ่านสถานะของมันอยู่
Repository ควบคุมและทำงานประสานกับ Service ต่างๆ ในการแปลงข้อมูลดิบ และถูกเรียกใช้งานต่อโดย ViewModels หลายๆ ตัวได้ โดยที่ตัวมันไม่มีสิทธิ์รู้ตัวตนของ ViewModels เลย
Service เป็นคลาสไร้สถานะ (Stateless) ที่มีบทบาทห่อหุ้ม API ภายนอก โดยทำงานรับใช้คลังเก็บข้อมูล และ ไม่มีวันรับรู้ความมีอยู่ของเลเยอร์อื่นใดเลย
Slide 14 • Deep Dive: Presentation Layer (UI)

เจาะลึกเลเยอร์แสดงผล: Views & ViewModels

🖼️ เลเยอร์ View ( Stateless UI )

วิดเจ็ตในเลเยอร์นี้ (เช่น StatelessWidget) จะประหยัดพลังงานหน่วยความจำ และ ไม่มีลอจิกทางธุรกิจอยู่ภายในเลย โดยมีหน้าที่ดึงข้อมูลสถานะจาก ViewModel มาระบายวาดลงหน้าจอผ่านทางตัวสร้างสัญญาณรีเฟรชเฉพาะส่วน ListenableBuilder

ตรรกะที่อนุญาตให้มีได้ในหน้าจอนี้ มีเพียงแค่การสั่งเปิด-ปิดแอนิเมชัน หรือการจัดเลย์เอาต์ตามขนาดหน้าจอและทิศทางการหมุนของเครื่องโทรศัพท์เท่านั้น

⚙️ เลเยอร์ ViewModel ( State & Commands )

เป็นคลาสจัดสรรตรรกะของหน้าจอ โดยมีการสืบทอดความสามารถมาจาก ChangeNotifier คอยประกาศฟังก์ชัน Command Objects (เช่น Command0 และ Command1) เพื่อให้หน้าจอ Views สั่งงานได้อย่างปลอดภัยไร้บั๊ก

มีหน้าที่คอยจับตาเฝ้าดูความเปลี่ยนแปลงข้อมูลสถานะ เมื่อระบบดึงข้อมูลสำเร็จเสร็จสิ้น จะเรียกใช้คำสั่ง notifyListeners() เพื่อส่งผ่านการ Rebuild ชิ้นส่วนหน้าจอโดยอัตโนมัติ

🔗 ศึกษารายละเอียดสถาปัตยกรรมชั้นแสดงผล UI ในเชิงปฏิบัติ: https://docs.flutter.dev/app-architecture/case-study/ui-layer
Slide 15 • Deep Dive: Data Layer

เจาะลึกเลเยอร์ข้อมูลเบื้องหลัง: Repositories & Services

📦 เลเยอร์ Repository ( Single Source of Truth )

คลังข้อมูลหลักที่เป็นแหล่งความจริงหนึ่งเดียวในการเก็บและแปลงข้อมูลทริปเดินทาง มีบทบาทสำคัญในการควบคุมและจัดเก็บลอจิกการอัปเดตข้อมูล การทำ Caching ระบบการจัดสรรข้อผิดพลาด ตลอดจนการทำซ้ำคำสั่งที่ล้มเหลว (Retry Logic)

จะประมวลผลดึงค่า JSON จาก Services และขัดเกลากรองข้อมูลดิบให้กลายเป็น "Domain Models" ที่สมบูรณ์และปลอดภัย เพื่อส่งผ่านต่อไปให้หลายๆ ViewModels ในระบบเรียกใช้งาน

🔌 เลเยอร์ Service ( Stateless HTTP Client )

คลาสทำงานที่เป็นศูนย์รวมชุดคำสั่ง API เชื่อมโยงข้อมูลเน็ตเวิร์ก มีหน้าต่างรับผิดชอบเพียงขอบเขตเดียวคือการติดต่อเพื่อดึงหรือบันทึกข้อมูลดิบกลับไปยังเครื่องฐานข้อมูลปลายทาง (เช่น Django REST Framework Backend)

ทำงานเป็นแบบไร้สถานะ (Stateless) และให้คลาส Repositories ปรากฏตัวในคอนสตรักเตอร์แบบเป็นส่วนตัว (Private) เพื่อส่งข้อมูลดิบกลับขึ้นไปประมวลผลต่อตามลำดับชั้นอย่างมีระบบระเบียบและปลอดภัยสูง

🔗 ศึกษารายละเอียดสถาปัตยกรรมเลเยอร์ข้อมูลของระบบแอปพลิเคชัน: https://docs.flutter.dev/app-architecture/case-study/data-layer
Flutter Mobile Dev | Week 11 • Part 4

ปฏิบัติการตั้งค่าโปรเจกต์และเครื่องมือพัฒนา

🎯 สารบัญหมวดที่ 4: เวิร์กชอปการติดตั้งระบบ

💡 คำชี้แนะภาคปฏิบัติ:

ในหมวดเรียนนี้จะเป็นการลงมือเขียนโค้ดและพิมพ์คำสั่งควบคุมระบบจริงแบบทีละขั้นตอน (Step-by-Step) ขอให้นักศึกษาจัดเตรียมเครื่องคอมพิวเตอร์และตรวจสอบสัญญาณอินเทอร์เน็ตให้เรียบร้อยก่อนเริ่มต้นทำตาม

Slide 17 • Verifying the Environment

ขั้นตอนที่ 1: ตรวจสอบความพร้อมด้วย flutter doctor

ก่อนเริ่มต้นเขียนโครงสร้างโปรเจกต์ใหม่ นักศึกษาทุกคนจำเป็นต้องตรวจสอบระบบและสถานะของซอฟต์แวร์สนับสนุนบนระบบเครื่อง เพื่อให้แน่ใจว่าเครื่องมือสำหรับการรันและทดสอบระบบจำลอง (Emulators) ทำงานได้สมบูรณ์:

# เปิดโปรแกรม Terminal หรือ Command Prompt แล้วพิมพ์คำสั่งด้านล่าง:

$ flutter doctor

🎯 สิ่งที่ควรตรวจสอบในหน้าจอผลลัพธ์:

  • ช่อง [✓] Flutter ต้องแสดงรุ่นเวอร์ชันอย่างน้อย 3.9.0 หรือสูงกว่า เพื่อรองรับฟีเจอร์ AI และสถาปัตยกรรมตัวใหม่
  • ช่อง [✓] Android toolchain และ [✓] Xcode (สำหรับ macOS) ต้องแสดงสถานะสมบูรณ์
  • ช่อง [✓] VS Code หรือ [✓] Android Studio มีการติดตั้งปลั๊กอิน Flutter และ Dart เรียบร้อยแล้ว
🔗 กรณีเกิดข้อผิดพลาดในการตรวจสอบสภาพแวดล้อม ศึกษาแนวทางแก้ไขปัญหาได้ที่: https://docs.flutter.dev/install/troubleshoot
Slide 18 • Project Creation & Libraries

ขั้นตอนที่ 2: เริ่มต้นจัดสร้างโครงร่างโปรเจกต์และนำเข้าคลังไลบรารี

สร้างโฟลเดอร์สำหรับพัฒนาแอปพลิเคชัน Compass ของเราขึ้นมาใหม่ และติดตั้งกลุ่มไลบรารีเสริมที่จำเป็นสำหรับการเชื่อมโยงเน็ตเวิร์ก (Dio), ระบบจัดการสถานะ (Provider), และการสร้างความปลอดภัยให้โทเค็น (Secure Storage):

# สร้างโปรเจกต์ใหม่และย้ายหน้าต่างการทำงานเข้าสู่ไดเรกทอรีโปรเจกต์:

$ flutter create compass_booking_app

$ cd compass_booking_app

# นำเข้าปลั๊กอินสำหรับเชื่อมต่อ REST API และจัดเก็บข้อมูลอย่างปลอดภัย:

$ flutter pub add dio provider flutter_secure_storage

🔗 เอกสารอ้างอิงและคู่มือการติดตั้ง (สำหรับการศึกษาต่อ):

Slide 19 • MVVM Directory Structuring

ขั้นตอนที่ 3: การจัดระเบียบสารบนโฟลเดอร์สไตล์ MVVM

เพื่อแยกความรับผิดชอบของโค้ดให้สอดคล้องตามข้อกำหนดของทีมผู้พัฒนา Flutter และหลักการกักเก็บความจริงหนึ่งเดียว (SSOT) ให้นักศึกษาสร้างโฟลเดอร์ย่อยภายใต้ไดเรกทอรี lib/ ดังนี้:

# รันคำสั่งต่อไปนี้เพื่อสร้างโครงสร้างโฟลเดอร์พร้อมกัน:

# สำหรับระบบปฏิบัติการ Unix/macOS:

$ mkdir -p lib/data/models lib/data/repositories lib/data/services

$ mkdir -p lib/domain/models

$ mkdir -p lib/ui/core lib/ui/home/view_models lib/ui/home/widgets

# สำหรับ Windows PowerShell:

$ mkdir lib\data\models, lib\data\repositories, lib\data\services

$ mkdir lib\domain\models

$ mkdir lib\ui\core, lib\ui\home\view_models, lib\ui\home\widgets

💡 เหตุผลในการแบ่งโครงสร้าง:

  • การจัด data/ ตามชนิดช่วยให้คลาสเรียกใช้ API สามารถแชร์การทำงานกันได้ง่ายข้ามหลายส่วน
  • การจัด ui/ แยกตามฟีเจอร์ ช่วยลดการทำงานชนกันของโค้ดเมื่อทีมขยายใหญ่ขึ้น
🔗 เจาะลึกกรณีศึกษาการวางโครงสร้างโปรเจกต์ระดับมาตรฐาน: https://docs.flutter.dev/app-architecture/case-study#package-structure
Slide 20 • AI Tooling & Plugins Setup

ขั้นตอนที่ 4: ติดตั้งระบบผู้ช่วยพัฒนา AI Copilot

เพื่อเพิ่มประสิทธิภาพและตรวจสอบพฤติกรรมการพิมพ์โค้ดของแอปพลิเคชันให้เป็นสากล เราจะทำการติดตั้งระบบ **Flutter Agent Plugins** และเชื่อมต่อระบบ IDE เข้ากับ **Dart and Flutter MCP Server** อย่างมีประสิทธิภาพ:

# เปิดใช้งานร่วมกับ Claude Code (ผ่าน Terminal):

$ claude plugin marketplace add flutter/agent-plugins

$ claude plugin install dart-flutter@dart-flutter

💡 ประโยชน์ของระบบช่วยเหลือ:

เครื่องมือ AI จะได้รับพิมพ์เขียวระดับสูง สามารถใช้อุปกรณ์ประมวลผลจำลองตรวจสอบข้อผิดพลาดบนหน้าจอวิดเจ็ตแบบเรียลไทม์ และช่วยหาแพ็กเกจที่ปลอดภัยจากเว็บไซต์ผับเดฟได้ทันที

🔗 แนวทางการปรับแต่งและติดตั้งระบบช่วยเหลือแบบครบถ้วน:
คู่มือการตั้งค่าเครื่องมือ AI คู่มือการใช้งานระบบ MCP Server
Developer environment setup
ภาพแอปพลิเคชัน Compass ใน IDE ที่ตั้งค่าโครงสร้างสถาปัตยกรรมพร้อมเขียนคำสั่งเรียบร้อยแล้ว
Slide 21 • Building Skeleton Code

ขั้นตอนที่ 5: การจัดวางโครงข่ายคลาสรับส่งค่าเริ่มต้น

ให้นักศึกษาทำการสร้างไฟล์แบบจำลองประเภทข้อมูล lib/domain/models/booking.dart เพื่อกำหนดโครงสร้างจำลองข้อมูลของทริปสำหรับการท่องเที่ยวแบบเบื้องต้น:

// lib/domain/models/booking.dart

class BookingSummary {

final int id;

final String destinationName;

final DateTime startDate;

final DateTime endDate;

final double price;

BookingSummary({

required this.id,

required this.destinationName,

required this.startDate,

required this.endDate,

required this.price,

});

}

กิจกรรมเพิ่มเติมสำหรับนักศึกษา:

สร้างโครงสร้างคลาสจำลองในเลเยอร์เน็ตเวิร์กไว้ชั่วคราว เพื่อเตรียมการเชื่อมต่อและดึงข้อมูลดิบจาก API หลังบ้านตัวจริงของ Django REST Framework ในการเรียนสัปดาห์หน้า

Slide 22 • Week 11 Summary & Homework

สรุปบทเรียนและภารกิจการเตรียมพร้อมสู่สัปดาห์ที่ 12

ในวันนี้เราได้เข้าใจสถาปัตยกรรมแอปพลิเคชันระดับโปรดักชัน คุ้นเคยกับแนวคิด **MVVM, SSOT และ UDF** และสามารถตั้งโครงร่างแฟ้มโฟลเดอร์สำหรับพัฒนา Compass App ได้เสร็จสมบูรณ์แล้ว

ภารกิจจัดเตรียมความพร้อมก่อนเข้าสู่สัปดาห์ถัดไป:

  • ตรวจสอบให้แน่ใจว่าเครื่องคอมพิวเตอร์ส่วนตัวมีการลงทะเบียนซอฟต์แวร์ Python 3.10+ บนระบบเครื่องแล้ว
  • ศึกษาพื้นฐานคำสั่งสำหรับสร้างระบบฐานข้อมูลและการจัดการ API ของ Django REST Framework (DRF) ล่วงหน้า
  • ทดลองลงมือตรวจสอบความเสถียรของแอปพลิเคชันเวอร์ชันเปล่าบนเครื่องจำลองหรือโทรศัพท์มือถือส่วนตัว
🔗 ศึกษาคู่มือการรันสภาพแวดล้อมจำลอง (Local Development) เพิ่มเติมเพื่อความเข้าใจที่ลึกซึ้ง: https://github.com/flutter/samples/tree/main/compass_app