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 فارمیٹ استعمال کیا جاتا ہے: +ملکی کوڈ، آپریٹر کوڈ، نمبر۔ Google کی libphonenumber لائبریری فون کی توثیق کے لیے صنعتی معیار ہے۔ یہ کوڈ کے ذریعے ملک کا تعین کرتی ہے، نمبر کی لمبائی اور فارمیٹ کی جانچ کرتی ہے۔ 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 ایک isValid فیلڈ اور اختیاری غلطی کے پیغام کے ساتھ ValidationResult لوٹاتا ہے۔ یہ طریقہ ترکیب کے لیے آسان ہے: متعدد جانچیں ترتیب وار کی جاتی ہیں اور پہلی ملنے والی غلطی لوٹائی جاتی ہے۔ ای میل اور فون کی توثیق اسی اصول پر عمل کرتی ہے — ہر ایک پیغام یا کامیابی کے ساتھ نتیجہ لوٹاتا ہے۔

توثیق کب کرنی چاہیے؟

توثیق کا وقت 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 TextInputLayout کے ساتھ Material Design Components استعمال کرنے کی سفارش کرتا ہے۔ setError، setHelperText اور setCounterEnabled کے ذریعے بلٹ ان توثیق تیسرے فریق کی لائبریریوں کے بغیر بنیادی منظرناموں کو کور کرتی ہے۔ پیچیدہ پروجیکٹس (fintech، صحت) کے لیے، مجموعہ استعمال کرنا بہتر ہے: Material Components + Clean Architecture کی ڈومین پرت سے نمونوں کے ساتھ کسٹم توثیق۔

فیلڈ کی توثیق میں عام غلطیاں

پہلی غلطی ان پٹ شروع ہونے سے پہلے غلطی دکھانا ہے۔ اگر فیلڈ لازمی ہے لیکن صارف نے اسے بھرنا شروع نہیں کیا، تو “فیلڈ لازمی ہے” نہ دکھائیں۔ یہ مسئلے کا غلط احساس پیدا کرتا ہے۔ غلطی صرف اس وقت ظاہر ہونی چاہیے جب صارف نے فیلڈ کے ساتھ تعامل کیا ہو: ٹائپ کرنا شروع کیا، فیلڈ چھوڑا، فارم جمع کرانے کی کوشش کی۔

دوسری غلطی غیر واضح غلطی کا پیغام ہے۔ پیغام مخصوص ہونا چاہیے اور مسئلہ حل کرنے کا مشورہ دینا چاہیے۔ “غلط ای میل” برا ہے۔ “ای میل میں @ اور ڈومین ہونا چاہیے، مثلاً user@example.com” اچھا ہے۔ صارف کو سمجھنا چاہیے کہ بالکل کیا غلط ہے اور دستاویزات کا حوالہ دیے بغیر اسے کیسے ٹھیک کرنا ہے۔

تیسری غلطی وضاحت کے بغیر جمع کرانے کو روکنا ہے۔ اگر توثیق کی غلطیوں کی وجہ سے جمع کرانے کا بٹن غیر فعال ہے، تو صارف کو دیکھنا چاہیے کہ کون سے فیلڈز غلط ہیں۔ پیغامات کے بغیر ایک سرمئی بٹن صارف کے لیے ایک مردہ سرا ہے۔ ہمیشہ غلطیوں والے فیلڈز کو نمایاں کریں اور ہر غلط فیلڈ کے ساتھ غلطی کا متن دکھائیں۔