ว่าด้วยเรื่อง Android Application Architecture ที่ดี

จากงาน Android Dev Summit 2015 นั้น มีหัวข้อที่น่าสนใจเยอะเลย หนึ่งในนั้นคือ Android Application Architecture ได้อธิบายสิ่งต่าง ๆ ที่น่าสนใจสำหรับการพัฒนา Android application แต่หัวข้อที่ชอบมาก ๆ คือ โครงสร้างการทำงานของระบบ มาดูกันว่าเป็นอย่างไร

เริ่มต้นได้อย่างน่าคิด

อะไรที่คุณตัดสินใจไปแล้วมันจะอยู่กับคุณไปตลอด ดังนั้นคิดให้ดี ๆ โดยโครงสร้างของ app ที่คิดขึ้นมานั้น มันจะง่าย หรือ ยาก ให้คิดถึงปัญหาที่ต้องการแก้ไขเป็นหลัก ไม่ใช่คิดถึง วิธีการแก้ไขปัญหา หรือ framework หรือ library เป็นหลัก !! คำถามต่อมา น่าคิดมาก ๆ คือ แล้วโครงสร้างของระบบจะเป็นแบบไหนดีล่ะ ?

• MVC
• MVP
• MVP-I
• MVVM
• MVVM-I
• VIPER
• Clean Architecture
• Reactive
• Flux
• ...

พบว่ามันมีหลายแนวทางมาก ๆ !! (Paradox of choices) แต่แนะนำว่า อย่าไปยึดติดกับ desing pattern อย่าไปยึดติดกับ Library อย่าไปยึดติดกับ Framework เพราะว่ามันจะจำกัดกรอบความคิดของเรามากเกินไป ให้เน้นไปที่การแก้ไขปัญหาดีกว่า ทุกแนวทางนั้น ล้วนมีเป้าหมายเดียวกัน คือ สามารถเปลี่ยนแปลงได้รวดเร็ว นั่นคือ สามารถ refactoring ได้ง่าย รวมไปถึงทดสอบการทำงานแต่ละส่วนได้ง่าย เพื่อป้องกันไม่ให้เกิดสิ่งที่เรียกว่า Lava flow

สิ่งที่แนะนำในการออกแบบ คือ Architect for UX (User Experience)

มันเป็นอย่างไรล่ะ ? ตัวอย่าง App ต้องทำการส่งข้อมูลไปยัง server คำถามคือ จะขึ้นรูป loading ทำไม ? แถมบางครั้งถ้า network มีปัญหา รูป loading มันไม่หายไปด้วย ทำให้ app ปิดตัวเองอีก ซึ่งเป็นประสบการณ์การใช้งานที่ไม่ดีเลยใช่ไหม ? แสดงการทำงานดังรูป ปัญหาจากรูปแบบการทำงานนี้ คือ View จะรอไปจนกว่าจะได้ข้อมูลจาก ViewController และ Network นั่นคือ ViewController มันผูกติดกับ Network อย่างมาก !! สามารถแก้ไขด้วยการแยก ViewController ออกจาก Network ซะ ด้วยการเพิ่มอีกหนึ่งส่วน หรือ อีกหนึ่ง layer นั่นคือ Model เนื่องจาก ViewController นั้นต้องการเพียงข้อมูลเพื่อส่งไปแสดงผลที่ View เท่านั้น ไม่ได้ต้องการ Network เลย แสดงการทำงานดังรูป แต่จากรูปแบบนี้ก็ยังคงมีปัญหากับ Network อยู่ใช่ไหม ? เนื่องจากเราเพียงย้ายให้ Network ไปทำงานกับ Model เท่านั้นเอง ดังนั้น จะแก้ไขปัญหานี้อย่างไรดีล่ะ ? สิ่งที่ต้องทำก็คือ Model นั้นให้เป็น Persistent model ที่อยู่บนเครื่อง หรือ Local ซะ และเพิ่มส่วนของ Application Logic ขึ้นมา เพื่อทำงานร่วมกับ Network แทน โดยแบ่งการทำงานเป็นส่วน ๆ ดังนี้ ส่วนที่ 1 เมื่อ Application logic ได้ข้อมูลจาก Network หรือ sync data เรียบร้อยแล้ว จะทำการส่ง หรือ จัดเก็บไปที่ Persistent Model แสดงการทำงานดังรูป ส่วนที่ 2 ส่วนของ ViewController เมื่อต้องการข้อมูลไปแสดงผลที่ View ก็ให้ทำการดึงข้อมูลจาก Persistent Model แทน ซึ่งไม่ต้องรออะไรเลย แสดงการทำงานดังรูป ส่วนที่ 3 เมื่อมีการร้องขอ หรือ ส่งข้อมูลมาจากผู้ใช้งานผ่าน View จะทำการส่งการร้องขอมายัง ViewController จากนั้นจะส่งการร้องขอไปยัง Application Logic เพื่อทำงาน ซึ่งจะทำงาน 2 อย่าง คือ

1. ทำการ update ข้อมูลที่ Persistent Model
2. ทำการส่งข้อมูลไปยัง Network

จากนั้นเมื่อฝั่ง Network ส่งข้อมูลกลับมายัง Application Logic แล้ว จะทำการ update ข้อมูลที่ Persistent Model และแจ้งกลับไปยัง ViewController ว่าคำร้องขอเสร็จเรียบร้อยแล้ว แสดงการทำงานดังรูป

มาถึงตรงนี้อาจจะงงอีกว่า จะแจ้งกลับไปยัง ViewController ยังไงว่าทำงานเสร็จแล้ว ?

น่าคิดมาก ๆ ดังนั้นในขั้นตอนการส่งคำร้องขอตั้งแต่แรก ต้องมีการจัดการ event หรือ เหตุการณ์ต่าง ๆ ไว้ก่อนนะ นั่นคือมีการ register event และ subscribe ไว้ เมื่อมีการทำการเสร็จสิ้นก็ให้ทำการส่ง notify ไปยัง subscribe นั้น ๆ จากนั้นก็ทำการ unsubscribe ซะ เป็นอันพบขั้นตอนการทำงาน แนวคิดพวกนี้มันคือ EventBus นั่นเอง แต่ทำมาเยอะขนาดนี้ มันก็ยังไม่ปัญหาตามมาอีก นั่นคือ เรื่องของ Background process ถ้า queue การทำงานมันค้าง และ เต็ม ทำให้ process อื่น ๆ ที่อยู่ใน queue รอไปเรื่อย ๆ จะส่งผลให้ app ค้าง หรือ ปิดตัวไปอีก แสดงการทำงานดังรูป การแก้ไขปัญหานี้คือ ก็ให้แยก queue ของการทำงานให้ทำงานคนละ Thread ไป นั่นคือ

• Network task queue
• Local task queue

ส่งผลให้ app ของเราทำงานได้รวดเร็ว (Responsive) แสดงการทำงานดังรูป

สามารถสรุปการทำงานในส่วนของ Activity สำหรับการ Notify ได้ดังนี้ ( Activity State Machine )

• onCreate() ทำการ setup พวก User Interface ต่าง ๆ
• onStart() ทำการ register event เช่น การดึงข้อมูล
• เมื่อเกิด event ขึ้นมา หรือ onEvent() หรือ ดึงข้อมูลเสร็จแล้ว จะทำการ refesh ข้อมูลใหม่
• onStop() ทำการ unregister event

ซึ่งจะเห็นได้ว่ามันเรียบง่าย และง่ายต่อการทำความเข้าใจอย่างมาก

Key Takeaway มีดังนี้

• Design for offline เนื่องจากเรื่องของ network มันไม่เคยเป็นมิตรกับใครเลย
  • ให้ส่วนของ User Interface ใช้ข้อมูลจาก model
  • ส่วนของ network และการ update model ให้ Application Logic จัดการ
  • ให้แต่ละส่วนทำงานเป็นอิสระจากกัน อาจจะใช้งาน Event, Callback หรืออะไรก็ได้ที่จำเป็น
• Decoupling แต่ละส่วนแยกกันทำงาน
  • สามารถนำ Dependency Injection มาใช้งานได้
  • มันมีทั้งข้อดีและข้อเสีย ต้องทำความเข้าใจก่อน ไม่ใช่ทำตาม ๆ กันไป
  • อย่าใช้ Reflection API โดยเด็ดขาด เพราะว่ามันทำให้ performance ต่ำลงไปมาก ดังนั้นเลือก library ให้ระวังกันด้วย
• Design API
  • ออกแบบ API เพื่อฝั่ง client หรือ ผู้ใช้งานนะ
  • ให้ฝั่ง client ทำงานน้อยที่สุด
  • ให้ฝั่ง server ทำงานมากที่สุด
• Act locally, Sync Globally !!

และยังมีเรื่องอื่น ๆ อีกมากมาย ลองดูต่อจาก VDO ข้างต้นได้เลยครับ มีสิ่งที่น่าสนใจให้เราเรียนรู้อีกมากมาย