Validate: คืออะไร การตรวจสอบฟิลด์นำเข้าและการนำไปใช้ใน Android

การตรวจสอบฟิลด์ใน Android คืออะไร

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

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

ตาม การวิจัย UX ผู้ใช้คาดหวังให้เห็นข้อผิดพลาดการตรวจสอบภายใน 1-2 วินาทีหลังจากป้อนข้อมูลเสร็จ ความล่าช้ามากกว่า 3 วินาทีจะถูกมองว่าเป็นปัญหาแอปพลิเคชัน นี่คือสาเหตุที่การตรวจสอบแบบเรียลไทม์ผ่าน TextWatcher ดีกว่าการตรวจสอบเฉพาะเมื่อกดปุ่มส่ง

วิธีการหลักในการตรวจสอบฟิลด์

มีสามแนวทางหลักสำหรับ การตรวจสอบฟิลด์ ใน Android วิธีแรกคือการตรวจสอบด้วยตนเองผ่านตัวดำเนินการเงื่อนไข (if, when) นักพัฒนาจะเขียนฟังก์ชันที่รับสตริงและส่งคืน Boolean หรือข้อความแสดงข้อผิดพลาด วิธีนี้ให้การควบคุมตรรกะอย่างสมบูรณ์ แต่ต้องเขียนโค้ดสำหรับแต่ละฟิลด์และแต่ละเงื่อนไข

วิธีที่สองคือ การใช้คลาสในตัวของ Android ตัวอย่างเช่น Patterns.EMAIL_ADDRESS.matcher(email).matches() ตรวจสอบอีเมลตามรูปแบบมาตรฐาน Patterns.PHONE.matcher(phone).matches() ตรวจสอบหมายเลขโทรศัพท์ TextUtils.isEmpty() ตรวจสอบค่าว่าง วิธีการเหล่านี้ครอบคลุมสถานการณ์พื้นฐานโดยไม่ต้องเพิ่มการพึ่งพาภายนอก

วิธีที่สามคือ ไลบรารีการตรวจสอบ ไลบรารีเช่น InputValidator, AndroidValidator หรือ Commons Validator มีคำอธิบายประกอบและลูกโซ่การตรวจสอบพร้อมใช้ นักพัฒนาอธิบายกฎในเชิงประกาศ: @Email, @NotEmpty, @MinLength(6) ไลบรารีจะดำเนินการตรวจสอบเองและส่งคืนรายการข้อผิดพลาด วิธีนี้ช่วยเร่งการพัฒนาแต่เพิ่มการพึ่งพา

การตรวจสอบอีเมล โทรศัพท์ และรหัสผ่าน

สำหรับ อีเมล การตรวจสอบมาตรฐานรวมถึงการตรวจสอบสัญลักษณ์ @ ส่วนโดเมน และการไม่มีช่องว่างและอักขระซีริลลิก Android มี Patterns.EMAIL_ADDRESS ซึ่งครอบคลุมที่อยู่อีเมลที่ถูกต้องส่วนใหญ่ อย่างไรก็ตาม หากต้องการการตรวจสอบเฉพาะ (เช่น เฉพาะโดเมนของบริษัท) ต้องเขียนนิพจน์ทั่วไปแบบกำหนดเอง อีเมลจะถูกตรวจสอบหลังจากป้อนข้อมูลเสร็จ ไม่ใช่หลังจากแต่ละอักขระ

หมายเลขโทรศัพท์ ถูกตรวจสอบตามหน้ากากประเทศหรือภูมิภาค สำหรับหมายเลขระหว่างประเทศจะใช้รูปแบบ E.164: +รหัสประเทศ รหัสผู้ให้บริการ หมายเลข ไลบรารี libphonenumber ของ Google เป็นมาตรฐานอุตสาหกรรมสำหรับการตรวจสอบโทรศัพท์ ไลบรารีจะระบุประเทศตามรหัส ตรวจสอบความยาวและรูปแบบหมายเลข ใน Android สามารถใช้ PhoneNumberUtils.isGlobalPhoneNumber สำหรับการตรวจสอบพื้นฐาน

รหัสผ่าน มีเกณฑ์ความซับซ้อนหลายประการ: ความยาวขั้นต่ำ การมีตัวพิมพ์ใหญ่และตัวพิมพ์เล็ก ตัวเลข อักขระพิเศษ Android ไม่มีคลาสในตัวสำหรับการตรวจสอบรหัสผ่าน — แต่ละโปรเจกต์กำหนดข้อกำหนดของตัวเอง โดยทั่วไปรหัสผ่านจะถูกตรวจสอบผ่านนิพจน์ทั่วไปหรือชุดเงื่อนไข สิ่งสำคัญคือไม่เปิดเผยข้อกำหนดที่แน่นอนในข้อความแสดงข้อผิดพลาด: “รหัสผ่านง่ายเกินไป” ดีกว่า “ต้องมีตัวพิมพ์ใหญ่และตัวเลข”

data class ValidationResult(
    val isValid: Boolean,
    val errorMessage: String? = null
)

fun validatePassword(password: String): ValidationResult {
    if (password.length < 6)
        return ValidationResult(false, "Minimum 6 characters")
    if (!password.any { it.isUpperCase() })
        return ValidationResult(false, "Uppercase letter required")
    return ValidationResult(true)
}

ในตัวอย่าง validatePassword ส่งคืน ValidationResult พร้อมฟิลด์ isValid และข้อความแสดงข้อผิดพลาดที่ไม่บังคับ วิธีนี้สะดวกสำหรับการประกอบ: การตรวจสอบหลายครั้งจะดำเนินการตามลำดับและส่งคืนข้อผิดพลาดแรกที่พบ การตรวจสอบอีเมลและโทรศัพท์เป็นไปตามหลักการเดียวกัน — แต่ละรายการส่งคืนผลลัพธ์พร้อมข้อความหรือความสำเร็จ

ควรตรวจสอบเมื่อใด

ช่วงเวลาการตรวจสอบ ส่งผลกระทบอย่างมากต่อ UX มีสามกลยุทธ์: การตรวจสอบหลังจากแต่ละอักขระ (ทันที) หลังจากสูญเสียโฟกัส (onFocusLost) และเมื่อส่งแบบฟอร์ม (onSubmit) แต่ละกลยุทธ์เหมาะสมกับสถานการณ์ที่แตกต่างกัน การตรวจสอบทันทีเหมาะสำหรับฟิลด์ที่มีข้อจำกัดเข้มงวด — หมายเลขโทรศัพท์ รหัส PIN OnFocusLost เหมาะสำหรับอีเมลและชื่อ OnSubmit เหมาะสำหรับฟิลด์ที่ต้องกรอก

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

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

เครื่องมือและไลบรารีสำหรับการตรวจสอบ

Android SDK มีเครื่องมือพื้นฐานสำหรับ Validate: Patterns สำหรับอีเมลและโทรศัพท์ TextUtils สำหรับตรวจสอบค่าว่าง นิพจน์ทั่วไปสำหรับรูปแบบที่กำหนดเอง สำหรับโปรเจกต์ที่มี 1-3 ฟิลด์ ก็เพียงพอแล้ว อย่างไรก็ตาม ในแบบฟอร์มที่มี 10+ ฟิลด์ การตรวจสอบด้วยตนเองจะยากต่อการบำรุงรักษา — ฟิลด์ใหม่แต่ละฟิลด์ต้องมีฟังก์ชันแยกต่างหากและตรรกะการส่งที่อัปเดต

ไลบรารีการตรวจสอบยอดนิยม: Android Saripaar (คำอธิบายประกอบ @Email, @NotEmpty, @Password), Apache Commons Validator (การตรวจสอบอีเมล, URL, หมายเลขบัตรเครดิต), RxBinding + RxJava สำหรับการตรวจสอบเชิงปฏิกิริยา Saripaar อนุญาตให้วางคำอธิบายประกอบบนฟิลด์นำเข้าโดยตรงและเรียกการตรวจสอบด้วยบรรทัดเดียว: validator.validate() ไลบรารีจะแสดงข้อผิดพลาดโดยอัตโนมัติผ่าน setError

Google แนะนำให้ใช้ Material Design Components กับ TextInputLayout การตรวจสอบในตัวผ่าน setError, setHelperText และ setCounterEnabled ครอบคลุมสถานการณ์พื้นฐานโดยไม่ต้องใช้ไลบรารีของบริษัทอื่น สำหรับโปรเจกต์ที่ซับซ้อน (ฟินเทค การดูแลสุขภาพ) ควรใช้การผสมผสาน: Material Components + การตรวจสอบแบบกำหนดเองกับรูปแบบจากเลเยอร์โดเมนของ Clean Architecture

ข้อผิดพลาดทั่วไปในการตรวจสอบฟิลด์

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

ข้อผิดพลาดที่สองคือ ข้อความแสดงข้อผิดพลาดที่ไม่ชัดเจน ข้อความควรเฉพาะเจาะจงและแนะนำวิธีแก้ไขปัญหา “อีเมลไม่ถูกต้อง” แย่ “อีเมลต้องมี @ และโดเมน เช่น user@example.com” ดี ผู้ใช้ควรเข้าใจว่ามีอะไรผิดพลาดและจะแก้ไขอย่างไรโดยไม่ต้องดูเอกสาร

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