Validate: nó là gì, xác thực trường nhập liệu và triển khai trong Android

Xác thực trường trong Android là gì?

Xác thực trường là việc kiểm tra một giá trị duy nhất do người dùng nhập theo các quy tắc đã chỉ định. Mỗi trường có kiểu dữ liệu riêng: email, số, điện thoại, mật khẩu, văn bản. Mỗi loại có tiêu chí riêng: định dạng, độ dài, phạm vi giá trị, tính bắt buộc. Xác thực trường trả lời câu hỏi: đầu vào trong trường này có đúng không?

Sự khác biệt giữa xác thực trường và xác thực biểu mẫu là một trường được kiểm tra độc lập với các trường khác. Email được xác thực theo mẫu email, điện thoại theo mẫu điện thoại. Nếu một trường không hợp lệ, người dùng sẽ thấy lỗi cho trường cụ thể đó. Biểu mẫu có thể vẫn chưa được gửi ngay cả khi một trường không vượt qua xác thực. Xác thực trường là khối xây dựng cho xác thực biểu mẫu hoàn chỉnh.

Theo nghiên cứu UX, người dùng mong đợi thấy lỗi xác thực không muộn hơn 1-2 giây sau khi hoàn thành nhập liệu. Sự chậm trễ hơn 3 giây được coi là vấn đề của ứng dụng. Đó là lý do tại sao xác thực thời gian thực qua TextWatcher được ưa chuộng hơn so với chỉ kiểm tra khi nhấn nút gửi.

Các phương pháp xác thực trường chính

Có ba cách tiếp cận chính để xác thực trường trong Android. Cách thứ nhất là kiểm tra thủ công qua các toán tử điều kiện (if, when). Nhà phát triển viết một hàm nhận chuỗi và trả về Boolean hoặc thông báo lỗi. Cách tiếp cận này cho phép kiểm soát hoàn toàn logic nhưng yêu cầu viết mã cho mỗi trường và mỗi điều kiện.

Cách tiếp cận thứ hai là sử dụng các lớp tích hợp của Android. Ví dụ: Patterns.EMAIL_ADDRESS.matcher(email).matches() xác thực email theo mẫu chuẩn. Patterns.PHONE.matcher(phone).matches() xác thực số điện thoại. TextUtils.isEmpty() kiểm tra trống. Các phương pháp này bao gồm các kịch bản cơ bản mà không thêm phụ thuộc bên ngoài.

Cách tiếp cận thứ ba là thư viện xác thực. Các thư viện như InputValidator, AndroidValidator hoặc Commons Validator cung cấp các chú thích sẵn có và chuỗi xác thực. Nhà phát triển mô tả các quy tắc một cách khai báo: @Email, @NotEmpty, @MinLength(6). Thư viện tự thực hiện xác thực và trả về danh sách lỗi. Điều này tăng tốc độ phát triển nhưng thêm một phụ thuộc.

Xác thực email, điện thoại và mật khẩu

Đối với email, xác thực tiêu chuẩn bao gồm kiểm tra sự hiện diện của ký tự @, phần tên miền và không có khoảng trắng và ký tự Cyrillic. Android cung cấp Patterns.EMAIL_ADDRESS, bao phủ hầu hết các địa chỉ email hợp pháp. Tuy nhiên, nếu yêu cầu xác thực cụ thể (ví dụ: chỉ tên miền doanh nghiệp), cần viết biểu thức chính quy tùy chỉnh. Email được xác thực sau khi hoàn thành nhập liệu, không phải sau mỗi ký tự.

Số điện thoại được xác thực theo mặt nạ quốc gia hoặc khu vực. Đối với số quốc tế, định dạng E.164 được sử dụng: +mã quốc gia, mã nhà mạng, số. Thư viện libphonenumber của Google là tiêu chuẩn ngành để xác thực điện thoại. Nó xác định quốc gia theo mã, kiểm tra độ dài và định dạng số. Trong Android, PhoneNumberUtils.isGlobalPhoneNumber có thể được sử dụng để xác thực cơ bản.

Mật khẩu có một số tiêu chí độ phức tạp: độ dài tối thiểu, sự hiện diện của chữ hoa và chữ thường, chữ số, ký tự đặc biệt. Android không có lớp tích hợp để xác thực mật khẩu — mỗi dự án tự xác định yêu cầu riêng. Thông thường, mật khẩu được xác thực qua biểu thức chính quy hoặc một tập hợp điều kiện. Điều quan trọng là không tiết lộ yêu cầu chính xác trong thông báo lỗi: “Mật khẩu quá đơn giản” tốt hơn “Yêu cầu chữ hoa và chữ số”.

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)
}

Trong ví dụ, validatePassword trả về ValidationResult với trường isValid và thông báo lỗi tùy chọn. Cách tiếp cận này thuận tiện cho việc tổng hợp: nhiều kiểm tra được thực hiện tuần tự và lỗi đầu tiên được tìm thấy sẽ được trả về. Xác thực email và điện thoại tuân theo nguyên tắc tương tự — mỗi loại trả về kết quả với thông báo hoặc thành công.

Khi nào nên thực hiện xác thực?

Thời điểm xác thực ảnh hưởng nghiêm trọng đến UX. Có ba chiến lược: xác thực sau mỗi ký tự (tức thì), sau khi mất tiêu điểm (onFocusLost) và khi gửi biểu mẫu (onSubmit). Mỗi chiến lược phù hợp với các kịch bản khác nhau. Xác thực tức thì tốt cho các trường có ràng buộc nghiêm ngặt — số điện thoại, mã PIN. OnFocusLost phù hợp cho email và tên. OnSubmit phù hợp cho các trường bắt buộc.

Theo Material Design Guidelines, nên kết hợp các chiến lược: một trường nên được xác thực khi mất tiêu điểm và cả khi gửi biểu mẫu. Xác thực tức thì phù hợp khi ràng buộc rõ ràng — ví dụ: độ dài tối đa của trường. Nếu hiển thị lỗi sau mỗi ký tự cho email, người dùng sẽ thấy thông báo trước khi hoàn thành nhập liệu. Điều này gây khó chịu và giảm tỷ lệ chuyển đổi.

Quy tắc lỗi đầu tiên: khi gửi biểu mẫu, chỉ hiển thị lỗi cho trường không hợp lệ đầu tiên. Đừng làm người dùng choáng ngợp với danh sách 10 lỗi. Sau khi sửa lỗi đầu tiên, lỗi tiếp theo có thể được hiển thị. Hướng dẫn từng bước này giảm tải nhận thức và giúp người dùng điền biểu mẫu nhanh hơn.

Công cụ và thư viện xác thực

Android SDK cung cấp các công cụ cơ bản cho Validate: Patterns cho email và điện thoại, TextUtils để kiểm tra trống, biểu thức chính quy cho các mẫu tùy ý. Đối với các dự án có 1-3 trường, điều này là đủ. Tuy nhiên, trong các biểu mẫu có 10+ trường, xác thực thủ công trở nên khó bảo trì — mỗi trường mới yêu cầu một hàm riêng và logic gửi được cập nhật.

Thư viện xác thực phổ biến: Android Saripaar (chú thích @Email, @NotEmpty, @Password), Apache Commons Validator (xác thực email, URL, số thẻ tín dụng), RxBinding + RxJava cho xác thực phản ứng. Saripaar cho phép đặt chú thích trực tiếp trên các trường nhập liệu và gọi xác thực bằng một dòng: validator.validate(). Thư viện tự động hiển thị lỗi qua setError.

Google khuyên dùng Material Design Components với TextInputLayout. Xác thực tích hợp qua setError, setHelperText và setCounterEnabled bao gồm các kịch bản cơ bản mà không cần thư viện bên thứ ba. Đối với các dự án phức tạp (fintech, y tế), tốt hơn nên sử dụng kết hợp: Material Components + xác thực tùy chỉnh với các mẫu từ tầng miền của Clean Architecture.

Lỗi thường gặp khi xác thực trường

Lỗi đầu tiên là hiển thị lỗi trước khi bắt đầu nhập liệu. Nếu một trường bắt buộc nhưng người dùng chưa bắt đầu điền, đừng hiển thị “Trường bắt buộc”. Điều này tạo ra cảm giác sai lầm về vấn đề. Lỗi chỉ nên xuất hiện sau khi người dùng đã tương tác với trường: bắt đầu nhập, rời khỏi trường, cố gắng gửi biểu mẫu.

Lỗi thứ hai là thông báo lỗi không rõ ràng. Thông báo phải cụ thể và gợi ý cách khắc phục vấn đề. “Email không hợp lệ” là tệ. “Email phải chứa @ và tên miền, ví dụ user@example.com” là tốt. Người dùng phải hiểu chính xác điều gì sai và cách khắc phục mà không cần tham khảo tài liệu.

Lỗi thứ ba là chặn gửi mà không giải thích. Nếu nút gửi không hoạt động do lỗi xác thực, người dùng phải thấy trường nào không hợp lệ. Một nút màu xám không có thông báo là ngõ cụt cho người dùng. Luôn làm nổi bật các trường có lỗi và hiển thị văn bản lỗi bên cạnh mỗi trường không hợp lệ.