การจัดการการเปลี่ยนแปลงอินพุต

Chromebook มีตัวเลือกการป้อนข้อมูลที่หลากหลายสำหรับผู้ใช้ ได้แก่ แป้นพิมพ์ เมาส์ แทร็กแพด หน้าจอสัมผัส สไตลัส MIDI และเกมแพด/คอนโทรลเลอร์บลูทูธ ซึ่งหมายความว่าอุปกรณ์เครื่องเดียวกันนี้สามารถกลายเป็นสถานีของดีเจ ผืนผ้าใบของศิลปิน หรือแพลตฟอร์มที่เกมเมอร์ชื่นชอบสำหรับเกมสตรีมมิงระดับ AAA

ในฐานะนักพัฒนาแอป คุณจะมีโอกาสสร้างประสบการณ์การใช้งานแอปที่หลากหลายและน่าตื่นเต้นสำหรับผู้ใช้โดยใช้ประโยชน์จากอุปกรณ์ป้อนข้อมูลที่ผู้ใช้มีอยู่แล้ว ไม่ว่าจะเป็นแป้นพิมพ์ที่ต่ออยู่ สไตลัส หรือตัวควบคุมเกม Stadia อย่างไรก็ตาม ความเป็นไปได้ทั้งหมดนี้ยังกำหนดให้คุณต้องพิจารณา UI เพื่อให้ประสบการณ์การใช้งานแอปเป็นไปอย่างราบรื่นและสมเหตุสมผล โดยเฉพาะอย่างยิ่งหากแอปหรือเกมของคุณออกแบบมาเพื่อโทรศัพท์มือถือ ตัวอย่างเช่น หากเกมมีจอยสติ๊กบนหน้าจอที่ควบคุมด้วยการสัมผัสสำหรับโทรศัพท์ คุณอาจต้องการซ่อนจอยสติ๊กนี้เมื่อผู้ใช้เล่นด้วยแป้นพิมพ์

ในหน้านี้ คุณจะเห็นปัญหาหลักที่ควรคำนึงถึงเมื่อพิจารณาแหล่งข้อมูลหลายแหล่งและกลยุทธ์ในการแก้ไขปัญหาเหล่านั้น

ผู้ใช้ค้นพบวิธีการป้อนข้อมูลที่รองรับ

ในอุดมคติแล้ว แอปควรตอบสนองต่ออินพุตใดก็ตามที่ผู้ใช้เลือกใช้อย่างราบรื่น ซึ่งมักจะเป็นกระบวนการที่ไม่ซับซ้อนและไม่จำเป็นต้องให้ข้อมูลเพิ่มเติมแก่ผู้ใช้ ตัวอย่างเช่น ปุ่มควรทำงานหากผู้ใช้คลิกปุ่มด้วยเมาส์ แทร็กแพด หน้าจอสัมผัส สไตลัส ฯลฯ และคุณไม่จำเป็นต้องบอกผู้ใช้ว่าสามารถใช้อุปกรณ์ต่างๆ เหล่านี้เพื่อเปิดใช้งานปุ่มได้

อย่างไรก็ตาม มีบางสถานการณ์ที่วิธีการป้อนข้อมูลสามารถปรับปรุงประสบการณ์ของผู้ใช้ได้ และอาจสมเหตุสมผลที่จะแจ้งให้ผู้ใช้ทราบว่าแอปของคุณรองรับวิธีการป้อนข้อมูลดังกล่าว ตัวอย่างมีดังต่อไปนี้

• แอปเล่นสื่ออาจรองรับแป้นพิมพ์ลัดที่มีประโยชน์มากมายซึ่งผู้ใช้อาจคาดเดาได้ยาก
• หากคุณสร้างแอป DJ ผู้ใช้อาจใช้หน้าจอสัมผัสในตอนแรกและอาจไม่ทราบว่าคุณอนุญาตให้ใช้แป้นพิมพ์/แทร็กแพดเพื่อเข้าถึงฟีเจอร์บางอย่างได้ ในทำนองเดียวกัน ผู้ใช้ก็อาจไม่ทราบว่าคุณรองรับตัวควบคุม DJ MIDI จำนวนมาก และการกระตุ้นให้ผู้ใช้ตรวจสอบฮาร์ดแวร์ที่รองรับอาจช่วยให้ผู้ใช้ได้รับประสบการณ์การเป็นดีเจที่สมจริงยิ่งขึ้น
• เกมของคุณอาจยอดเยี่ยมเมื่อใช้กับหน้าจอสัมผัสและแป้นพิมพ์/เมาส์ แต่ผู้ใช้อาจไม่ทราบว่าเกมยังรองรับคอนโทรลเลอร์เกมบลูทูธอีกด้วย การเชื่อมต่อบริการเหล่านี้จะช่วยเพิ่มความพึงพอใจและการมีส่วนร่วมของผู้ใช้

คุณช่วยให้ผู้ใช้ค้นพบตัวเลือกการป้อนข้อมูลได้ด้วยการส่งข้อความในเวลาที่เหมาะสม การติดตั้งใช้งานจะแตกต่างกันไปในแต่ละแอป ตัวอย่างเช่น

• ป๊อปอัปที่แสดงครั้งแรกหรือเคล็ดลับประจำวัน
• ตัวเลือกการกำหนดค่าในแผงการตั้งค่าสามารถระบุให้ผู้ใช้ทราบว่ามีการสนับสนุนอยู่ เช่น แท็บ "เกมคอนโทรลเลอร์" ในแผงการตั้งค่าของเกมจะระบุว่ารองรับคอนโทรลเลอร์
• ข้อความตามบริบท เช่น หากตรวจพบแป้นพิมพ์จริงและพบว่าผู้ใช้คลิกการดำเนินการโดยใช้เมาส์หรือหน้าจอสัมผัส คุณอาจต้องการแสดงคำแนะนำที่เป็นประโยชน์ซึ่งแนะนำแป้นพิมพ์ลัด
• รายการแป้นพิมพ์ลัด เมื่อตรวจพบแป้นพิมพ์จริง การระบุวิธีแสดงรายการแป้นพิมพ์ลัดที่มีใน UI จะมีวัตถุประสงค์ 2 อย่าง ได้แก่ การโฆษณาว่ามีแป้นพิมพ์ที่รองรับ และการให้วิธีง่ายๆ แก่ผู้ใช้ในการดูและจดจำแป้นพิมพ์ลัดที่รองรับ

การติดป้ายกำกับ/เลย์เอาต์ของ UI สำหรับรูปแบบอินพุต

ในอุดมคติแล้ว อินเทอร์เฟซภาพไม่ควรต้องเปลี่ยนแปลงมากนักหากใช้อุปกรณ์ป้อนข้อมูลอื่น และอินพุตที่เป็นไปได้ทั้งหมดควร "ใช้งานได้" อย่างไรก็ตาม มีข้อยกเว้นที่สำคัญ โดย 2 ข้อที่สำคัญที่สุดคือ UI เฉพาะการสัมผัสและข้อความที่ปรากฏบนหน้าจอ

UI สำหรับการสัมผัสโดยเฉพาะ

ทุกครั้งที่แอปมีองค์ประกอบ UI ที่เฉพาะเจาะจงสำหรับการแตะ เช่น จอยสติ๊กบนหน้าจอในเกม คุณควรพิจารณาว่าประสบการณ์ของผู้ใช้จะเป็นอย่างไรเมื่อไม่ได้ใช้การแตะ ในเกมมือถือบางเกม ส่วนสำคัญของหน้าจอจะใช้สำหรับตัวควบคุมที่จำเป็นสำหรับการเล่นแบบสัมผัส แต่ไม่จำเป็นหากผู้ใช้ใช้เกมแพดหรือคีย์บอร์ดในการเล่น แอปหรือเกมควรมีตรรกะในการตรวจหาว่ามีการใช้วิธีการป้อนข้อมูลใดอยู่ และปรับ UI ตามนั้น ดูตัวอย่างวิธีดำเนินการได้ที่ส่วนการติดตั้งใช้งานด้านล่าง

ข้อความแจ้งบนหน้าจอ

แอปของคุณอาจแสดงข้อความแจ้งที่เป็นประโยชน์บนหน้าจอต่อผู้ใช้ โปรดระมัดระวังว่าการตั้งค่าเหล่านี้ไม่ได้ขึ้นอยู่กับอุปกรณ์อินพุต เช่น

• ปัดไปที่…
• แตะที่ใดก็ได้เพื่อปิด
• บีบเพื่อซูม
• กด "X" เพื่อ…
• กดค้างเพื่อเปิดใช้งาน

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

ข้อควรพิจารณาเกี่ยวกับหลายภาษา

หากแอปของคุณรองรับหลายภาษา คุณจะต้องพิจารณาโครงสร้างสตริง ตัวอย่างเช่น หากคุณรองรับโหมดการป้อนข้อมูล 3 โหมดและ 5 ภาษา นั่นหมายความว่าข้อความ UI ทุกข้อความอาจมี 15 เวอร์ชันที่แตกต่างกัน ซึ่งจะเพิ่มปริมาณงานที่ต้องทำเพื่อเพิ่มฟีเจอร์ใหม่ๆ และเพิ่มโอกาสที่จะเกิดข้อผิดพลาดในการสะกดคำ

วิธีหนึ่งคือการพิจารณาการดำเนินการในอินเทอร์เฟซเป็นชุดสตริงที่แยกต่างหาก เช่น หากคุณกำหนดการดำเนินการ "ปิด" เป็นตัวแปรสตริงของตัวเองที่มีตัวแปรเฉพาะอินพุต เช่น "แตะที่ใดก็ได้เพื่อปิด" "กด "Esc" เพื่อปิด" "คลิกที่ใดก็ได้เพื่อปิด" "กดปุ่มใดก็ได้เพื่อปิด" ข้อความ UI ทั้งหมดที่ต้องบอกผู้ใช้ถึงวิธีปิดบางอย่างจะใช้ตัวแปรสตริง "ปิด" เดียวนี้ได้ เมื่อวิธีป้อนข้อมูลเปลี่ยนแปลง ให้เปลี่ยนค่าของตัวแปรนี้

การป้อนข้อมูลด้วยแป้นพิมพ์เสมือน / IME

โปรดทราบว่าหากผู้ใช้ใช้แอปโดยไม่มีแป้นพิมพ์จริง การป้อนข้อความจะเกิดขึ้นผ่านแป้นพิมพ์บนหน้าจอ โปรดทดสอบว่าองค์ประกอบ UI ที่จำเป็นไม่ถูกบดบังเมื่อแป้นพิมพ์บนหน้าจอปรากฏขึ้น ดูข้อมูลเพิ่มเติมได้ที่เอกสารประกอบเกี่ยวกับระดับการมองเห็น IME ของ Android

การใช้งาน

ในกรณีส่วนใหญ่ แอปหรือเกมควรตอบสนองต่ออินพุตที่ถูกต้องทั้งหมดอย่างถูกต้อง ไม่ว่าจะมีอะไรแสดงบนหน้าจอ หากผู้ใช้ใช้หน้าจอสัมผัสเป็นเวลา 10 นาที แต่จากนั้นเปลี่ยนไปใช้แป้นพิมพ์อย่างกะทันหัน อินพุตแป้นพิมพ์ควรใช้งานได้ ไม่ว่าจะมีข้อความหรือตัวควบคุมบนหน้าจอหรือไม่ก็ตาม กล่าวคือ ฟังก์ชันการทำงานควรมีความสำคัญมากกว่าภาพ/ข้อความ ซึ่งจะช่วยรับประกันว่าแอป/เกมจะใช้งานได้แม้ว่าตรรกะการตรวจหาอินพุตจะมีข้อผิดพลาดหรือเกิดสถานการณ์ที่ไม่คาดคิดขึ้น

ขั้นตอนถัดไปคือการแสดง UI ที่ถูกต้องสำหรับวิธีการป้อนข้อมูลที่ใช้อยู่ในปัจจุบัน คุณตรวจจับการละเมิดนี้ได้อย่างไร จะเกิดอะไรขึ้นหากผู้ใช้สลับไปมาระหว่างวิธีการป้อนข้อมูลต่างๆ ขณะใช้แอปของคุณ จะเกิดอะไรขึ้นหากผู้ใช้ใช้วิธีการหลายอย่างพร้อมกัน

เครื่องสถานะที่มีลำดับความสำคัญตามเหตุการณ์ที่ได้รับ

วิธีหนึ่งคือการติดตาม "สถานะอินพุตที่ใช้งานอยู่" ปัจจุบัน ซึ่งแสดงข้อความแจ้งอินพุตที่แสดงบนหน้าจอต่อผู้ใช้ในขณะนี้ โดยการติดตามเหตุการณ์อินพุตจริงที่แอปได้รับ และเปลี่ยนสถานะโดยใช้ตรรกะที่มีลำดับความสำคัญ

ให้ความสำคัญ

เหตุใดจึงต้องจัดลำดับความสำคัญของสถานะอินพุต ผู้ใช้โต้ตอบกับอุปกรณ์ในหลากหลายวิธี และแอปของคุณควรรองรับตัวเลือกของผู้ใช้ เช่น หากผู้ใช้เลือกใช้หน้าจอสัมผัสและเมาส์บลูทูธพร้อมกัน ระบบควรจะรองรับการใช้งานดังกล่าว แต่คุณควรแสดงข้อความแจ้งและตัวควบคุมอินพุตบนหน้าจอใด เมาส์หรือการสัมผัส

การกำหนดชุดพรอมต์แต่ละชุดเป็น "สถานะอินพุต" แล้วจัดลำดับความสำคัญจะช่วยให้ตัดสินใจได้อย่างสอดคล้องกัน

เหตุการณ์อินพุตที่ได้รับจะเป็นตัวกำหนดสถานะ

เหตุใดจึงต้องดำเนินการกับเหตุการณ์อินพุตที่ได้รับเท่านั้น คุณอาจคิดว่าสามารถติดตามการเชื่อมต่อบลูทูธเพื่อระบุว่ามีการเชื่อมต่อคอนโทรลเลอร์บลูทูธหรือไม่ หรือตรวจสอบการเชื่อมต่อ USB สำหรับอุปกรณ์ USB เราไม่แนะนำให้ใช้วิธีนี้ด้วยเหตุผลหลัก 2 ประการ

ก่อนอื่น ข้อมูลที่คุณคาดเดาเกี่ยวกับอุปกรณ์ที่เชื่อมต่อโดยอิงตามตัวแปร API นั้นไม่สอดคล้องกัน และจำนวนอุปกรณ์บลูทูธ/ฮาร์ดแวร์/สไตลัสก็เพิ่มขึ้นเรื่อยๆ

เหตุผลที่สองที่ควรใช้เหตุการณ์ที่ได้รับแทนสถานะการเชื่อมต่อคือผู้ใช้อาจเชื่อมต่อเมาส์ ตัวควบคุมบลูทูธ ตัวควบคุม MIDI ฯลฯ แต่ไม่ได้ใช้เพื่อโต้ตอบกับแอปหรือเกมของคุณ

การตอบสนองต่อเหตุการณ์อินพุตที่แอปได้รับอย่างต่อเนื่องจะช่วยให้คุณตอบสนองต่อการกระทำจริงของผู้ใช้ได้แบบเรียลไทม์ และไม่ต้องพยายามคาดเดาความตั้งใจของผู้ใช้ด้วยข้อมูลที่ไม่สมบูรณ์

ตัวอย่าง: เกมที่รองรับการสัมผัส แป้นพิมพ์/เมาส์ และคอนโทรลเลอร์

สมมติว่าคุณพัฒนาเกมแข่งรถสำหรับโทรศัพท์มือถือแบบสัมผัส ผู้เล่นสามารถเร่งความเร็ว ลดความเร็ว เลี้ยวขวา เลี้ยวซ้าย หรือใช้น้ำยาไนโตรเพื่อเพิ่มความเร็ว

อินเทอร์เฟซหน้าจอสัมผัสปัจจุบันประกอบด้วยจอยสติ๊กบนหน้าจอที่ด้านซ้ายล่างของหน้าจอสำหรับการควบคุมความเร็วและทิศทาง และปุ่มที่ด้านขวาล่างสำหรับไนโตร ผู้ใช้สามารถเก็บถังไนโตรในสนามแข่ง และเมื่อแถบไนโตรที่ด้านล่างของหน้าจอเต็มแล้ว ข้อความ "กดเพื่อใช้ไนโตร!" จะปรากฏเหนือปุ่ม หากเป็นเกมแรกของผู้ใช้หรือไม่มีการป้อนข้อมูลเป็นระยะเวลาหนึ่ง ข้อความ "บทแนะนำ" จะปรากฏเหนือจอยสติ๊กเพื่อแสดงวิธีทำให้รถเคลื่อนที่

คุณต้องการเพิ่มการรองรับแป้นพิมพ์และตัวควบคุมเกมบลูทูธ คุณจะเริ่มต้นจากตรงไหน

สถานะอินพุต

เริ่มต้นด้วยการระบุสถานะอินพุตทั้งหมดที่เกมอาจทำงานอยู่ แล้วแสดงรายการพารามิเตอร์ทั้งหมดที่คุณต้องการเปลี่ยนแปลงในแต่ละสถานะ

                                                                                                                                                                        

	แตะ	แป้นพิมพ์/เมาส์	อุปกรณ์ควบคุมเกม
รีแอ็กต่อ	อินพุตทั้งหมด	อินพุตทั้งหมด	อินพุตทั้งหมด
การควบคุมบนหน้าจอ	- จอยสติ๊กบนหน้าจอ - ปุ่ม Nitro	- ไม่มีจอยสติ๊ก - ไม่มีปุ่มไนโตร	- ไม่มีจอยสติ๊ก - ไม่มีปุ่มไนโตร
Text	แตะเพื่อดู Nitro	กด "N" เพื่อรับ Nitro!	กด "A" เพื่อรับ Nitro!
บทแนะนำ	รูปภาพจอยสติ๊กสำหรับความเร็ว/ทิศทาง	รูปภาพปุ่มลูกศรและปุ่ม WASD สำหรับความเร็ว/ทิศทาง	รูปภาพของเกมแพดสำหรับความเร็ว/ทิศทาง

ติดตามสถานะ "อินพุตที่ใช้งานอยู่" แล้วอัปเดต UI ตามต้องการโดยอิงตามสถานะดังกล่าว

หมายเหตุ: โปรดทราบว่าเกม/แอปควรตอบสนองต่อวิธีการป้อนข้อมูลทั้งหมด ไม่ว่าจะมีสถานะใดก็ตาม เช่น หากผู้ใช้ขับรถด้วยหน้าจอสัมผัส แต่กด N บนแป้นพิมพ์ ระบบควรทริกเกอร์การทำงานของไนโตร

การเปลี่ยนแปลงสถานะที่จัดลำดับความสำคัญ

ผู้ใช้บางรายอาจใช้หน้าจอสัมผัสและแป้นพิมพ์พร้อมกัน ผู้ใช้อาจเริ่มเล่นเกม/ใช้แอปของคุณบนโซฟาในโหมดแท็บเล็ต แล้วเปลี่ยนไปใช้แป้นพิมพ์บนโต๊ะ ส่วนบางคนอาจเชื่อมต่อหรือยกเลิกการเชื่อมต่อเกมคอนโทรลเลอร์กลางเกม

คุณไม่ควรมีองค์ประกอบ UI ที่ไม่ถูกต้อง เช่น บอกให้ผู้ใช้กดปุ่ม n เมื่อใช้หน้าจอสัมผัส ในขณะเดียวกัน ในกรณีที่ผู้ใช้ใช้อุปกรณ์อินพุตหลายเครื่องพร้อมกัน เช่น หน้าจอสัมผัสและแป้นพิมพ์ คุณไม่ต้องการให้ UI สลับไปมาระหว่าง 2 สถานะนี้อย่างต่อเนื่อง

วิธีหนึ่งในการจัดการปัญหานี้คือการกำหนดลำดับความสำคัญของประเภทอินพุต และสร้างการหน่วงเวลาระหว่างการเปลี่ยนแปลงสถานะ สำหรับเกมรถยนต์ด้านบน คุณควรตรวจสอบว่าจอยสติ๊กบนหน้าจอจะมองเห็นได้ทุกครั้งที่ได้รับเหตุการณ์การแตะหน้าจอ ไม่เช่นนั้นผู้ใช้อาจคิดว่าเกมใช้ไม่ได้ ซึ่งจะทำให้หน้าจอสัมผัสเป็นอุปกรณ์ที่มีลำดับความสำคัญสูงสุด

หากได้รับเหตุการณ์จากแป้นพิมพ์และหน้าจอสัมผัสพร้อมกัน เกมควรอยู่ในโหมดหน้าจอสัมผัส แต่จะยังคงตอบสนองต่ออินพุตจากแป้นพิมพ์ หากไม่ได้รับการป้อนข้อมูลด้วยหน้าจอสัมผัสหลังจากผ่านไป 5 วินาทีและยังคงได้รับเหตุการณ์ของแป้นพิมพ์อยู่ บางทีการควบคุมบนหน้าจออาจจางลงและเกมจะเปลี่ยนไปใช้สถานะแป้นพิมพ์

อินพุตจากเกมคอนโทรลเลอร์จะมีรูปแบบคล้ายกัน โดยสถานะ UI ของคอนโทรลเลอร์จะมีลำดับความสำคัญต่ำกว่าแป้นพิมพ์/เมาส์และระบบสัมผัส และจะปรากฏเฉพาะในกรณีที่ได้รับอินพุตจากเกมคอนโทรลเลอร์เท่านั้น ไม่ใช่รูปแบบอินพุตอื่นๆ เกมจะตอบสนองต่ออินพุตของคอนโทรลเลอร์เสมอ

ด้านล่างนี้คือแผนภาพสถานะและตารางการเปลี่ยนสถานะสำหรับตัวอย่าง ปรับไอเดียให้เข้ากับแอปหรือเกม

                                                                                                                                        

	#1 หน้าจอสัมผัส	#2 แป้นพิมพ์	#3 จอยเกม
ย้ายไปที่ #1	ไม่มี	- ได้รับการป้อนข้อมูลด้วยการสัมผัส - เปลี่ยนไปที่สถานะการป้อนข้อมูลด้วยการสัมผัสทันที	- ได้รับการป้อนข้อมูลด้วยการสัมผัส - เปลี่ยนไปที่สถานะการป้อนข้อมูลด้วยการสัมผัสทันที
ย้ายไปที่ #2	- ไม่มีการแตะเป็นเวลา 5 วินาที - ได้รับข้อมูลจากแป้นพิมพ์ - เปลี่ยนไปใช้สถานะการป้อนข้อมูลจากแป้นพิมพ์	ไม่มี	- ได้รับการป้อนข้อมูลด้วยแป้นพิมพ์ (ย้ายไปที่สถานะการป้อนข้อมูลด้วยแป้นพิมพ์ทันที)
ย้ายไปที่ #3	- ไม่มีการแตะเป็นเวลา 5 วินาที - ไม่มีการใช้แป้นพิมพ์เป็นเวลา 5 วินาที - ได้รับอินพุตจากเกมแพด - เปลี่ยนไปใช้สถานะอินพุตจากเกมแพด	- ไม่มีการป้อนข้อมูลจากแป้นพิมพ์เป็นเวลา 5 วินาที - ได้รับการป้อนข้อมูลจากเกมแพด - เปลี่ยนไปใช้สถานะการป้อนข้อมูลจากเกมแพด	ไม่มี

หมายเหตุ: สังเกตว่าการจัดลำดับความสำคัญช่วยให้เห็นชัดเจนว่าควรใช้การป้อนข้อมูลประเภทใดเป็นหลัก สถานะอินพุตจะเลื่อนขึ้นตามลำดับความสำคัญทันที

3. จอยเกม -> 2 แป้นพิมพ์ -> 1. แตะ

ทันทีที่มีการใช้อุปกรณ์ที่มีลำดับความสำคัญสูงกว่า แต่จะค่อยๆ "ลด" ลำดับความสำคัญลงหลังจากผ่านระยะเวลาหน่วงและต่อเมื่อมีการใช้อุปกรณ์ที่มีลำดับความสำคัญต่ำกว่าอยู่

เหตุการณ์การป้อนข้อมูล

ต่อไปนี้คือตัวอย่างโค้ดเกี่ยวกับวิธีตรวจหาเหตุการณ์อินพุตจากอุปกรณ์อินพุตประเภทต่างๆ โดยใช้ Android API มาตรฐาน ใช้เหตุการณ์เหล่านี้เพื่อขับเคลื่อนเครื่องสถานะของคุณ เช่น ด้านบน คุณควรปรับแนวคิดทั่วไปให้เข้ากับประเภทเหตุการณ์อินพุตที่คาดไว้ รวมถึงแอปหรือเกม

ปุ่มแป้นพิมพ์และปุ่มควบคุม

// Drive the state machine based on the received input type
// onKeyDown drives the state machine, but does not trigger game actions
// Both keyboard and game controller events come through as key events
override fun onKeyDown(keyCode: Int, event: KeyEvent?): Boolean {
    if (event != null) {
        // Check input source
        val outputMessage = when (event.source) {
            SOURCE_KEYBOARD -> {
                MyStateMachine.KeyboardEventReceived()
                "Keyboard event"
            }
            SOURCE_GAMEPAD -> {
                MyStateMachine.ControllerEventReceived()
                "Game controller event"
            }
            else -> "Other key event: ${event.source}"
        }
        // Do something based on source type
        findViewById(R.id.text_message).text = outputMessage
    }
    // Pass event up to system
    return super.onKeyDown(keyCode, event)
}

// Trigger game events based on key release
// Both keyboard and game controller events come through as key events
override fun onKeyUp(keyCode: Int, event: KeyEvent?): Boolean {
   when(keyCode) {
       KeyEvent.KEYCODE_N -> {
           MyStateMachine.keyboardEventReceived()
           engageNitro()
           return true // event handled here, return true
       }
   }
   // If event not handled, pass up to system
   return super.onKeyUp(keyCode, event)
}

หมายเหตุ: สำหรับ KeyEvents คุณสามารถเลือกใช้ onKeyDown() หรือ onKeyUp() ในที่นี้ onKeyDown() ใช้สำหรับการควบคุมเครื่องสถานะ ส่วน onKeyUp() ใช้สำหรับการทริกเกอร์เหตุการณ์ในเกม

หากผู้ใช้กดปุ่มค้างไว้ onKeyUp() จะทริกเกอร์เพียงครั้งเดียวต่อการกดแป้น ในขณะที่ onKeyDown() จะเรียกใช้หลายครั้ง หากต้องการตอบสนองต่อการกดลง คุณควรจัดการเหตุการณ์ในเกมใน onKeyDown() และใช้ตรรกะเพื่อจัดการกับเหตุการณ์ที่เกิดซ้ำ ดูข้อมูลเพิ่มเติมได้ในเอกสารประกอบการจัดการการดำเนินการของแป้นพิมพ์

การสัมผัสและสไตลัส

// Touch and stylus events come through as touch events
override fun onTouchEvent(event: MotionEvent?): Boolean {
   if (event != null) {
       // Get tool type
       val pointerIndex = event.action and ACTION_POINTER_INDEX_MASK shr ACTION_POINTER_INDEX_SHIFT
       val toolType = event.getToolType(pointerIndex)

       // Check tool type
       val outputMessage = when (toolType) {
           TOOL_TYPE_FINGER -> {
               MyStateMachine.TouchEventReceived()
               "Touch event"
           }
           TOOL_TYPE_STYLUS -> {
                MyStateMachine.StylusEventReceived()
               "Stylus event"
           }
           else -> "Other touch event: ${toolType}"
       }

       // Do something based on tool type, return true if event handled
       findViewById(R.id.text_message).text = outputMessage
   }
   // If event not handled, pass up to system
   return super.onGenericMotionEvent(event)
}

เมาส์และจอยสติ๊ก

// Mouse and joystick events come through as generic events
override fun onGenericMotionEvent(event: MotionEvent?): Boolean {
   if (event != null) {
       // Check input source
       val outputMessage = when (event.source) {
           SOURCE_JOYSTICK -> {
                MyStateMachine.ControllerEventReceived()
               "Controller event"
           }
           SOURCE_MOUSE -> {
                MyStateMachine.MouseEventReceived()
               "Mouse event"
           }
           else -> "Other generic event: ${event.source}"
       }
       // Do something based on source type, return true if event handled
       findViewById(R.id.text_message).text = outputMessage
   }
   // If event not handled, pass up to system
   return super.onGenericMotionEvent(event)
}