พอกันทีกับ God Activity มาวางโครงดีๆ ด้วย Architecture Components
Table of Contents
- Part 1 — Introduction <- You are here
- Part 2 — Data Layer
- Part 3 — Presentation Layer
- Part 4 — Demo
- Part 5 — Addendum
Introduction
งาน Google IO 2017 ที่ผ่านมานอกจากเรื่องฮือฮาอย่าง Kotlin แล้ว อีกสิ่งที่น่าสนใจไม่แพ้กันคือการมาถึงของ Android Architecture Components (จากนี้ขอย่อว่า AAC นะจ้ะ) ที่จะมาช่วยให้เราวาง Architecture และเขียนแอปได้คลีนขึ้นไปอีกระดับ บล็อกนี้เราจะมาพูดถึง LiveData, ViewModel และ Room ซึ่งเป็นส่วนหนึ่งใน AAC ผ่านเดโมแอปที่ผมเตรียมไว้ แต่ก่อนจะมาเริ่มละเลงโค้ดก้น เรามาตอบคำถามกันก่อนว่าทำไมเราต้องใส่ใจเรื่อง Architecture กันด้วย ?
ทำไมเราต้องสนใจการวาง Architecture ด้วย ?
นั่นสิครับ ทำไมหละ? ก็ในเมื่อทุกวันนี้ก็เขียนแอปได้อยู่แล้ว วาง UI สวยๆ เป็นดึงข้อมูลจาก API ได้ แถมแอปที่ปล่อยไปก็มียอดโหลดเยอะแยะ ทำไมต้องมาเสียเวลาสนใจศึกษาเรื่อง Architecture กันอีก ?
ถ้าคุณมีคำถามพวกนี้อยู่ในหัว คุณอาจจะเป็นหนึ่งใน Android Dev ที่เขียนโค้ดส่วนใหญ่กระจุกอยู่ใน Activity หรือ Fragment คุณอาจจะไม่เคยสนใจหรือไม่เคยรู้จัก MVP, MVVM หรือหนักกว่านั้นคือคุณไม่เคยทำ Unit Test เลย !?!
ถ้าคุณเป็นหนึ่งในนั้น ผมแนะนำว่าถึงเวลาแล้วครับที่คุณจะต้องมาให้ความสำคัญกับการวาง Architecture ของแอป เพราะแอปที่ไม่มีการวาง Architecture ที่ดีและเขียนโค้ดพันกันยุ่งเหยิงนั้น
- มันทำเทสยากหรือแทบจะทำไม่ได้เลย แก้อะไรไปก็ไม่รู้ว่าไปทำให้ส่วนอื่นพังหรือเปล่าเพราะไม่มีผลเทสมายืนยัน
- สเกลแอปยากจะเพิ่มฟีเจอร์ใหม่แต่ละที ต้องตามแก้ไขหลายจุดเพราะโค้ดมันพันกันมั่วไปหมด
- ไล่หาไล่แก้บั๊กก็ยาก ตอนกลับมาอ่านโค้ดทีหลังแม้จะเป็นโค้ดตัวเองก็ยังอ่านยาก อย่าหวังว่าคนอื่นจะอยากมาตามดูตามแก้ ซึ่งเป็นหนึ่งในสิ่งที่น่าเบื่อที่สุดในอาชีพโปรแกรมเมอร์คือการที่ต้องมานั่งดูโค้ดคนอื่นที่เขียนมาแบบยุ่งเหยิง สุดท้ายก็กลายเป็นเลกาซี่โค้ดที่ไม่มีใครอยากแตะ
- ทุกข้อข้างบนทำยากแต่สร้างบั๊กใหม่ๆ กลับง่าย จริงอยู่ว่าต่อให้เราเขียนโค้ดโคตรคลีนหรือวาง Architecture ไว้ดีขนาดไหนมันก็ยังเกิดบั๊กได้ แต่ยิ่งแอปที่โค้ดไว้แบบยุ่งเหยิงก็ยิ่งเสี่ยงที่จะเกิดบั๊กได้ง่ายขึ้น และสุดท้ายความเสี่ยงก็ไปตกอยู่กับผู้ใช้
ทุกข้อทั้งหมดจะทำให้ความเร็วในการพัฒนาแอปของคุณค่อยๆ ลดลงไปเมื่อความซับซ้อนของแอปมากขึ้นเรื่อยๆ สุดท้ายก็จะส่งผลกับภาพรวมเพราะคุณจะส่งงานได้ช้าและงานก็ไม่มีคุณภาพ
เอาละครับ Enough Talking ผมบ่นมากเป็นตาแก่ไปแล้ว เรามาพูดถึง Android App Architecture กันดีกว่า
Architecture ของแอป Android ถือเป็นเรื่องใหม่ ?
สำหรับ Android นั้นการวาง Architecture ดีๆ ไม่ได้เป็นเรื่องใหม่นะครับ เรื่องนี้นักพัฒนามีคุยกันมานานแล้ว มีแพทเทิร์นมากมายที่นิยมเอามาใช้ในการวาง Architecture เพื่อให้แต่ละส่วนของแอปแยกหน้าที่การทำงานกันอย่างชัดเจนตามหลัก Separation of Concern ไม่ว่าจะเป็น Clean Architecture, การวางโครงส่วน presentation layer แบบ MVP หรือ MVVM หรือจะไป Redux, C++ Core ก็ไม่มีใครว่า บางทีในหนึ่งแอปอาจจะมีหลายแพทเทิร์นก็ได้ เพราะเรื่องการวาง Architecture นั้นมันไม่มีกฎตายตัว แต่มันขึ้นอยู่กับลักษณะของแอปและความต้องการของทีม แม้แต่การวางโครงด้วย AAC นี้ก็เป็นแค่แนวทางหนึ่งเท่านั้น ไม่จำเป็นว่าต้องทำเหมือนกันทุกแอปเสมอไป
สำหรับในบล็อกนี้เราจะมีเดโมแอปที่ใช้ส่วนต่างๆ ของ AAC คือ ViewModel, LiveData และ Room รวมไปถึงไลบรารีตัวอื่นคือ RxJava2, Retrofit และ Dagger2 พร้อมทั้งทำ Unit Test บางส่วนของแอปด้วย JUnit และ Mockito และที่สำคัญทั้งโปรเจคนี้เป็น Pure Kotlin จ้า !
Disclaimer
-ในขณะที่เขียนอยู่นี้ AAC ยังอยู่ในสถานะ alpha (1.0.0-alpha2) ถ้าจะเอาไปใช้ในระดับ Production ก็ขอให้พิจารณาหรือทดสอบดีๆ นะจ้ะเพราะ API อาจจะยังไม่นิ่ง
- Code snippet ที่แสดงในบล็อกจะเป็นการยกมาแค่บางส่วน เพื่อความกระชับและเข้าใจง่ายคุณสามารถดูโค้ดเต็มๆ ได้โปรเจคจริง ผมจะแทรกลิงค์ไป Github ไว้ใน part 2
- บล็อกนี้จะไม่อธิบายพื้นฐานของ Kotlin, RxJava2, Retrofit, Mockito และ Dagger2 นะครับ ผมจะโฟกัสการวาง Architecture ด้วยไลบรารีพวกนี้ร่วมกับ AAC เลย ถ้าใครอยากจะปูพื้นไลบรารีข้างต้นสามารถตามอ่านได้ตรงส่วนลิงค์ใน part สุดท้ายของซีรี่ย์นี้ครับ
Posts Reader App
สำหรับตัวเดโมแอปนั้น จะเป็นแอปที่ชื่อว่า Posts Reader ซึ่งเอาให้ง่ายเราจะไปดึงข้อมูลจาก Open API ที่ชื่อ JSONPlaceholder โดยแอปจะมีเพียงสองหน้าคือหน้า Post List และหน้า Post Detail หน้าตาแบบเรียบๆ ตามรูป
ในหน้า Post List จะแสดง Post ทั้งหมดโดยแสดงแค่ Title ของแต่ละ Post ส่วนในหน้า Post Detail จะแสดงทั้ง Title และ Body ของ Post ที่เราคลิกเลือก
ส่วนภาพรวม Architecture ของแอป Posts Reader จะเป็นตามนี้
เราจะแบ่งแอปเป็นสองเลเยอร์คือ Data Layer และ Presentation Layer ซึ่งจะอยู่ใน package /data และ /presentation ตามลำดับ
- Data Layer เป็นส่วนของ Repository ทำหน้าที่จัดการข้อมูลทั้งจาก API และ Local Database
- Presentation Layer เป็นส่วนของ UI ซึ่งจะใช้ข้อมูลใน Repository ของ Data Layer อีกที
ติดตามต่อไปยัง Part 2 ส่วนของ Data Layer ได้เลยครับ
