มาดูโครงสร้าง code ของ Google I/O 2018 app for Android กัน

จาก 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