
ไปอ่านดู feature ที่น่าสนใจใน Android Studio 3.6 พบว่าเยอะมาก หนึ่งในนั้นคือ การใช้งาน view binding แทนการใช้งาน method findViewById() ไปเลย ที่สำคัญใช้งานได้ทั้ง Java และ Kotlin ด้วย

สำหรับ Android developer ตัวจริงน่าจะใช้ Android Studio 3.4 หรือ 3.5 กันไปแล้ว แต่สำหรับคนไม่ชอบการ update แล้ว project fail ทุกครั้ง ก็คงต้องชอบกับ Android Studio 3.3 ตัวเต็ม ๆ ซึ่งไส้ในคือ IntelliJ IDE 2018.2.2 รวมไปถึงสนับสนุน Kotlin 1.3.11 ซึ่งมีความสามารถที่น่าสนใจพอควร มาดูใน feature ที่ผมใช้บ่อย ๆ

จาก 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 นั้นเขาพัฒนากันออกมาอย่างไร ? มีโครงสร้างอย่างไรบ้าง ? ดังนั้นมาลองดูกัน

จากงาน Google I/O 2018 นั้นมีหลายสิ่งอย่างมาก ๆ สำหรับชาว Android จะเห็นได้ว่าทำการสรุปและรวบรวมชุดเครื่องมือต่าง ๆ ไว้ในชื่อใหม่ว่า Android Jetpack ซึ่งช่วยทำให้การพัฒนาง่ายและสะดวกขึ้น ลดจำนวน code ขยะหรือที่ไม่จำเป็นลงไป รวมทั้งช่วยพัฒนาระบบที่มีคุณภาพและเสถียรอีกด้วย บอกได้คำเดียวว่าเพียบ มีทั้งของเก่าและใหม่ มีตัวหนึ่งที่น่าสนใจคือ Navigation หรือ Navigation Architecture Component ดังนั้นมาทำความรู้จักกันหน่อย จะเข้าใจง่ายขึ้น ก็ต้องใช้งานสิ มาเริ่มกันเลย

จดบันทึกไว้นิดหน่อยสำหรับการเขียน Unit test สำหรับทดสอบ Android app ที่พัฒนาด้วย Reactive for Java 2.x (RxJava) ซึ่งมีโครงสร้างง่าย ๆ คือ Presenter สำหรับควบคุมการทำงานหลักของระบบ Repository สำหรับจัดการการดึงข้อมูลจาก REST APIs โดยนำ RxJava มาใช้ในส่วนของ Presenter เพื่อทำงานกับการดึงข้อมูลจาก Repository คำถามที่ตั้งไว้คือ จะทำการทดสอบในส่วนของ Presenter อย่างไรดี ? เพราะว่ามีการใช้งานทั้ง Repository หนักกว่านั้นคือ RxJava นั่นเอง ดังนั้นมาเขียนชุดทดสอบกันดีกว่า

สำหรับการใช้งาน Gradle ทั้ง Android, Backend และ Frontend นั้น ในแต่ละ task นั้นสร้าง cache data ไว้เสมอ ทำให้ทำงานได้เร็วขึ้น แต่ความเร็วของแต่ละเครื่องที่ build ขึ้นอยู่กับการสร้าง cache data นี่แหละ ดังนั้นถ้าแต่ละเครื่องทำการ share cache data ก็น่าจะดีนะ ดังนั้นมาใช้งาน Caching server กันหน่อยดีกว่า เป้าหมายเพื่อความเร็วในการ build นั่นคือทำให้ชีวิตนักพัฒนาดีขึ้น