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 تأثیر می‌گذارد. سه استراتژی وجود دارد: اعتبارسنجی پس از هر کاراکتر (instant)، پس از از دست دادن فوکوس (onFocusLost) و هنگام ارسال فرم (onSubmit). هر استراتژی برای سناریوهای مختلف مناسب است. اعتبارسنجی لحظه‌ای برای فیلدهای با محدودیت‌های سخت خوب است — شماره تلفن، کد PIN. OnFocusLost — برای ایمیل و نام. OnSubmit — برای فیلدهای الزامی.

بر اساس Material Design Guidelines، توصیه می‌شود استراتژی‌ها را ترکیب کنید: فیلد باید در هنگام از دست دادن فوکوس و همچنین هنگام ارسال فرم بررسی شود. اعتبارسنجی لحظه‌ای زمانی مناسب است که محدودیت واضح باشد — مثلاً حداکثر طول فیلد. اگر برای ایمیل پس از هر کاراکتر خطا نشان داده شود، کاربر قبل از اتمام ورود پیام را خواهد دید. این آزاردهنده است و نرخ تبدیل را کاهش می‌دهد.

قاعده اولین خطا: هنگام ارسال فرم، خطا را فقط برای اولین فیلد نامعتبر نشان دهید. کاربر را با لیست 10 خطا بمباران نکنید. پس از رفع اولین خطا، می‌توان خطای بعدی را نشان داد. این راهنمایی گام به گام بار شناختی را کاهش می‌دهد و به کاربر کمک می‌کند فرم را سریع‌تر پر کند.

ابزارها و کتابخانه‌های اعتبارسنجی

Android SDK ابزارهای پایه برای Validate ارائه می‌دهد: Patterns برای ایمیل و تلفن، TextUtils برای بررسی خالی بودن، عبارات منظم برای الگوهای دلخواه. برای پروژه‌های با 1-3 فیلد این کافی است. با این حال در فرم‌های با 10+ فیلد، اعتبارسنجی دستی به سختی قابل نگهداری می‌شود — هر فیلد جدید نیاز به تابع جداگانه و به‌روزرسانی منطق ارسال دارد.

کتابخانه‌های محبوب اعتبارسنجی: Android Saripaar (حاشیه‌نویسی‌های @Email، @NotEmpty، @Password)، Commons Validator از Apache (بررسی ایمیل، URL، شماره کارت اعتباری)، RxBinding + RxJava برای اعتبارسنجی واکنشی. Saripaar اجازه می‌دهد حاشیه‌نویسی‌ها مستقیماً روی فیلدهای ورودی قرار داده شوند و اعتبارسنجی با یک خط فراخوانی شود: validator.validate(). کتابخانه به طور خودکار خطاها را از طریق setError نشان می‌دهد.

Google استفاده از Material Design Components با TextInputLayout را توصیه می‌کند. اعتبارسنجی داخلی از طریق setError، setHelperText و setCounterEnabled سناریوهای پایه را بدون کتابخانه‌های خارجی پوشش می‌دهد. برای پروژه‌های پیچیده (فین‌تک، پزشکی) بهتر است از ترکیبی استفاده شود: Material Components + اعتبارسنجی سفارشی با الگوهای لایه دامنه Clean Architecture.

خطاهای رایج در اعتبارسنجی فیلدها

اولین خطا — نشان دادن خطا قبل از شروع ورود. اگر فیلد الزامی است اما کاربر هنوز پر کردن آن را شروع نکرده، «فیلد الزامی است» را نشان ندهید. این احساس کاذب مشکل ایجاد می‌کند. خطا باید فقط پس از تعامل کاربر با فیلد ظاهر شود: شروع به ورود کرد، از فیلد خارج شد، سعی کرد فرم را ارسال کند.

دومین خطا — پیام خطای نامفهوم. پیام باید مشخص باشد و نحوه رفع مشکل را راهنمایی کند. «ایمیل نامعتبر» — بد. «ایمیل باید شامل @ و دامنه باشد، مثلاً user@example.com» — خوب. کاربر باید بفهمد دقیقاً چه اشکالی دارد و چگونه آن را بدون مراجعه به مستندات رفع کند.

سومین خطا — مسدود کردن ارسال بدون توضیح. اگر دکمه ارسال به دلیل خطاهای اعتبارسنجی غیرفعال است، کاربر باید ببیند کدام فیلدها نامعتبر هستند. دکمه خاکستری بدون پیام، بن‌بست برای کاربر است. همیشه فیلدهای دارای خطا را برجسته کنید و متن خطا را در کنار هر فیلد نامعتبر نشان دهید.