เมื่อพูดถึง Android ก็คงจะนึกถึง Samsung กันบ้างเป็นบางครั้ง เพราะ Samsung นั้นเป็นหนึ่งในแบรนด์ใหญ่ที่เข้ามาคลุกวงในกับ Android มานานพอสมควรแล้ว ซึ่งในปี 2017 นี้ก็ได้เปิดตัว Samsung Galaxy S8/S8+ กับ Samsung DeX ไป (ถ้าของไทยก็เปิดตัวในวันที่เขียนบทความนี้นี่แหละ) และสิ่งที่เจ้าของบล็อกจะมาพูดถึงนั้นไม่ได้เน้นไปที่ฝั่ง Customer ซักเท่าไร แต่เป็นฝั่ง Developer ที่ควรรู้และปรับตัวให้ทันกับ Samsung ในปัจจุบันและวันข้างหน้าฮะ
เกริ่นเรื่องเกริ่นราว
สำหรับผู้ใช้ทั่วไปส่วนใหญ่ก็คงจะรู้จักกับแบรนด์ Samsung ในฐานะหนึ่งใน Smartphone ยอดนิยมกันอยู่แล้วเนอะ แล้วมุมของนักพัฒนาแอนดรอยด์ล่ะ?
ซึ่งในอดีตนั้น Samsung ก็เป็นหนึ่งในแบรนด์ที่ทำให้นักพัฒนาต้องเจอกับคำว่า Android Fragmentation น่ะแหละ ฮาๆ มีทั้งสเปคเครื่องและขนาดหน้าจอที่แตกต่างกันออกไปมากมาย ยังไม่รวมไปถึงฟีเจอร์ต่างๆที่ Samsung ยัดมาให้อีกมากมาย
แต่ถึงกระนั้น Samsung ก็เป็นเพียงไม่กี่เจ้าที่เปิดฟีเจอร์ต่างๆนานาให้นักพัฒนาได้ใช้งานในรูปแบบของ SDK (อีกเจ้าก็ Sony) จึงทำให้หลายๆฟีเจอร์นั้นไม่ได้รองรับแค่แอปของ Samsung เองเท่านั้น นักพัฒนาก็เอาไปทำเพิ่มเองได้เหมือนกัน ถ้าจะมีปัญหาก็มีอยู่อย่างเดียวคือ นักพัฒนาขี้เกียจเขียนโค้ดเพิ่ม ฮาๆ
เมื่อเทียบกับแบรนด์อื่นๆแล้วที่ทำฟีเจอร์ออกมาใช้งานได้กับแอปของตัวเองอย่างเดียวเท่านั้น สาเหตุหลักก็คือมันเป็นเรื่องยากที่จะดึงให้นักพัฒนามาเพิ่มโค้ดให้รองรับกับฟีเจอร์ของเจ้านั้นๆได้
แต่ Samsung ไม่ได้ทำแบบนั้น เพราะทุกวันนี้ได้ปล่อย SDK ต่างๆนานามากมายให้นักพัฒนานำไปใช้งานเพื่อให้แอปทำงานกับฟีเจอร์เฉพาะของ Samsung ได้
ซึ่งเหล่า SDK ก็ดูแลกันแบบจริงจังเลยนะ ไม่ใช่ว่าทำๆออกมาแล้วก็ปล่อยๆทิ้งไว้ เพราะจากที่เจ้าของบล็อกสังเกตมานานพอสมควรก็พบว่า SDK เหล่านี้มีการอัพเดทเรื่อยๆ (ถ้ามีอะไรที่ต้องเพิ่มเข้ามาน่ะนะ) และยังมีการแจ้ง Deprecated สำหรับ SDK ตัวที่ไม่ได้ใช้งานในเวอร์ชันใหม่ๆแล้วด้วย
การเปลี่ยนแปลงที่เกิดขึ้นในยุคของ Android 7.0
เมื่อ Samsung เพิ่มฟีเจอร์ใหม่ๆที่มี SDK เข้ามา ก็ต้องให้นักพัฒนาไปเพิ่มโค้ดเพิ่ม SDK กันเอง เพื่อให้ใช้งานฟีเจอร์นั้นๆได้ (ถึงแม้หลายๆฟีเจอร์จะใส่โค้ดแค่นิดเดียวก็ตาม) ดังนั้นก็อย่าแปลกใจที่ทุกวันนี้มีแค่บางแอปเท่านั้นที่รองรับฟีเจอร์พิเศษของ Samsung (ถึงแม้แอปส่วนใหญ่มีผู้ใช้เป็น Samsung มากกว่า 50% จากยอดผู้ใช้ทั้งหมดก็ตาม)
แต่สิ่งที่เจ้าของบล็อกเริ่มสังเกตเห็นก็คือ “ฟีเจอร์ใหม่ๆของ Samsung จะเริ่มเข้าไปครอบอยู่บนการทำงานของ Pure Android เดิม โดยที่นักพัฒนาทำอะไรน้อยลงหรือแทบไม่ต้องทำอะไร”
อย่างเช่น MultiWindow ที่เดิมทีใช้ได้แค่บนเครื่อง Samsung เท่านั้น พอมาเป็น Android 7.0 Nougat แล้วก็ทำให้ทุกรุ่นใช้งานฟีเจอร์นี้ได้ทั้งหมด
ซึ่งเดิมทีนั้นการทำแอปให้รองรับกับ MultiWindow บนเครื่อง Samsung ก็คือการเพิ่มโค้ดบางอย่างเข้าไป (ฟีเจอร์นี้ทำให้รองรับได้ง่ายมาก โดยไม่ต้องใช้ SDK ก็ได้) แต่ถ้าเครื่องไหนของ Samsung ได้อัปเดตเป็น Android 7.0 Nougat ปุ๊ป ก็จะย้ายไปทำงานอยู่บนพื้นฐานของ Pure Android ทันที
หรือก็คือบางฟีเจอร์ของ Samsung จะเริ่มไปทำงานอยู่บนพื้นฐานเดิมของ Pure Android เพื่อที่นักพัฒนาจะได้ไม่ต้องทำอะไรเพิ่ม เพียงแค่ใส่ใจกับ Best Practice ตาม Guideline ของ Android ก็พอ
ยกตัวอย่างเช่น…
การเปลี่ยนแปลงของฟีเจอร์ Fingerprint
Fingerprint ถือว่าเป็นหนึ่งในฟีเจอร์ที่หลายๆแบรนด์เริ่มเอาเข้ามาใช้บนอุปกรณ์แอนดรอยด์ แต่ปัญหาหลักสำหรับนักพัฒนาก็คือ เข้าไปใช้งานไม่ได้ เพราะหลายๆแบรนด์สร้างขึ้นมาเพื่อใช้งานกับแอปของตัวเองเท่านั้น
ซึ่งแบรนด์ไหนที่ออกอัปเดตให้รองรับ Android 6.0 Marshmallow ได้ และมี Fingerprint Scanner อยู่ในเครื่อง นักพัฒนาก็จะสามารถใช้งาน Fingerprint ผ่าน Fingerprint API ของ Android ได้
แต่ก็มี Samsung เจ้าเดียวนี่แหละฮะ ที่ออก Pass SDK ให้เรียกใช้งานได้ และพอ Android มีการเปิดตัว Android 6.0 Marshmallow ที่มาพร้อมกับฟีเจอร์ Fingerprint ก็ทำให้ Samsung ย้ายการทำงานของ Fingerprint ตัวเองไปอยู่บน Fingerprint API ของ Pure Android แทน (ก็ต้องเขียนโค้ดให้ทำงานแยกกัน)
เจ้าของบล็อกเคยเจอปัญหาลูกค้าให้ใส่ฟีเจอร์ Fingerprint ไว้ในแอปแล้วลูกค้าพบว่าบางเครื่องใช้งานฟีเจอร์ดังกล่าวไม่ได้ ทั้งๆที่เครื่องนั้นมี Fingerprint Scanner ซึ่งสาเหตุก็เกิดมาจากเครื่องนั้นๆแบรนด์อื่นที่ไม่ใช่ Samsung และเป็นเวอร์ชันต่ำกว่า Android 6.0 Marshmallow (ก็ต้องอธิบายกันยกใหญ่พอสมควร)
การเปลี่ยนแปลงของฟีเจอร์ MultiWindow
MultiWindow เดิมทีนั้นเป็นหนึ่งในฟีเจอร์ชูโรงของเครื่อง Samsung เลยก็ว่าได้ ซึ่งในภายหลังก็ถูกเอามาใส่ไว้ใน Android 7.0 Nougat เป็นที่เรียบร้อยแล้ว
ซึ่งก็เหมือนเดิมฮะ เมื่อเครื่อง Samsung เครื่องไหนที่ได้อัปเดตเป็น Android 7.0 Nougat ก็จะย้ายการทำงานของ MultiWindow มาครอบอยู่บน Multi-Window ของ Pure Android
จากที่เจ้าของบล็อกเคยทำแอปให้รองรับ MultiWindow ของ Samsung จริงๆที่ทำเพิ่มก็แค่ใส่ Metadata แค่บรรทัดเดียว แต่พอมาเป็น Multi-Window บน Android ก็จะเพิ่มเติมเรื่องการ Handle Instance State และ Configuration Change เท่านั้น ซึ่งเป็น Best Practice ของ Android ที่นักพัฒนาต้องทำอยู่แล้ว เรียกได้ว่าแทบไม่ต้องทำอะไร (ถ้าเขียนมาอย่างถูกต้องตั้งแต่แรก)
การเปิดตัวของ Samsung Galaxy S8/S8+ ที่มาพร้อมฟีเจอร์ใหม่ๆ
โดยปกติแล้วในทุกๆปีที่ Samsung เปิดตัว Flagship อย่างตระกูล S และ Note เจ้าของบล็อกก็จะคิดในใจอยู่เสมอว่า “จะมีฟีเจอร์อะไรที่ทำให้ต้องเขียนโค้ดเพิ่มอีกว้า” เพราะที่ผ่านมาก็จะเป็นแนวๆนี้อยู่เสมอ
แต่ในคราวนี้ฟีเจอร์ที่เปิดตัวมาพร้อมกับ Samsung Galaxy S8/S8+ กลับเปลี่ยนแปลงไปจากเดิมโดยสิ้นเชิงเมื่อได้รู้เบื้องหลังการทำงานของฟีเจอร์ต่างๆที่นักพัฒนาสามารถรองรับได้ เพราะไม่มี SDK เพิ่มมาเลยซักตัว!!
โดยฟีเจอร์ที่เปิดมาใหม่ในครั้งนี้ที่ส่งผลกับนักพัฒนาจะมีดังนี้
- หน้าจอที่อัตราส่วนไม่เหมือนใคร (18.5 : 9) ซึ่งการทำให้รองรับหน้าจอแบบนี้ทาง Samsung ใช้ชื่อเรียกว่า Full Screen Apps
- Samsung DeX ที่จะเปลี่ยนจาก Smartphone ให้กลายเป็น Desktop ได้
การทำให้รองรับ Full Screen Apps
การเปิดตัวเครื่องที่มีหน้าจออัตราส่วน 18.5 : 9 จะเรียกว่าเอาแต่ใจก็ว่าได้ (พอๆกับ LG G6 ที่มีหน้าจอเป็นอัตราส่วน 18 : 9 น่ะแหละ) แต่สิ่งที่เกิดขึ้นก็คือ “ไม่ใช่ทุกแอปที่ถูกบังคับให้แสดงผลบนอัตราส่วนนี้” เข้าใจว่าทาง Samsung ก็น่าจะเข้าใจถึงเรื่องนี้อยู่เหมือนกัน เพราะแอปที่มีให้ดาวน์โหลดอยู่ทุกวันนี้ มีอยู่หลายตัวที่ไม่ได้ทำให้ Responsive กับหน้าจอทุกขนาด
การทำให้แอปแสดงผลได้ Responsive กับหน้าจอทุกขนาดถือว่าเป็นหนึ่งในพื้นฐานของการพัฒนาแอป ซึ่งนักพัฒนาต้องเรียนรู้และเข้าใจถึงความแตกต่างของหน้าจอแต่ละขนาด และการจัด Layout ให้ยืดหยุ่นอยู่แล้ว ดังนั้นเจ้าของบล็อกจะข้ามเรื่องนี้ไปเลยนะ
ดังนั้นโดย Default แล้ว การแสดงผลบนหน้าจอแบบนี้ แอปที่ไม่รองรับจะถูกบีบให้อยู่ในอัตราส่วน 16 : 9 แทน ซึ่งผู้ใช้สามารถเข้าไปตั้งค่าใน Settings ได้ว่าจะให้แอปไหนแสดงผลแบบ Full Screen
ซึ่งปัจจัยที่ Samsung ดูว่าแอปนั้นๆรองรับกับ Full Screen Apps หรือไม่ มีอยู่ 3 อย่างด้วยกัน
- SDK Version ที่กำหนดไว้ใน
build.gradle
- Attribute ใน Android Manifest ที่ชื่อว่า
android:resizeableActivity
- Metadata ใน Android Manifest ที่ชื่อว่า
android.max_aspect
รู้จักกับ Attribute ที่ชื่อ android:resizeableActivity
เป็น Attribute ที่เพิ่มเข้ามาใหม่ใน Android 7.0 Nougat เพื่อให้นักพัฒนาสามารถประกาศได้ว่าแอปนั้นรองรับ Multi-Window หรือไม่ สามารถประกาศได้ทั้ง Application Level และ Activity Level แต่ถ้าจะให้แนะนำ ก็ควรกำหนดไว้ใน Application Level
รู้จักกับ Metadata ที่ชื่อ android.max_aspect
เป็น Metadata ตัวใหม่ที่ดูเหมือนว่าทางทีม Android ใส่ไว้พักหนึ่งแล้ว แต่ไม่ได้พูดถึงเลยซักนิด ซึ่งทำให้ Samsung Galaxy S8/S8+ และ LG G6 รู้ได้ว่าแอปนั้นรองรับอัตราส่วนหน้าจอของตัวเครื่องหรือไม่
การทำงานของ Metadata ตัวนี้ก็คือแค่เอาไว้บอกว่าแอปของผู้ที่หลงเข้ามาอ่านนั้นรองรับกับอัตราส่วนหน้าจอมากที่สุดคือเท่าไร วิธีคำนวณก็ง่ายๆเลยจับอัตราส่วนมาหารกันซะ
- อัตราส่วน 4:3 จะเท่ากับ 4 / 3 = 1.33
- อัตราส่วน 16:10 จะเท่ากับ 16 / 10 = 1.60
- อัตราส่วน 16:9 จะเท่ากับ 16 / 9 = 1.78
- อัตราส่วน 18:9 จะเท่ากับ 18 / 9 = 2.00
- อัตราส่วน 18.5:9 จะเท่ากับ 18.5 / 9 = 2.06
โดยปกติแล้วถ้าไม่ได้ใส่ไว้จะถูกกำหนดไว้เป็น 1.86 ซึ่งรองรับทั้ง 4:3, 16:10 และ 16:9
ดังนั้นนักพัฒนาควรดูว่าแอปของตัวเองนั้นรองรับอัตราส่วนมากที่สุดเท่าไร แล้วกำหนดไว้ใน Android Manifest ซะ
รูปแบบการรองรับในหน้าตั้งค่า Full Screen Apps
โดยรูปแบบการรองรับจะแสดงให้เห็นในหน้าตั้งค่า Full Screen Apps อยู่ 3 แบบด้วยกัน
- May not work properly : อาจจะแสดงผลไม่ได้ แต่ยังสามารถเปิดปิดได้ตามใจชอบ (ถ้าไม่เวิร์กก็ค่อยปิด)
- Manually : สามารถเปิดปิดได้ตามใจชอบ (ถ้าไม่เวิร์กก็ค่อยปิด)
- Fully Supported : รองรับ Full Screen Apps อยู่แล้ว (เปิดโดยอัตโนมัติ)
May not work properly
- กำหนด SDK Version ไว้ต่ำกว่า 24
- ประกาศ
android:resizeableActivity="false"
ไว้
Manually
- กำหนด SDK Version ไว้มากกว่าหรือเท่ากับ 24
- ไม่ได้ประกาศ
android:resizeableActivity
- ไม่ได้ประกาศ
android.max_aspect
หรือกำหนดค่าไว้ต่ำกว่า 2.06
Fully Supported
กรณีที่หนึ่ง
- กำหนด SDK Version ไว้มากกว่าหรือเท่ากับ 24
- ประกาศ
android:resizeableActivity="true"
กรณีที่สอง
- กำหนด SDK Version ไว้มากกว่าหรือเท่ากับ 24
- ประกาศ
android.max_aspect
ไว้มากกว่าหรือเท่ากับ 2.06
การเปิด/ปิด Full Screen Apps ทำให้เกิด Configuration Changes
เป็นอีกเรื่องหนึ่งที่นักพัฒนามักจะมองข้ามกันไป เมื่อผู้ใช้เข้าไปในเปิด/ปิด Full Screen Apps ในหน้า Settings เมื่อกลับมาเปิดแอปใหม่ จะเกิดสิ่งที่เรียกว่า Configuration Changes (เพราะขนาดหน้าจอมีการเปลี่ยนแปลง) ดังนั้นแอปก็ควรจัดการกับ Instance State ไว้ด้วย (ปกติก็ต้องทำอยู่แล้วนะ)
Samsung DeX อีกหนึ่งในฟีเจอร์ที่นักพัฒนาต้องเรียนรู้
เป็นหนึ่งในความสามารถของ Samsung Galaxy S8/S8+ ที่เจ้าของบล็อกเชื่อว่าซักวันหนึ่งมันจะเข้ามากลายเป็นสิ่งสำคัญที่นักพัฒนาต้องเรียนรู้และเข้าใจอย่างแน่นอน
ซึ่งการที่แอปแสดงผลอยู่บนหน้าจอแบบ Phone แล้วสามารถสลับไปแสดงในรูปแบบ Desktop ได้เนี่ย อาจจะดูเหมือนว่านักพัฒนาต้องทำอะไรเยอะมาก แต่เอาเข้าจริงแล้วแทบไม่ต้องจะทำอะไรก็สามารถรองรับ Samsung DeX ได้เลย ขอแค่เขียนแอปตาม Best Practice ตาม Guideline ของ Android ก็พอ
ส่วนเรื่องราวของการทำแอปให้รองรับกับ Samsung DeX ก็แนะนำให้ไปอ่านที่บทความ Samsung DeX ในฉบับนักพัฒนา ทำแอป ฯ อย่างไรให้ใช้งานบน DeX ได้สมบูรณ์ เค้าเขียนไว้ละเอียดยิบแล้วล่ะ
แต่ก็ขอเพิ่มเติมเนื้อหาเกี่ยวกับ Samsaung DeX อีกนิดหน่อยละกัน
ค่าของหน้าจอแตกต่างกัน ระหว่าง Phone Mode และ DeX Mode
ความฉลาดอย่างหนึ่งของ Samsung DeX ก็คือ ตัวมันเองไปครอบการทำงานอยู่บน Freeform Mode ที่เป็นหนึ่งในความสามารถของ Multi-Window บน Android 7.0 Nougat ดังนั้นจึงไม่ต้องทำอะไรเพิ่มเติม ถ้าแอปไหนรองรับ Multi-Window บน Android 7.0 Nougat อยู่แล้ว ก็จะสามารถทำงานได้ทันที
ส่วนแอปไหนที่ไม่รองรับ เมื่อสลับมาแสดงบน Samsung DeX ก็จะถูกปรับให้แสดงผลในหน้าต่างที่มีขนาดอัตราส่วนเป็นแบบเดียวกับหน้าจอมือถือ ดังนั้นไม่ต้องห่วงเลยว่า Layout ของแอปจะผิดเพี้ยน
ปกติแล้วแอปที่แสดงผลอยู่บนหน้าจอของ Samsung Galaxy S8/S8+ จะมีค่าต่างๆของหน้าจอดังนี้
Phone Mode
- Resolution (px) : 2,960 x 1,440 px
- Resolution (dp) : 740 x 360 dp
- Density : XXXHDPI
- Screen Size : Normal
- UI Mode : Normal
DeX Mode
- Resolution (px) : 1,920 x 1,080 px
- Resolution (dp) : 1,920 x 1,080 dp
- Density : MDPI
- Screen Size : Changing by user settings
- UI Mode : Desk
บน DeX Mode ไม่ว่าจะปรับหน้าต่างขนาดเท่าไร การดึงค่าขนาดหน้าจอจากตัว System ผ่านโค้ดก็จะได้ค่าเป็น 1,920 x 1,080 px อยู่ดี จึงควรระวังตรงจุดนี้ด้วย ถ้ามีการเอาค่าดังกล่าวไปใช้ในการคำนวณค่าบางอย่างในโค้ด
Configuration Change บน Samsung DeX
สิ่งที่เกิดขึ้นตอนสลับระหว่าง Phone Mode กับ DeX Mode ก็คือ Configuration Change นั่นเอง ซึ่งมีทั้ง Resolution และค่า Density ที่เปลี่ยนไป ที่น่าจะส่งผลกับแอปของนักพัฒนามากที่สุด
แอปที่ประกาศ android:configChanges
ไว้ใน Android Manifest แล้วไม่ยอมจัดการให้ถูกต้องตั้งแต่แรกก็จะเจอปัญหานี้ทันที เพราะ Density และ Resolution มีการเปลี่ยนแปลง
ซึ่งการจัดการกับ Configuration Change ให้ถูกต้อง ก็เป็น Best Practice อย่างหนึ่งที่นักพัฒนาจะต้องทำ
อย่างที่บอกไปในตอนแรกว่า แอปตัวไหนที่ไม่รองรับ Multi-Window ก็ยังคงแสดงผลบน DeX Mode ได้อยู่ดี แต่ค่าหน้าจอของแอปที่ไม่รองรับ DeX Mode จะได้เป็นแบบนี้แทน
ไม่รองรับ Multi-Window แต่แสดงผลบน DeX Mode ได้
- Resolution (px) : 731 x 411 px
- Resolution (dp) : 731 x 411 dp
- Density : MDPI
- Screen Size : Normal
ดังนั้น ถึงแม้ว่าจะไม่รองรับ Multi-Window แต่อย่างน้อยก็ควรจัดการกับ Configuration Change ให้ถูกต้องอยู่ดีครับ
และแอปจำเป็นต้องใช้พื้นที่เต็มหน้าจอตลอดเวลา แนะนำว่าควรจะรองรับ Multi-Window ไม่งั้นจะเป็นแบบนี้
เนื่องจาก Facebook Messenger ไม่รองรับ Multi-Window เมื่อแสดงบน Samsung DeX ก็จะมีพื้นที่แค่ 731x411px จึงทำให้ตัว Chat Head ของ Facebook Messenger แสดงผลได้ไม่เต็มจอ (ลากไปมาได้ภายในกรอบเส้นปะเท่านั้น)
เข้าสู่ยุคที่ผู้ใช้สามารถเปลี่ยน Screen Resolution ได้เอง
อุปกรณ์แอนดรอยด์ของ Samsung ที่เป็น Android 7.0 Nougat ขึ้นไปจะสามารถปรับความละเอียดของหน้าจอได้แล้ว ดังนั้นผู้ใช้แค่เข้าไปที่ Settings > Display > Screen Resolution
แล้วปรับความละเอียดที่ต้องการได้เลย
จากที่ลองเล่นหลายๆรุ่น ก็พบว่าไม่ว่าจะ S6, S7, S7 หรือ Note 5 ก็สามารถปรับความละเอียดหน้าจอได้หมด ซึ่งเป็นหนึ่งในฟีเจอร์ของ Samsung ที่จะช่วยให้ประหยัดพลังงานได้ในยามที่ต้องการ และการปรับความละเอียดหน้าจอที่ว่าเป็นแบบ Runtime นะ กดปุ๊ปเปลี่ยนปั๊ป ไม่ต้อง Restart ให้เสียเวลา
นั่นล่ะครับ สิ่งที่นักพัฒนาจะต้องรับมือ
สิ่งที่เกิดขึ้นเมื่อผู้ใช้ปรับความละเอียดหน้าจอ
ในกรณีที่เป็นเครื่องพวก Samsung Galaxy S6, S7 และ Note 5 จะสามารถเปลี่ยนความละเอียดหน้าจอได้ดังนี้
- WQHD : 2,560 x 1,440 px
- FHD : 1,920 x 1,080 px
- HD : 1,280 x 720 px
ซึ่งไม่ว่าจะเปลี่ยนเป็นขนาดเท่าไร แต่ความละเอียดของหน้าจอในหน่วย DP ก็ยังคงเป็น 640x360dp อยู่ดี
ถ้าเป็น Samsung Galaxy S8 ก็จะเปลี่ยนได้ดังนี้
- WQHD+ : 2,960 x 1,440 px
- FHD+ : 2,220 x 1,080 px
- HD+ : 1,480 x 720 px
และไม่ว่าจะเปลี่ยนเป็นขนาดเท่าไร ความละเอียดของหน้าจอในหน่วย DP ก็ยังคงเป็น 740x360dp อยู่ดี
ซึ่งเป็นขนาดหน้าจอที่คล้องจองกับหน้าจอทั่วๆไปอยู่แล้ว ดังนั้นไม่น่าจะส่งผลอะไรมากนักเนอะ แต่สิ่งที่มีการเปลี่ยนแปลงจริงๆแล้วคือ Density ต่างหากล่ะ
เมื่อปรับความละเอียดของหน้าจอของ Samsung Galaxy S6, S7, S8 และ Note 5 ก็จะทำให้ Density ของหน้าจอเปลี่ยนตามไปด้วย
- WQHD/WQHD+ : XXXHDPI
- FHD/FHD+ : XXHDPI
- HD/HD+ : XHDPI
ค่า Density แปรผันไปตามประเภทของอุปกรณ์ด้วย ในบทความนี้ทดสอบกับหน้าจอขนาด Phone ทั้งหมด ดังนั้นบนขนาด Tablet จะแตกต่างกันออกไป
เมื่อ Density มีการเปลี่ยนแปลงทุกครั้ง นั่นก็หมายความว่าเกิด Configuration Change ทุกครั้งนั่นเอง สุดท้ายก็จะวกกลับมาที่ว่านักพัฒนาเขียนแอปให้รองรับกับ Configuration Change อย่างถูกต้องหรือป่าว
สรุปฟีเจอร์ใหม่ๆของ Samsung และแนวโน้มในอนาคต
จากที่เจ้าของบล็อกพูดถึงเรื่องฟีเจอร์ใหม่ๆของ Samsung ที่เพิ่มเข้ามาให้นักพัฒนาต้องรับมือก็จะมีอยู่ 3 อย่างด้วยกันคือ Full Screen Apps, Samsung DeX และ Screen Resolution (มี Multi-Window ด้วย แต่ไม่ถือว่าเป็นเรื่องใหม่เนอะ)
เมื่อดูหัวใจสำคัญของแต่ละฟีเจอร์ว่านักพัฒนาต้องทำอะไรกับมันบ้าง ก็จะสรุปได้ดังนี้
Multi-Window
- Responsive Screen Supporting
- Handling Instance State
- Configuration Changes
Full Screen Apps
- Responsive Screen Supporting
- Handling Instance State
- Configuration Changes
Samsung DeX
- Responsive Screen Supporting
- Handling Instance State
- Configuration Changes
Screen Resolution Changeable
- Responsive Screen Supporting
- Handling Instance State
- Configuration Changes
จะเห็นว่าสุดท้ายแล้วก็เหมือนๆกันทั้งหมดนั่นเอง และที่สำคัญคือมันไม่ใช่เรื่องใหม่ที่นักพัฒนาต้องเรียนรู้เพิ่มเติมเลย แต่เป็นสิ่งที่นักพัฒนาควรรู้อยู่แล้วในพื้นฐานการพัฒนาแอป
แล้วนักพัฒนาต้องรู้อะไรบ้าง? อันนี้คือ Guideline ที่แนะนำให้สำหรับนักพัฒนาที่มองข้ามเรื่องเหล่านี้อยู่ เพื่อให้ไปเรียนรู้ต่อเองได้ครับ
- เข้าใจการทำงานของ Activity/Fragment Life Cycle
- เข้าใจในการจัด Layout หน้าจอให้ยืดหยุ่นได้ ถ้าแยกระหว่างแนวตั้งกับแนวนอน และแยกระหว่าง Phone กับ Tablet ได้ด้วยจะดีมากๆ
- เข้าใจในการจัดการกับ Instance State ที่ทุกๆส่วนของแอป
- เข้าใจวิธีการทำงานของ Configuration Change และวิธีการจัดการอย่างถูกต้อง
เมื่อมองภาพรวมของฟีเจอร์เหล่านี้ก็จะทำให้เห็นว่าฟีเจอร์ใหม่ๆหลังจากนี้ของ Samsung มีแนวโน้มว่าจะครอบอยู่บนการทำงานพื้นฐานของ Pure Android โดยที่นักพัฒนาไม่ต้องทำอะไรเพิ่ม ขอแค่ทำให้แอปสามารถทำงานได้บนฟีเจอร์หลักของ Android ก็พอ แต่ถ้าเป็นฟีเจอร์เฉพาะทางก็คงไม่พ้น SDK อยู่ดีน่ะแหละ (แต่ก็จะมีน้อยลงเรื่อยๆ)
ซึ่ง Samsung DeX ถือว่าเป็นตัวอย่างฟีเจอร์ที่ดีมากของ Samsung ที่แสดงให้เห็นว่าในมุมมองของผู้ใช้ทั่วไปอาจจะรู้สึกว่ามันเป็นฟีเจอร์ที่แตกต่างไปจากเดิมอย่างสิ้นเชิง แต่ในมุมมองของนักพัฒนาคือแทบจะไม่ต้องทำอะไรเพิ่ม (และเจ้าของบล็อกเชื่อว่านี่คือ Experiment อย่างหนึ่งของ Samsung กับ Android ที่จะถูกนำไปใส่ไว้ใน Android เวอร์ชันใหม่ๆในอนาคตอย่างแน่นอน)
สุดท้ายนี้ ขอฝากทิ้งท้ายให้กับบทความนี้ว่า
วันนี้ผู้ที่หลงเข้ามาอ่านเขียนโค้ดถูกต้องตาม Best Practice ใน Guideline ของ Android แล้วหรือยัง?