จาก session Architecture Components in Real Life (Android) ในงาน Mobile Conf 2018
มีคำถามหนึ่งที่น่าสนใจคือ
ทาง Google ได้ปล่อย source code ของ Google I/O 2018 app ออกมา
เหล่า Android developer ได้เข้าไปดู เข้าไปศึกษาหรือไม่ ?
คำตอบที่ได้รับกลับมาคือ เงียบ (อาจจะมีคนเข้าไปดูก็ได้ แต่ไม่แสดงตัวเท่านั้นเอง)
เป็นสิ่งที่แปลกมาก ๆ นะ (หรือเป็นเรื่องปกติไปแล้วนะ)

ดังนั้นเหล่า Android developer มาลองศึกษากันหน่อย
ว่า Google I/O 2018 app นั้นเขาพัฒนากันออกมาอย่างไร ?
มีโครงสร้างอย่างไรบ้าง ?
ดังนั้นมาลองดูกัน

เมื่อเข้าไปดูก็พบว่า

ใน Android Developer Blog เขียนอธิบายไว้คร่าว ๆ แล้ว
ถูกเขียนใหม่ ด้วยโครงสร้างใหม่ นั่นก็คือ Architecture Component  และภาษา Kotlin
ซึ่งมีโครงสร้างดังรูป

จากรูปโครงสร้างของ app ประกอบไปด้วย

  • Presentation layer สำหรับการแสดงผลซึ่งมีสองส่วนหลักคือ Activity/Fragment และ ViewModel โดยในส่วนนี้จะใช้งาน Data Binding Library สำหรับการ binding UI เข้ากับข้อมูล หรือ ViewModel ต่อไป
  • Domain layer สำหรับ Use case หรือ business process ต่าง ๆ
  • Data layer สำหรับการจัดการข้อมูลจาก data source ต่าง ๆ ผ่านสิ่งที่เรียกว่า Repository ประกอบไปด้วย FireStore, Local cache และ Google Cloud Storage โดยที่ข้อมูลจะมีทั้งแบบ static data, schedule data และ realtime data ที่สำคัญ app นี้สนับสนุนการทำงานแบบ offline ด้วยนะ

ข้อมูลที่ส่งไปมาระหว่าง layer ก็คือ LiveData

ยังไม่พอนะยังใช้ Library อื่น ๆ อีก เช่น

  • Dagger2 จัดการเรื่อง Dependency Injection
  • OkHTTP จัดการเรื่องการใช้งาน API ผ่านระบบ network
  • Gson สำหรับจัดการข้อมูล JSON
  • ThreeTen สำหรับจัดการเรื่อง datetime
  • Timber สำหรับจัดการเรื่อง logging
  • Crashlytic

เขียน code ใหม่ด้วยภาษา Kotlin ยังไม่พอนะใช้งาน Android Kotlin Extension (KTX) อีกด้วย
มาถึงตรงนี้ มันมาเต็มมาก ๆ
เหมาะต่อการเรียนรู้สุด ๆ ถ้าใครพลาดแล้วจะเสียใจ

ดูไปดูมามันคือ Clean Architecture ชัด ๆ


ยกตัวอย่างของ Use Case ที่อยู่ใน module shared

ยังไม่พอนะ ยังมีส่วนของการทดสอบอีกด้วย

ทั้ง Unit testing ด้วย jUnit และ Mockito , Mockito-Kotlin
ทั้ง UI testing ด้วย Espresso

สิ่งที่น่าสนใจคือ code ใน app นี้มีการทดสอบเยอะมาก ๆ
มันสะท้อนให้เห็นว่า โครงสร้างของระบบมันทดสอบได้ง่ายมาก (Testable)
ดังนั้นสิ่งที่เหล่านักพัฒนาต้องเข้าใจคือ
ถ้าระบบงานของเราทดสอบยากแล้ว
มันกำลังบ่งบอกว่า โครงสร้างระบบของเรานั้นไม่ถูกอย่างแน่นอน

มาดูโครงสร้าง module ของ app กันหน่อย

ทำการแบ่งออกเป็น module ย่อย ๆ
เพื่อแยกส่วนการทำงานต่าง ๆ ออกจากกัน
แต่ต้องระวังในเรื่องของ dependency กันด้วยนะ
ถ้าออกแบบไม่ดี สิ่งที่เกิดขึ้นคือ cyclic dependency หรือการเรียกกันไปมา

Module ต่าง ๆ ประกอบไปด้วย

  • mobile เป็น module หลักของการทำงานประกอบไปด้วย activity, fragment, ViewModel และสิ่งต่าง ๆ ที่เกี่ยวข้องกับ UI เช่น adapter ของ data binding เป็นต้น
  • tv สำหรับ Android TV app
  • model สำหรับ model class ที่ใช้ใน app ทั้งหมด เช่น User, Speaker, Session, Room และ Tag เป็นต้น
  • shared สำหรับ business logic นั่นคือ UseCase ต่าง ๆ ที่แยกออกตาม domain เช่น Agenda, Authentication, Session, User และ Speaker เป็นต้น รวมไปถึง class การทำงานหลักอีกมากมาย
  • test-shared สำหรับสร้างข้อมูลที่ใช้ในส่วนของ Unit testing
  • androidTest-shared สำหรับเก็บ utilities class ที่ใช้ในส่วนของ UI testing

ผลจากการแยก module ทำให้การ build แบบ incremental เร็วขึ้น
ถ้าแยกแล้วช้าลงน่าจะผิดนะ
รวมทั้งสามารถแยกทีมช่วยกันพัฒนาได้ง่ายอีกด้วย

คำถามคือ เราควรใช้งานสิ่งต่าง ๆ เหล่านี้หรือไม่ ?
จาก session นี้บอกไว้ว่า
เราควรศึกษาทำความเข้าใจก่อน
จากนั้นลงมือทำ PoC (Proof of Concept) ใน use case ต่าง ๆ ไม่ใช่แค่ login หรือ ดึงข้อมูลจาก github นะ
เมื่อถึงเวลา และ use case ที่เหมาะสม จะได้นำมาใช้งานได้เลย

มาศึกษากันดูครับ ผมว่าน่าจะได้ความรู้และแนวทางการพัฒนาที่ดีเพียบเลย
ขอให้สนุกกับการ coding

Tags:,,