การพัฒนาแอปบนแอนดรอยด์ในช่วงแรกเราอาจจะพัฒนาแอปโดยไม่ต้องคิดถึงเรื่องโครงสร้างของโค้ดมากนัก แต่เมื่อพัฒนาไปได้จนถึงจุดหนึ่งที่แอปเริ่มมีขนาดใหญ่ และไม่ได้มีคนเขียนโค้ดแค่เพียงคนเดียวอีกต่อไป ก็อาจจะต้องคำนึงถึงเรื่อง App Architecture เพื่อให้ง่ายต่อการพัฒนาแอปในอนาคต

App Architecture ใน ณ ที่นี้จะหมายถึงรูปแบบโครงสร้างของโค้ดที่เราเขียนในแอปใด ๆ ก็ตาม (ใน ณ ที่นี้คือแอปบนแอนดรอยด์) เพื่อกำหนดรูปแบบในการทำงานร่วมกันระหว่างโค้ดแต่ละส่วน ที่เรารู้จักกันในชื่อของ MVC, MVP, MVVM, VIPER, MVI, REDUX และอื่น ๆ อีกมากมาย

ซึ่งเรื่องนี้เคยเป็นปัญหาสำหรับนักพัฒนาในอดีตมามากมาย เพราะในสมัยนั้นแต่ละแอปก็จะมี App Architecure ต่างกัน ขึ้นอยู่กับว่ารูปแบบไหนเหมาะกว่ากัน จนกระทั่งในปี 2017 ทีมแอนดรอยด์ของ Google ก็ได้เปิดตัวชุดพัฒนาที่มีชื่อเรียกว่า Architecture Components ภายในงาน Google I/O 2017 เพื่อเป็นแนวทางแนะนำสำหรับ App Architecture สำหรับแอปบนแอนดรอยด์ โดยใช้ Concept ของ MVVM กับ Clean Architecture ร่วมกัน

"แล้วเราจะเป็นต้องใช้ Architecture Components เท่านั้นหรอ? ใช้แบบอื่นได้มั้ย?"

ต้องบอกว่า Architecture Components นั้นเป็นแค่เพียงทางเลือกหนึ่งเท่านั้น ถ้ามีรูปแบบอื่นที่สามารถตอบโจทย์กับการทำงานของแอปและตอบโจทย์ทีมพัฒนาอยู่แล้ว ก็ไม่จำเป็นต้องเปลี่ยน

แต่ Architecture Components จะเหมาะกับทีมพัฒนาแอปที่กำลังตัดสินใจเลือก App Architecture เพื่อใช้งานกับแอปของตัวเอง ไม่ว่าจะเป็นแอปที่กำลังจะพัฒนาขึ้นมาใหม่ หรือแอปเก่าที่ต้องการเปลี่ยนไปใช้แบบใหม่ที่ตอบโจทย์กว่าเดิม

นอกจากนี้ Architecture Components ยังครอบคลุมไปถึงการทำงานในส่วนอื่น ๆ ที่มีทั้งส่วนที่เกี่ยวข้องและไม่เกี่ยวข้องกับ UI อีกด้วย เช่น

  • Navigation สำหรับควบคุมการเปลี่ยนหน้า UI
  • Paging สำหรับจัดการกับข้อมูลที่มาจาก Web Service หรือ Local Database เพื่อนำมาแสดงผลใน RecyclerView  แบบ Pagination
  • Room สำหรับช่วยจัดการกับ Local Database ที่เป็น SQLite
  • WorkManager สำหรับการทำงานที่เป็น Background Task

ดังนั้นบทความนี้จะมาแนะนำเหตุผลดี ๆ ในมุมของ App Architecture ว่าทำไมนักพัฒนาแอปบนแอนดรอยด์ถึงควรเปลี่ยนมาใช้ Architecture Components กัน

ข้อดีของการใช้ Architecture Components

เป็น App Architecture ที่แนะนำสำหรับการพัฒนาแอปบนแอนดรอยด์

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

แยก Logic ระหว่าง Application UI กับ Application Business ออกจากกัน

ด้วยรูปแบบที่ Architecture Components ออกแบบไว้ ทำให้นักพัฒนาสามารถแยก Logic ระหว่าง Application UI (ส่วนที่จัดการเรื่อง UI และการทำงานของ Android Framework) และ Application Business (ส่วนที่จัดการกับข้อมูลให้ถูกต้องตาม Business Requirement) ออกจากกันได้

ทำให้การดูแลและแก้ไขโค้ดในแต่ละส่วนนั้นทำได้ง่าย ลดผลกระทบที่เกิดขึ้นเมื่อแก้ไขโค้ดที่ฝั่งใดฝั่งหนึ่งให้น้อยลง เช่น การแก้ไข UI ใด ๆ ในโค้ดฝั่ง Application UI ทำให้ไม่เกิดผลกระทบกับโค้ดในส่วน Application Business จึงมั่นใจได้ว่าแอปยังคงทำงานได้ตาม Business Requirement เดิมที่มีอยู่

ควบคุมการทำงานของ UI ด้วย Model

ใน Architecture Components จะมีสิ่งที่เรียกว่า View Model (เรียกสั้น ๆ ว่า VM) ที่ใช้ Concept ของ MVVM เพื่อจัดการกับ Logic ของ Application UI และส่งข้อมูลในรูปของ Model ให้ Activity หรือ Fragment นำข้อมูลไปกำหนดค่าสำหรับการแสดงผลของ UI อีกที

นั่นหมายความว่า Logic เพื่อควบคุมการแสดงผลของ UI จะถูกแยกออกจาก Android Platform Behavior จัดการกับโค้ดเพื่อให้แอปแสดงผลตรงกับที่คาดไว้ (Consistency) ได้ง่าย

Android Platform Behavior ใน​ ณ​ ที่นี้หมายถึงการทำงานที่เกิดขึ้นตามรูปแบบที่ Android OS ได้ออกแบบไว้ ไม่ว่าจะเป็น Activity/Fragment Lifecycle, Configuration Changes หรือ Activity Recreation

ลดโค้ดที่จัดการกับ Android Platform Behavior ให้น้อยลง

ด้วยวิธีการเขียนโค้ดในรูปแบบเดิม ๆ สำหรับแอปบนแอนดรอยด์ จะต้องมีโค้ดบางส่วนเพื่อทำให้แอปสามารถทำงานได้ถูกต้องและไม่ขัดกับการทำงานของ Android Platform Behavior

โดยใน Architecture Components จะมี ViewModel ช่วยจัดการปัญหาที่เกิดขึ้นให้บางส่วนแล้ว จึงลดโค้ดที่จะต้องเขียนเพื่อจัดการกับการทำงานในส่วนนี้ให้น้อยลง เช่น

  • ViewModel จะไม่ถูก Recreate เมื่อเกิด Configuration Changes
  • มี SavedStateHandle เพื่อช่วยเก็บข้อมูลไม่ให้หายไปเมื่อเกิด Activity Recreation
  • มี LiveData เพื่อช่วยให้ ViewModel ส่งข้อมูลได้โดยไม่ต้องสนใจ Lifecycle ของ Activity/Fragment
  • สามารถใช้ ViewModel เป็นตัวกลางในการส่งข้อมูลระหว่าง Activity กับ Fragment หรือระหว่าง Fragment ด้วยกันได้

Architecture Components มีการพัฒนาอยู่ตลอดเวลา

เพื่อให้ตอบโจทย์กับการใช้งานในแอปที่หลากหลายรูปแบบ ทีมแอนดรอยด์ของ Google จึงรับ Feedback จากนักพัฒนาทั่วโลกอยู่ตลอด เพื่อปรับปรุงและพัฒนา Architecture Components อยู่เสมอ ไม่ว่าจะเป็นการเพิ่มฟีเจอร์หรือความสามารถใหม่ ๆ เพื่อช่วยให้นักพัฒนาทำงานได้ง่ายขึ้น รวมไปถึงการดูแลแก้ไขบั๊กที่เกิดขึ้นด้วยเช่นกัน

Architecture Components Release Notes Archive | Android Developers
Android Developers

ดังนั้นจากเดิมที่นักพัฒนาจะต้องมาคิดเรื่องนี้ ก็ปล่อยให้เป็นหน้าที่ของคนที่พัฒนา Architecture Components แล้วเอาเวลาไปใส่ใจกับโค้ดที่จำเป็นต่อการทำงานของแอปจริง ๆ แทน

สามารถเขียนเทสได้ (Testable)

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

แน่นอนว่า Architecture Components ถูกสร้างขึ้นมาด้วย Testability Mindset ทำให้โค้ดแต่ละส่วนสามารถเขียนเทสได้ด้วยรูปแบบที่แตกต่างกันออกไป ดังนั้นตราบใดโค้ดของนักพัฒนาไม่ได้เป็นเป็น Anti-pattern สำหรับ Architecture Components ก็สามารถเขียนเทสให้กับโค้ดในแต่ละส่วนได้เสมอ

รองรับ First Class Kotlin

เนื่องจากถูกออกแบบมาให้รองรับกับการใช้งานด้วยภาษา Kotlin ตั้งแต่แรกตามที่ Google ได้ประกาศไว้ว่าจะให้ Kotlin เป็น First Class Citizen สำหรับแอนดรอยด์ จึงมั่นใจได้ว่า Architecture Components จะรองรับความสามารถของภาษา Kotlin ได้อย่างเต็มที่

มี Learning Curve ต่ำ เมื่อต้องเปลี่ยนไปพัฒนาแอปตัวใหม่ที่ใช้ App Architecture เหมือนกัน

เนื่องจากเป็น App Architecture ที่ทีมแอนดรอยด์ของ Google แนะนำ จึงทำให้แอปเป็นจำนวนมากที่ใช้ Architecture Components รวมไปถึงแหล่งข้อมูลในการเรียนรู้ด้วยเช่นกัน ทำให้นักพัฒนาแอปส่วนใหญ่มีความคุ้นเคยและเข้าใจการทำงานของ Architecture Components กันอยู่แล้ว

ดังนั้นไม่ว่าจะเป็นการย้ายไปพัฒนาแอปตัวอื่นหรือมีนักพัฒนาคนใหม่เข้ามาร่วมทีม ก็จะมี Learning Curve ในการเรียนรู้โค้ดของแอปที่น้อยกว่าเดิม ไม่ต้องเสียเวลาเรียนรู้การทำงานของ App Architecture แล้วใช้เวลาไปกับการเรียนรู้ส่วนที่เป็น Code Structure และ Business Domain ในแอปนั้น ๆ แทน

สรุป

เมื่อพิจารณาถึงข้อดีแล้ว ไม่แปลกใจที่แอปส่วนใหญ่ในปัจจุบันนี้หันมาใช้ App Architecture เป็น Architecture Components กัน ในขณะที่ข้อเสียส่วนมากเป็น Trade-off ที่มาจากข้อดีซะส่วนใหญ่ เมื่อเทียบความคุ้มค่าแล้ว ทำให้ Architecture Components เป็นทางเลือกที่ดีสำหรับนักพัฒนาแอปส่วนใหญ่

และส่วนหนึ่งก็เกิดมาจาก Pain Point ในอดีตที่นักพัฒนาไม่สามารถหา App Architecture ที่ลงตัวได้ ทำให้ต้องคอยเปลี่ยนอยู่บ่อย ๆ หรือทนดูแลโค้ดรูปแบบเก่า ๆ ที่ไม่ตอบโจทย์กับการทำงานบางอย่าง ดังนั้นการมาของ Architecture Components จึงทำให้นักพัฒนามั่นใจได้ว่าเป็น App Architecture ที่เหมาะสำหรับการพัฒนาแอปบนแอนดรอยด์ เพราะถูกคิดค้นและพัฒนาด้วยทีมแอนดรอยด์ของ Google ที่ได้รับ Feedback มาจากนักพัฒนาทั่วโลก

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