Validate: ما هو، التحقق من حقول الإدخال والتطبيق في Android

ما هو التحقق من الحقل في Android؟

التحقق من الحقل هو التحقق من قيمة واحدة أدخلها المستخدم وفقًا للقواعد المحددة. كل حقل له نوع البيانات الخاص به: البريد الإلكتروني، الرقم، الهاتف، كلمة المرور، النص. لكل نوع معاييره الخاصة: التنسيق، الطول، نطاق القيم، الإلزام. يجيب التحقق من الحقل على السؤال: هل الإدخال في هذا الحقل صحيح؟

الفرق بين التحقق من الحقل والتحقق من النموذج هو أن الحقل يتم التحقق منه بشكل مستقل عن الحقول الأخرى. يتم التحقق من البريد الإلكتروني وفقًا لنمط البريد الإلكتروني، والهاتف وفقًا لنمط الهاتف. إذا كان الحقل غير صالح، يرى المستخدم خطأ لهذا الحقل تحديدًا. قد يبقى النموذج غير مرسل حتى لو فشل حقل واحد في التحقق. التحقق من الحقل هو لبنة البناء للتحقق الكامل من النموذج.

وفقًا لأبحاث تجربة المستخدم، يتوقع المستخدمون رؤية خطأ التحقق في موعد لا يتجاوز 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 ورسالة خطأ اختيارية. هذا النهج مناسب للتكوين: يتم إجراء عدة فحوصات بالتسلسل، ويتم إرجاع أول خطأ يتم العثور عليه. يتبع التحقق من البريد الإلكتروني والهاتف نفس المبدأ — كل منهما يُرجع نتيجة مع رسالة أو نجاح.

متى يتم إجراء التحقق؟

توقيت التحقق يؤثر بشكل حاسم على تجربة المستخدم. هناك ثلاث استراتيجيات: التحقق بعد كل حرف (فوري)، بعد فقدان التركيز (onFocusLost)، وعند إرسال النموذج (onSubmit). كل استراتيجية مناسبة لسيناريوهات مختلفة. التحقق الفوري جيد للحقول ذات القيود الصارمة — رقم الهاتف، رمز PIN. OnFocusLost مناسب للبريد الإلكتروني والاسم. OnSubmit مناسب للحقول الإلزامية.

وفقًا لـ Material Design Guidelines، يُوصى بدمج الاستراتيجيات: يجب التحقق من الحقل عند فقدان التركيز وأيضًا عند إرسال النموذج. التحقق الفوري مناسب عندما يكون القيد واضحًا — على سبيل المثال، الحد الأقصى لطول الحقل. إذا تم إظهار خطأ بعد كل حرف للبريد الإلكتروني، سيرى المستخدم رسالة قبل إنهاء الإدخال. هذا مزعج ويقلل من التحويل.

قاعدة الخطأ الأول: عند إرسال نموذج، أظهر خطأ فقط لأول حقل غير صالح. لا تُثقل المستخدم بقائمة من 10 أخطاء. بعد تصحيح الخطأ الأول، يمكن إظهار الخطأ التالي. هذا التوجيه خطوة بخطوة يقلل العبء المعرفي ويساعد المستخدم على ملء النموذج بشكل أسرع.

الأدوات والمكتبات للتحقق

يوفر Android SDK أدوات أساسية للتحقق: 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” هذا جيد. يجب أن يفهم المستخدم ما هو الخطأ بالضبط وكيفية إصلاحه دون الرجوع إلى الوثائق.

الخطأ الثالث هو منع الإرسال بدون شرح. إذا كان زر الإرسال غير نشط بسبب أخطاء التحقق، يجب أن يرى المستخدم الحقول غير الصالحة. الزر الرمادي بدون رسائل هو طريق مسدود للمستخدم. قم دائمًا بتسليط الضوء على الحقول التي بها أخطاء وأظهر نص الخطأ بجانب كل حقل غير صالح.