ถึงแม้ว่า Jetpack Compose จะเป็น UI Framework ทางเลือกสำหรับการพัฒนาแอปบนแอนดรอยด์ที่มีความน่าสนใจและเป็นที่พูดถึงกันอย่างมากในปัจจุบัน แต่การพยายามนำมาใช้ในโปรเจคแบบสุ่มสี่สุ่มห้าก็คงจะไม่ดีเท่าไร ทำให้เจ้าของบล็อกตัดสินใจเขียนบทความนี้ขึ้นมาเพื่อแนะนำรูปแบบในการนำ Jetpack Compose ไปใช้งานในโปรเจคที่อาจจะมีโครงสร้างแตกต่างกันไปครับ
บทความในชุดเดียวกัน
- Stateless & Stateful Composable
- State Hoisting
- Slot API
- Shape
- UI Preview
- Composition Local
- Adoption Strategy [Now Reading]
โดยเจ้าของบล็อกขอแบ่งเป็น 4 รูปแบบดังนี้
- ใช้ Jetpack Compose แบบ 100% – เหมาะกับโปรเจคที่ต้องเขียนใหม่ทั้งหมด
- ใช้ในฟีเจอร์ใหม่ – เหมาะกับโปรเจคที่ใช้ Android View อยู่
- ใช้กับหน้าใหม่ – เหมาะกับโปรเจคที่ใช้ Android View อยู่
- ใช้กับ Android View ที่มีอยู่แล้ว – ไม่ค่อยแนะนำ
![](https://akexorcist.dev/content/images/2024/07/jetpack_compose_integration_strategy-001.webp)
ใช้ Jetpack Compose แบบ 100%
เหมาะกับ – โปรเจคที่ต้องเขียนขึ้นมาใหม่ตั้งแต่ต้น (ถ้าเป็นโปรเจคในบริษัท คุณต้องโชคดีประมาณนึงเลย)
การนำ Jetpack Compose มาใช้ในโปรเจคแบบ 100% จะทำให้นักพัฒนาได้ใช้ความสามารถของ Jetpack Compose อย่างเต็มที่ทั้งในส่วนของ UI และ Navigation โดยนักพัฒนาสามารถเลือกได้ว่าจะทำเป็น Single Activity เพื่อให้ Navigation ทั้งหมดอยู่ภายใต้ Jetpack Compose ไปเลย
![](https://akexorcist.dev/content/images/2024/07/jetpack_compose_integration_strategy-002-1.webp)
หรือจะมี Activity มากกว่าหนึ่งตัวก็ไม่มีปัญหา เพราะบางครั้งเราก็ต้องการแยกบางฟีเจอร์ออกมาอยู่ใน Activity คนละตัวเพราะมี Flow ที่ซับซ้อนหรือมีการทำงานที่ไม่อยากให้กระทบกับ Activity หลัก เช่น Deep Link ที่จะให้ Activity อีกตัวจัดการให้แทนก่อน เป็นต้น
![](https://akexorcist.dev/content/images/2024/07/jetpack_compose_integration_strategy-003-1.webp)
แต่การมีหลาย Activity ก็หมายความว่าจะมี Back Stack แยกกันระหว่าง Composable Function กับ Activity ด้วยเช่นกัน ดังนั้นควรวางแผนให้ดีว่ารูปแบบการทำงานจะเป็นไปในทิศทางไหน เช่น Activity ที่สร้างแยกขึ้นมาควรเป็นฟีเจอร์ที่จบในตัว หรือลดการทำ Navigation ระหว่าง Activity เท่าที่ทำได้เพื่อลดความซับซ้อนที่ไม่จำเป็น เป็นต้น
นอกจากนี้การใช้ Jetpack Compose ทั้งโปรเจคจะสะดวกตรงที่นักพัฒนาสามารถวาง Codebase ในโปรเจคเพื่อให้เอื้อกับ Jetpack Compose โดยไม่ต้องสนใจ Android View ได้เลย
ใช้ในฟีเจอร์ใหม่
เหมาะกับ – โปรเจคที่มีอยู่แล้ว และต้องการนำ Jetpack Compose มาใช้งาน
การสร้างฟีเจอร์ใหม่ด้วย Jetpack Compose ในโปรเจคที่มีการใช้ Android View อยู่แล้ว จะช่วยให้การสร้าง UI ทำได้รวดเร็วกว่าเดิม โดยจะทำเป็น Activity หรือ Fragment ก็ได้ และมี Navigation ภายในตัวเองได้เลย เมื่อฟีเจอร์อื่นจะเปิดฟีเจอร์นี้ก็ให้ทำ Navigation ในระดับ Activity หรือ Fragment แทน
![](https://akexorcist.dev/content/images/2024/07/jetpack_compose_integration_strategy-004.webp)
แต่สิ่งที่ต้องคิดต่อคือ Codebase เดิมที่มีอยู่ในโปรเจค เพราะมีโอกาสสูงมากที่โค้ดเหล่านั้นจะไม่เอื้อต่อการใช้กับ Jetpack Compose เนื่องจากผูกโค้ดไว้กับ Android View ตั้งแต่แรก (โค้ดเหล่านั้นอาจจะเขียนขึ้นมาก่อนที่ Jetpack Compose จะถูกสร้างขึ้นมาด้วยซ้ำ) เช่น Base Class ของ Activity, Fragment, และ ViewModel เป็นต้น ดังนั้นการตัดสินใจเขียนโค้ดเหล่านี้ขึ้นมาใหม่เพื่อให้รองรับกับ Jetpack Compose โดยเฉพาะก็จะเป็นทางเลือกที่ดีกว่า
และการทำงานที่มีเงื่อนไขพิเศษในบางกรณีก็อาจจะต้องเขียนแยกสำหรับ Jetpack Compose โดยเฉพาะและได้ผลลัพธ์ที่ต่างไปจากเดิม
ยกตัวอย่างเช่น โค้ดกลางสำหรับ Snackbar ที่เคยทำไว้ที่กำหนด Anchor View เพื่อให้แสดงอยู่เหนือ View ที่ต้องการได้ ซึ่งจะติดปัญหาว่าทำแบบนั้นใน Jetpack Compose ไม่ได้ และในฟีเจอร์นั้นก็อยากให้ Snackbar แสดงอยู่เหนือปุ่มเหมือนกัน ทำให้ต้องสร้าง Snackbar สำหรับ Jetpack Compose ขึ้นมาโดยเฉพาะ และมีข้อจำกัดว่า Snackbar จะหายไปทันทีเมื่อกดออกจากฟีเจอร์นั้น
ใช้กับหน้าใหม่
เหมาะกับ – โปรเจคที่มีอยู่แล้ว และต้องการนำ Jetpack Compose มาใช้งาน
จะรอใช้ Jetpack Compose เฉพาะตอนทำฟีเจอร์ใหม่ก็อาจจะต้องรอจนกว่าจะมีฟีเจอร์ใหม่มาให้ทำ ดังนั้นการใช้ Jetpack Compose ในฟีเจอร์เก่าที่มีการเพิ่มหน้าใหม่ก็นับว่าเป็นไอเดียที่ดีเช่นกัน
โดยนักพัฒนาสามารถสร้างหน้าใหม่ด้วย Fragment และสร้าง UI ด้วย Jetpack Compose ได้เช่นกัน แต่รูปแบบนี้จะต้องใช้ Navigation ของเดิมเพื่อให้ทำงานร่วมกับ Fragment ตัวอื่นที่อยู่ในฟีเจอร์นั้น
![](https://akexorcist.dev/content/images/2024/07/jetpack_compose_integration_strategy-005.webp)
วิธีนี้จะต้องคำนึงเรื่องเดียวกับวิธีก่อนหน้าที่ต้องดู Codebase เดิมที่มีอยู่ด้วย แต่ความสะดวกอย่างหนึ่งของการใช้ Jetpack Compose แบบนี้คือไม่ต้องกังวลเรื่องการส่งข้อมูลระหว่างหน้า เพราะให้หน้าอื่น ๆ ส่งข้อมูลเข้ามาทาง Fragment ตามปกติเลย แล้วค่อยส่งต่อเข้ามาใน Composable Function อีกที
ใช้กับ Android View ที่มีอยู่แล้ว
เหมาะกับ – อยากใช้ Jetpack Compose แทน Android View แค่บาง UI Component
เนื่องจาก Jetpack Compose สามารถ Interop หรือใช้งานร่วมกับ Android View ได้ จึงทำให้นักพัฒนาสามารถใช้ Android View เหมือนเดิม แล้วสร้าง UI Component บางตัวด้วย Jetpack Compose ได้ (หรือจะเอา Android View ไปใช้ใน Jetpack Compose ก็ได้เช่นกัน)
![](https://akexorcist.dev/content/images/2024/07/jetpack_compose_integration_strategy-006-3.webp)
โดย UI ที่สร้างด้วย Jetpack Compose แนะนำให้สร้างเป็น Stateless Composable เพื่อลดปัญหาในการนำไปใช้งานกับ Android View ให้น้อยที่สุด
แต่โดยส่วนตัวไม่ค่อยแนะนำให้ใช้ Jetpack Compose กับรูปแบบนี้ซักเท่าไร เพราะได้ประโยชน์จากการทำงานของ Jetpack Compose น้อย และการกำหนดค่าให้กับ Android View และ Jetpack Compose ก็ต่างกัน ซึ่งอาจจะทำให้โค้ดในโปรเจคซับซ้อนขึ้นโดยไม่จำเป็นได้
สรุป
Jetpack Compose นั้นเป็น UI Framework ที่มีข้อดีมากมายเมื่อเทียบกับการเขียน UI ด้วย Android View แบบเดิม ๆ ซึ่งนักพัฒนาไม่จำเป็นต้องรอใช้ Jetpack Compose เฉพาะตอนขึ้นโปรเจคใหม่เท่านั้น นำมาใช้กับโปรเจคที่มีอยู่แล้วก็ได้เช่นกัน
แน่นอนว่าการใช้ Jetpack Compose จะมีเรื่องอื่น ๆ ที่ต้องพิจารณาตามมาด้วย เช่น โค้ดเดิมที่มีอยู่อาจจะผูกกับการทำงานของ Android View มากเกินไปจนทำให้โค้ดนั้นไม่รองรับ Jetpack Compose หรือรูปแบบการ Navigation ที่ใช้อยู่ในโปรเจค เป็นต้น
ดังนั้นก่อนจะเริ่มนำไปใช้งานก็ควรเลือกรูปแบบและวางแผนให้เหมาะสมกับโปรเจคของเราด้วยนะครับ