اعتبارسنجی فرم — چیست، اعتبارسنجی فرم و پیادهسازی در اندروید
Form Validation فرآیند بررسی صحت تمام فیلدهای فرم قبل از ارسال دادهها به سرور است. برخلاف اعتبارسنجی یک فیلد مجزا، Form Validation روابط متقابل بین فیلدها را در نظر میگیرد: تأیید رمز عبور، وابستگی یک فیلد به دیگری، الزام شرطی. بر اساس دادههای Google Developers, 2026، Form Validation باید در هنگام ارسال، کل فرم را بررسی کند و خلاصهای از همه خطاها را به کاربر ارائه دهد. اعتبارسنجی صحیح فرم، نرخ تبدیل ثبتنام را ۲۵-۳۵٪ افزایش میدهد و تعداد خطاهای ورودی را کاهش میدهد.
نکات اصلی
- Form Validation — بررسی جامع تمام فیلدها و روابط متقابل آنها قبل از ارسال دادهها.
- اعتبارسنجی فیلد یک فیلد را مستقل بررسی میکند، اما اعتبارسنجی فرم — همه فیلدها را با هم بررسی میکند.
- مدیریت دکمه ارسال — دکمه باید تا زمانی که حداقل یک فیلد نامعتبر است، غیرفعال باشد.
- کتابخانههای اعتبارسنجی مانند Saripaar و RxBinding بررسی فرم با دهها فیلد را سادهتر میکنند.
- اعتبارسنجی هنگام ارسال — مرحله الزامی، حتی اگر فیلدها در زمان واقعی بررسی شوند.
اعتبارسنجی فرم در اندروید چیست؟
Form Validation فرآیندی است که تضمین میکند تمام دادههای وارد شده توسط کاربر در فرم، قبل از ارسال به سرور با الزامات کسبوکار مطابقت دارند. اعتبارسنجی فرم شامل بررسی هر فیلد به صورت جداگانه و همچنین بررسیهای متقابل است: آیا رمز عبور با تأیید مطابقت دارد، آیا حداقل یک چکباکس انتخاب شده، آیا تمام فیلدهای الزامی پر شدهاند، آیا تاریخ صحیح است (مثلاً تاریخ تولد در آینده نباشد).
تفاوت با اعتبارسنجی ساده فیلد این است که Form Validation با فرم به عنوان یک کل واحد عمل میکند. میتواند ارسال را مسدود کند اگر فیلد شرطی پر نشده باشد، یا خلاصه خطاها را در یک پنجره دیالوگ نشان دهد. در فرمهای پیچیده (ثبتنام، ثبت سفارش، پرسشنامه) اعتبارسنجی فرم یک لایه منطق جداگانه است که مستقل از UI آزمایش میشود.
بر اساس تحقیقات UX گروه NN، کاربران ۳ برابر بیشتر فرم را تکمیل میکنند اگر خطاها را بلافاصله پس از ارسال ببینند، نه بعد از هر فیلد به صورت جداگانه. با این حال، بهترین نتیجه ترکیبی را میدهد: اعتبارسنجی آنی فیلدهای ساده (طول، قالب) + بررسی کامل هنگام ارسال برای فیلدهای متقابل و منطق کسبوکار.
تفاوتهای اعتبارسنجی فیلد و اعتبارسنجی فرم
اعتبارسنجی فیلد به این سؤال پاسخ میدهد: آیا ورودی در این فیلد خاص صحیح است؟ ایمیل دارای قالب user@domain.com است، تلفن از اعداد تشکیل شده، رمز عبور بیشتر از ۶ کاراکتر است. اعتبارسنجی فیلد ایزوله است — به فیلدهای دیگر وابسته نیست و میتواند در زمان واقعی انجام شود. نتیجه: خطا برای یک فیلد خاص یا عدم وجود آن.
اعتبارسنجی فرم به این سؤال پاسخ میدهد: آیا میتوان فرم را به طور کامل ارسال کرد؟ نه تنها هر فیلد، بلکه ترکیبات آنها را نیز در نظر میگیرد: رمز عبور و تأیید باید مطابقت داشته باشند، تاریخ شروع نمیتواند دیرتر از تاریخ پایان باشد، مجموع فیلدها باید ۱۰۰٪ باشد. اعتبارسنجی فرم در هنگام ارسال انجام میشود و نتیجه کلی را برمیگرداند: فرم معتبر است یا نه.
از نظر معماری، اعتبارسنجی فیلد در لایه UI (fragment، ViewModel) قرار میگیرد، و اعتبارسنجی فرم در لایه دامنه (use case، interactor). این امکان استفاده مجدد از اعتبارسنجی فرم در کامپوننتهای مختلف UI و آزمایش آن بدون شبیهساز را فراهم میکند. در Clean Architecture، اعتبارسنجی فرم یک قانون کسبوکار است، نه منطق UI.
| معیار | اعتبارسنجی فیلد | اعتبارسنجی فرم |
|---|---|---|
| موضوع بررسی | یک فیلد | تمام فیلدها + روابط متقابل آنها |
| زمان انجام | در زمان واقعی / هنگام از دست دادن فوکوس | هنگام ارسال فرم |
| نتیجه | خطای یک فیلد خاص | وضعیت کلی فرم + لیست خطاها |
| لایه معماری | لایه UI | لایه دامنه |
رویکردهای اعتبارسنجی فرم
دو رویکرد اصلی برای Form Validation وجود دارد. اولی — امری: توسعهدهنده تابعی مینویسد که به ترتیب هر فیلد را بررسی میکند و لیست خطاها را جمعآوری میکند. این رویکرد برای درک ساده است، اما کد با هر فیلد جدید رشد میکند. برای فرمی با ۵ فیلد رویکرد امری هنوز راحت است، برای ۱۵ فیلد — در حال حاضر مشکلساز.
رویکرد دوم — اعلامی: قوانین اعتبارسنجی با حاشیهنویسی یا پیکربندی توصیف میشوند. کتابخانه خودش تمام فیلدها را پیمایش میکند، قوانین را اعمال میکند و نتیجه را برمیگرداند. مثال: حاشیهنویسی @Email روی فیلد emailData، @ConfirmPassword روی فیلد تأیید. رویکرد اعلامی کد اعتبارسنجی را ۳-۵ برابر کوتاهتر و خوانا میکند.
رویکرد سوم — واکنشی با استفاده از RxJava یا Kotlin Flow. هر فیلد به عنوان Observable یا StateFlow نمایش داده میشود. اعتبارسنجی فرم تغییرات همه فیلدها را زیر نظر میگیرد و وضعیت کلی را با هر تغییری دوباره محاسبه میکند. دکمه ارسال زمانی که همه فیلدها معتبر باشند به طور خودکار فعال میشود. این رویکرد نیاز به درک برنامهنویسی واکنشی دارد، اما روانترین UX را ارائه میدهد.
مثال اعتبارسنجی فرم ثبتنام
فرم ثبتنام با سه فیلد را در نظر بگیرید: ایمیل، رمز عبور و تأیید رمز عبور. اعتبارسنجی فرم شامل: بررسی ایمیل از طریق Patterns.EMAIL_ADDRESS، بررسی رمز عبور برای حداقل طول ۸ کاراکتر و وجود عدد، بررسی مطابقت رمز عبور و تأیید. تنها وقتی هر سه بررسی عبور کنند، فرم قابل ارسال است.
kotlin
data class RegistrationForm(
val email: String,
val password: String,
val confirmPassword: String
)
fun validateRegistration(form: RegistrationForm): ValidationResult {
if (!Patterns.EMAIL_ADDRESS.matcher(form.email).matches())
return ValidationResult(false, "Invalid email address")
if (form.password.length < 8)
return ValidationResult(false, "Password too short")
if (form.password != form.confirmPassword)
return ValidationResult(false, "Passwords do not match")
return ValidationResult(true)
}در مثال، validateRegistration data class فرم را میپذیرد و ValidationResult را برمیگرداند. اگر حداقل یک بررسی عبور نکند، false با پیام مربوطه برگردانده میشود. مدیریت دکمه ارسال بر اساس Result ساخته میشود: اگر isValid = true، دکمه فعال است. برای بهروزرسانی وضعیت در زمان واقعی میتوان از LiveData<ValidationResult> استفاده کرد و دکمه را با هر تغییری در هر فیلد بهروز کرد.
رویکرد واکنشی با Kotlin Flow امکان محاسبه خودکار وضعیت فرم را فراهم میکند. هر فیلد به عنوان MutableStateFlow<String> نمایش داده میشود و combine آنها را در یک Flow<ValidationResult> ترکیب میکند. اشتراک در UI دکمه ارسال را بدون فراخوانی دستی اعتبارسنجی بهروز میکند. این الگو توسط Google برای Jetpack Compose و معماری MVVM توصیه میشود.
کتابخانههای اعتبارسنجی فرم
Android Saripaar — محبوبترین کتابخانه اعتبارسنجی برای اندروید. امکان حاشیهنویسی مستقیم فیلدها و Viewها را فراهم میکند: @Email، @NotEmpty، @Password(min = 8, scheme = Password.Scheme.ALPHA_NUMERIC). اعتبارسنجی با یک خط validator.validate() با callback فراخوانی میشود. Saripaar به طور خودکار خطا را از طریق setError روی EditText تنظیم میکند. کتابخانه همچنین از حاشیهنویسیهای سفارشی برای قوانین خاص کسبوکار پشتیبانی میکند.
RxBinding + RxJava — رویکرد واکنشی بدون کتابخانه اعتبارسنجی جداگانه. هر فیلد تغییرات را از طریق RxTextView.textChanges() منتشر میکند. عملگر combineLatest همه فیلدها را ترکیب کرده و وضعیت کلی را محاسبه میکند. مزیت: کنترل کامل بر pipeline اعتبارسنجی، امکان اضافه کردن debounce، throttle، filter. عیب: نیاز به دانش RxJava.
Material Design Components — پشتیبانی داخلی از TextInputLayout و TextInputEditText. کتابخانه اعتبارسنجی را به این صورت فراهم نمیکند، اما UI برای نمایش خطاها میدهد: setError()، setHelperText()، setCounterEnabled(). برای خود اعتبارسنجی همچنان به منطق دستی یا Saripaar نیاز است. Material Components مسئول نمایش هستند، نه بررسی.
اشتباهات رایج در اعتبارسنجی فرم
اولین اشتباه — اعتبارسنجی فقط در سمت کلاینت. Form Validation در سمت کلاینت برای UX طراحی شده است، نه برای امنیت. یک مهاجم میتواند درخواست را مستقیماً به API ارسال کند و از اعتبارسنجی عبور کند. سرور باید همه فیلدها را دوباره بررسی کند. اعتبارسنجی کلاینتی نباید تنها محافظ باشد — این یک لایه اضافی برای راحتی کاربر است، نه برای امنیت دادهها.
دومین اشتباه — مسدود کردن دکمه ارسال بدون پیام. اگر دکمه غیرفعال است، کاربر باید ببیند کدام فیلدها نیاز به اصلاح دارند. دکمه خاکستری بدون توضیح — یکی از رایجترین دلایل نرخ پایین تبدیل فرمها. همیشه خطاهای فیلدها را در کنار آنها نشان دهید، حتی اگر دکمه مسدود شده باشد. کاربر باید بفهمد دقیقاً چه چیذی مانع ارسال میشود.
سومین اشتباه — نادیده گرفتن فیلدهای متقابل. اعتبارسنجی هر فیلد به صورت جداگانه کافی نیست. فیلدها میتوانند به یکدیگر وابسته باشند: رمز عبور و تأیید، تاریخ شروع و تاریخ پایان، کشور و شهر. Form Validation باید این روابط متقابل را بررسی کند. بررسی فقط فیلدهای جداگانه حس کاذب امنیت ایجاد میکند — فرم ممکن است با دادههای ناهماهنگ ارسال شود.
| اشتباه | نتیجه | راهحل |
|---|---|---|
| فقط اعتبارسنجی کلاینتی | آسیبپذیری امنیتی | بررسی اجباری سمت سرور |
| دکمه بدون پیام | نرخ پایین تبدیل فرم | نمایش خطاهای فیلدها |
| عدم بررسی متقابل | دادههای ناهماهنگ | اعتبارسنجی روابط متقابل فیلدها |
| بررسیهای بیش از حد مکرر | آزار کاربر | Debounce و بررسی هنگام از دست دادن فوکوس |
سوالات متداول
Form Validation چه تفاوتی با اعتبارسنجی فیلد دارد؟
اعتبارسنجی فیلد یک مقدار را از نظر قالب یا طول بررسی میکند. Form Validation همه فیلدها را با هم بررسی میکند، از جمله بررسیهای متقابل: مطابقت رمزهای عبور، وابستگی فیلدها به یکدیگر. اعتبارسنجی فیلد در لایه UI، Form Validation در لایه دامنه به عنوان یک قانون کسبوکار انجام میشود.
چگونه دکمه ارسال فرم را مدیریت کنیم؟
از رویکرد واکنشی استفاده کنید: همه فیلدها را در یک Flow یا Observable ترکیب کنید و تغییرات را زیر نظر بگیرید. با هر تغییری در هر فیلد، وضعیت کلی فرم را دوباره محاسبه کنید. اگر وضعیت معتبر است — دکمه فعال است. از Kotlin Flow با combine یا RxJava با combineLatest برای بهروزرسانی خودکار استفاده کنید.
کدام کتابخانه اعتبارسنجی برای اندروید بهتر است؟
Android Saripaar — بهترین انتخاب برای اعتبارسنجی اعلامی با حاشیهنویسی. اگر پروژه از RxJava استفاده میکند — RxBinding رویکرد واکنشی را بدون کتابخانه جداگانه فراهم میکند. برای فرمهای ساده، اعتبارسنجی دستی با Patterns و TextUtils بدون وابستگیهای خارجی کافی است.
آیا اگر اعتبارسنجی کلاینتی وجود دارد، اعتبارسنجی سمت سرور لازم است؟
الزاماً. اعتبارسنجی کلاینتی UX را بهبود میبخشد اما امنیت را تأمین نمیکند. سرور باید همه دادهها را دوباره بررسی کند، زیرا API به طور مستقیم در دسترس است. هرگز برای محافظت در برابر دادههای نادرست یا مخرب تنها به اعتبارسنجی کلاینتی تکیه نکنید.
چگونه فرم را در Jetpack Compose اعتبارسنجی کنیم؟
در Jetpack Compose از Kotlin Flow یا StateFlow برای ذخیره وضعیت هر فیلد استفاده کنید. تابع اعتبارسنجی وضعیت فرم را میپذیرد و ValidationResult را برمیگرداند. دکمه ارسال وضعیت کلی را زیر نظر میگیرد. برای نمایش خطاها از isError در OutlinedTextField یا TextField Compose استفاده کنید.
خلاصه
- Form Validation — بررسی جامع تمام فیلدهای فرم و روابط متقابل آنها قبل از ارسال دادهها.
- اعتبارسنجی فیلد ایزوله است و در UI انجام میشود؛ اعتبارسنجی فرم وابستگیهای متقابل را در نظر میگیرد و به لایه دامنه تعلق دارد.
- دکمه ارسال باید در فرم نامعتبر غیرفعال باشد — با نمایش اجباری خطاهای فیلدها.
- Android Saripaar — کتابخانه اصلی برای اعتبارسنجی اعلامی با حاشیهنویسی.
- RxBinding/Flow — رویکرد واکنشی برای محاسبه خودکار وضعیت فرم با تغییر هر فیلد.
- اعتبارسنجی سمت سرور به عنوان لایه امنیتی الزامی است، اعتبارسنجی کلاینتی فقط برای UX.
- بررسیهای متقابل — عنصر الزامی Form Validation، بدون آنها فرم ممکن است دادههای ناهماهنگ ارسال کند.
ما یک اپلیکیشن موبایل به صورت کلید در دست توسعه خواهیم داد
IT Sectr از سال 2017 برنامههای iOS و Android را برای استارتاپها و کسبوکارها ایجاد میکند. ما به شما مشاوره میدهیم و بهترین راهحل را پیشنهاد خواهیم کرد.
همچنین بخوانید