ว่าด้วยเรื่อง Android App Architecture จาก Google

จากงาน Google I/O 2017 นั้นมีของใหม่ ๆ ออกมาเยอะมาก ไม่รู้จะเยอะไปไหน !! มีหลายสิ่งอย่างน่าสนใจ ยกตัวอย่างเช่น Guide to App Architecture หรือโครงสร้างต่าง ๆ สำหรับการพัฒนา Android app ซึ่งทางทีมพัฒนาได้สรุปและเตรียม component ต่าง ๆ ไว้ให้อย่างครบครัน โดยแยกส่วนการทำงานต่าง ๆ ออกเป็น component อย่างชัดเจน ประกอบไปด้วย

• Component สำหรับการจัดการ Lifecycle ของ Activity/Fragment ให้ง่ายขึ้น
• LiveData คือ observer สำหรับ data holder เพื่อคอยดูการเปลี่ยนแปลงของข้อมูล โดยทำงานร่วมกับ lifecycle ของ Activity/Fragment/Service อีกทั้งยังช่วยจัดการไม่เกิด memory leak อีกด้วย มีการทำงานเช่นเดียวกับ RxJava และ Agera
• ViewModel เตรียมข้อมูลสำหรับ UI component ต่าง ๆ ซึ่งข้อมูลต่าง ๆ มาจาก LiveData นั่นเอง
• Room Persistence Library คือ Object mapping สำหรับ SQLite นั่นเอง ที่สำคัญยังคอยดูการเปลี่ยนแปลงข้อมูลอีกด้วย นั่นคือทำงานร่วมกับ LiveData นั่นเอง
• Repository คือคนกลางสำหรับจัดการข้อมูลจากที่ต่าง ๆ ไม่ว่าจะมาจาก Local หรือ Remote ก็ตาม
• Networking แนะนำให้ใช้ Retrofit
• การจัดการ component ที่ต้องทำงานร่วมกันแนะนำให้ใช้ Dagger 2

แสดงโครงสร้างของระบบดังนี้

ซึ่งโครงสร้างนี้มีเป้าหมายเพื่อ ช่วยแก้ไขปัญหาต่าง ๆ ดังนี้

การจัดการ Life Cycle ของ Activity/Fragment/Service ซึ่งมันซับซ้อนและยากต่อการจัดการ ส่งผลให้นักพัฒนาลำบากมาก ๆ และ จัดการหรือเอาไม่อยู่ !! ส่งผลให้ App พังหรือหยุดทำงานได้ง่ายมาก ๆ บ่อยครั้งพบว่า การจัดการต่าง ๆ เขียนอยู่ใน Activity/Fragment ทั้งหมด บ่อยครั้งพบว่า เขียน code จัดการแบบผิด ๆ บ่อยครั้งพบว่า มีการใช้ resource แล้วไม่ยอมคืน บ่อยครั้งพบว่า เกิด memory leak ขึ้น ดังนั้นตามแนวคิดของ Separation of Concern (SoC) นั่นคือแยกส่วนการทำงานออกเป็นส่วน ๆ หรือ component ตาม component ด้านบน โดยแนวทางนี้เป็นเพียงแนวทางหนึ่งในการแก้ไขปัญหาเท่านั้น ซึ่งช่วยทำให้ app มีความน่าเชื่อถือ ทดสอบและดูแลรักษาได้ง่าย แน่นอนว่า มันน่าลองทำตามเป็นอย่างยิ่ง ดังนั้นมาเริ่มกันดีกว่า !!

ปิดท้ายมาดูการทดสอบกันหน่อย

เนื่องจากแยกส่วนการทำงานออกจากกันชัดเจน ดังนั้นทำให้แต่ละส่วนทดสอบได้ง่าย มาดูกันว่าทดสอบกันอย่างไร ? 1.ในส่วนของ User Interface ใช้งาน Espresso ส่วนการทำงานต่าง ๆที่ User Interface ต้องการใช้งาน เช่น ViewModel ก็ให้ mock ไว้ซะ 2. ViewModel สามารถทดสอบด้วย JUnit ได้เลย ส่วนอื่น ๆ ที่ทำงานด้วย เช่น Repository ก็ให้ mock ไว้ซะ 3. Repository สามารถทดสอบด้วย JUnit เช่นกัน 4. DAO (Data Access Object) สำหรับการจัดการข้อมูลผ่าน Room แนะนำให้ใช้งานผ่าน Instrumentation test นั่นเอง เนื่องจากมีการใช้งาน library ของ Android นั่นเอง จากนั้นให้ทำการทดสอบด้วย in-memory database ซึ่งจะส่งผลกระทบต่อการทำงานน้อยมาก ๆ และอย่าทดสอบผ่าน SQLite ตรง ๆ เนื่องจากในแต่ละ device อาจจะใช้ SQLite version ต่างกัน !! 5. WebService/REST API ให้ทำการทดสอบผ่าน WebMockServer ซึ่งช่วยทำงานสร้าง face webserver ขึ้นมาแบบง่าย ๆ นั่นเอง 6. Testing Artifact โดยที่ Architecture component ได้เตรียม library สำหรับการควบคุมการทำงานใน background thread มาให้ ประกอบไปด้วย InstantTaskExecutorRule และ CountingTaskExecutorRule

ซึ่งน่าจะทำให้การพัฒนา Android app ง่ายและเป็นมาตรฐานยิ่งขึ้น ดังนั้นจะช้าอยู่ทำไม มาเขียน code กันเถอะ