Error State — فیلڈ کی خرابی کیا ہے، خرابیوں کی نمائش اور Android میں نفاذ

Android میں فیلڈ کی خرابی کی حالت کیا ہے؟

Error State ایک ان پٹ فیلڈ کا ایک خاص ڈسپلے موڈ ہے جو اس وقت فعال ہوتا ہے جب داخل کردہ ڈیٹا توثیق میں ناکام ہو جاتا ہے۔ بصری طور پر، Error State میں تین اجزاء شامل ہوتے ہیں: فیلڈ کے بارڈر یا پس منظر کے رنگ میں تبدیلی (عام طور پر سرخ)، فیلڈ کے نیچے خرابی کی وضاحت کرنے والے متن کا ظاہر ہونا، اور اختیاری طور پر ایک آئیکن یا نمایاں کرنا۔ Error State کا مقصد صارف کی توجہ فوری طور پر مسئلہ والے فیلڈ کی طرف مبذول کرانا اور خرابی کو درست کرنے کا مشورہ دینا ہے۔

Android میں، Error State کو Material Design Components سے TextInputLayout کی سطح پر نافذ کیا جاتا ہے۔ TextInputLayout EditText کو لپیٹتا ہے اور اس کی حالتوں کا انتظام کرتا ہے: normal، focused، error، disabled۔ setError(String) طریقہ فیلڈ کو خرابی کی حالت میں بدل دیتا ہے، بارڈر کا رنگ تبدیل کرتا ہے اور پیغام دکھاتا ہے۔ جب متن تبدیل ہوتا ہے یا setError(null) کو کال کیا جاتا ہے، فیلڈ normal پر واپس آ جاتا ہے۔

Material Design Guidelines کے مطابق، Error State نمایاں لیکن غالب نہیں ہونا چاہیے۔ سرخ بارڈر کا رنگ معمول کی حالت سے متضاد ہونا چاہیے لیکن انٹرفیس کو اوورلوڈ نہیں کرنا چاہیے۔ خرابی کے پیغام میں مسئلہ اور اسے حل کرنے کے طریقے کے بارے میں مخصوص معلومات ہونی چاہئیں۔ ایک خرابی کا آئیکن (مثال کے طور پر، فجائیہ نشان کے ساتھ سرخ دائرہ) بصری سگنل کو مضبوط کرتا ہے۔

TextInputLayout میں setError کیسے کام کرتا ہے

setError(CharSequence errorText) طریقہ TextInputLayout کو خرابی کی حالت میں بدل دیتا ہے۔ errorText پیرامیٹر وہ متن ہے جو فیلڈ کے نیچے دکھایا جاتا ہے۔ اگر null پاس کیا جائے تو خرابی صاف ہو جاتی ہے۔ TextInputLayout حرکت پذیری کا انتظام کرتا ہے: خرابی کا متن ہموار ظہور کے ساتھ ظاہر ہوتا ہے، بارڈر سرخ ہو جاتا ہے۔ ایک خرابی کا آئیکن (ڈیفالٹ: دائرے میں فجائیہ نشان) فیلڈ کے آخر میں دکھایا جاتا ہے۔

اہم تفصیلات: خرابی کے پیغام کے لیے جگہ محفوظ کرنے کے لیے setError سے پہلے setErrorEnabled(true) کو کال کیا جانا چاہیے۔ بصورت دیگر، جب خرابی ظاہر ہوگی تو لے آؤٹ “چھلانگ” لگا سکتا ہے کیونکہ جگہ محفوظ نہیں ہے۔ لے آؤٹ کی منتقلی سے بچنے کے لیے XML میں app:errorEnabled="true" کے ذریعے ہمیشہ خرابی کی معاونت کو فعال کرنے کی سفارش کی جاتی ہے۔

setError طریقہ خود بخود صاف ہو جاتا ہے جب فیلڈ کا متن تبدیل ہوتا ہے اگر setErrorEnabled(true) فعال ہو۔ یہ رویہ ریئل ٹائم توثیق کے لیے آسان ہے: جیسے ہی صارف خرابی کو درست کرنا شروع کرتا ہے، سرخ بارڈر غائب ہو جاتا ہے اور فیلڈ معمول کی حالت میں واپس آ جاتا ہے۔ تاہم، پیچیدہ منظرناموں کے لیے یہ خودکار صفائی ناپسندیدہ ہو سکتی ہے — ایسی صورتوں میں، خرابی کو دستی طور پر منظم کریں۔

val til = findViewById<TextInputLayout>(R.id.til_email)

// خرابی کی معاونت کو فعال کریں (بصورت دیگر XML میں سیٹ کریں)
til.isErrorEnabled = true

// خرابی کا پیغام سیٹ کریں
til.error = "Invalid email address"

// خرابی صاف کریں
til.error = null

// چیک کریں کہ آیا خرابی موجود ہے
if (til.error != null) {
    // فیلڈ خرابی کی حالت میں ہے
}

مثال setError/isErrorEnabled تک رسائی کے لیے Kotlin خصوصیات کا استعمال کرتی ہے۔ TextInputLayout خود بخود انٹرفیس کو اپ ڈیٹ کرتا ہے: boxStrokeColor تبدیل کرتا ہے، خرابی کا آئیکن دکھاتا ہے، خرابی کا متن دکھاتا ہے۔ اگر EditText میں متن تبدیل ہوتا ہے تو خرابی خود بخود صاف ہو جاتی ہے۔ دستی ری سیٹ کے لیے، error = null مقرر کریں۔

خرابیوں کو ظاہر کرنے کے متبادل طریقے

تمام پروجیکٹ Material Design Components استعمال نہیں کرتے۔ کسٹم خرابی کی نمائش کے لیے، آپ EditText کے نیچے ایک علیحدہ TextView استعمال کر سکتے ہیں جو خرابی پر ظاہر ہو جاتا ہے۔ یہ طریقہ اسٹائلز اور پیغام کی جگہ پر مکمل کنٹرول دیتا ہے۔ مثال کے طور پر، آپ پیغام کو فیلڈ کے دائیں جانب رکھ سکتے ہیں، مختلف پس منظر کا رنگ استعمال کر سکتے ہیں یا متن کے بائیں جانب ایک آئیکن شامل کر سکتے ہیں۔

Jetpack Compose میں، Error State کو OutlinedTextField یا TextField میں isError پیرامیٹر کے ذریعے نافذ کیا جاتا ہے۔ جب isError = true ہوتا ہے، بارڈر سرخ ہو جاتا ہے اور آپ supportingText کے ذریعے خرابی کا متن دکھا سکتے ہیں۔ Compose میں متن تبدیل ہونے پر خودکار صفائی کی بلٹ ان سہولت نہیں ہے — ڈویلپر remember اور mutableStateOf کا استعمال کرتے ہوئے خرابی کی حالت کو دستی طور پر منظم کرتا ہے۔

گروپ خرابیوں کے لیے (متعدد فیلڈز کے لیے ایک پیغام، مثال کے طور پر «تمام لازمی فیلڈز پُر کریں»)، فارم کے اوپری حصے میں Snackbar، Dialog یا ان لائن بلاک استعمال کریں۔ گروپ خرابی انفرادی فیلڈز کے Error State کو تبدیل نہیں کرتی بلکہ اس کی تکمیل کرتی ہے۔ صارف پہلے عام پیغام دیکھتا ہے، پھر خرابیوں والے مخصوص فیلڈز تلاش کرتا ہے۔

خرابیوں کے رنگ، آئیکن اور حرکت پذیری

Material Design Components میں Error State کا رنگ boxStrokeErrorColor خصوصیت یا تھیم میں colorError خصوصیت کے ذریعے کنٹرول کیا جاتا ہے۔ ڈیفالٹ طور پر، سسٹم کا سرخ رنگ استعمال ہوتا ہے، لیکن اسے ایپ تھیم میں یا براہ راست TextInputLayout میں app:boxStrokeErrorColor="@color/customErrorColor" کے ذریعے اوور رائیڈ کیا جا سکتا ہے۔ ڈارک تھیم کی معاونت کے لیے، ہلکے اور گہرے موڈ کے لیے مختلف رنگوں کے ساتھ ایک سلیکٹر استعمال کرنے کی سفارش کی جاتی ہے۔

خرابی کا آئیکن app:errorIconDrawable کے ذریعے ترتیب دیا جاتا ہے۔ ڈیفالٹ طور پر، دائرے میں فجائیہ نشان دکھایا جاتا ہے۔ اسے کسٹم آئیکن سے تبدیل کیا جا سکتا ہے یا app:errorIconDrawable="@null" مقرر کر کے مکمل طور پر ہٹایا جا سکتا ہے۔ آئیکن TextInputLayout کے آخر میں دکھایا جاتا ہے اور ایک اضافی بصری نشان کے طور پر کام کرتا ہے۔ Material Design 3 میں، رسائی کے لیے خرابی کا آئیکن لازمی ہے۔

خرابی کے ظاہر ہونے کی حرکت پذیری TextInputLayout میں شامل ہے: متن شفافیت میں ہموار تبدیلی کے ساتھ نیچے سے اوپر کی طرف سلائیڈ ہوتا ہے۔ کسٹم حرکت پذیری کے لیے، Transition API یا MotionLayout استعمال کریں۔ مثال کے طور پر، خرابی پر فیلڈ کو ہلانے سے اضافی توجہ مبذول ہوتی ہے۔ تاہم، حرکت پذیری کا زیادہ استعمال UX کو خراب کرتا ہے — پیغام کا ہموار ظاہر ہونا کافی ہے۔

توثیق کے دوران خرابی کی حالت کا انتظام

Error State کا انتظام دو مراحل میں تقسیم ہے: فیلڈ کی توثیق کے دوران خرابی کا تعین کرنا اور اصلاح پر خرابی کو صاف کرنا۔ آسان ترین صورت میں، توثیق TextWatcher.afterTextChanged میں کال کی جاتی ہے: اگر قدر غلط ہے تو خرابی کے پیغام کے ساتھ setError کال کیا جاتا ہے۔ اگر درست ہے تو setError(null) کال کیا جاتا ہے۔ جب setError(null) حالت صاف کرتا ہے تو TextInputLayout خود بخود خرابی چھپا دیتا ہے۔

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

ایک خرابی فوکس کا قاعدہ: فارم جمع کراتے وقت صرف پہلے غلطی والے فیلڈ پر فوکس سیٹ کریں۔ صارف ایک وقت میں ایک خرابی درست کرتا ہے، اور اصلاح کے بعد اگلا غلطی والا فیلڈ خود بخود فوکس حاصل کر لیتا ہے۔ یہ قدم بہ قدم طریقہ علمی بوجھ کو کم کرتا ہے۔ Material TextInputLayout خرابی مقرر کرتے وقت فوکس کو روکتا نہیں — یہ requestFocus() کے ذریعے دستی طور پر کیا جانا چاہیے۔

Error State کے ساتھ کام کرتے وقت عام غلطیاں

پہلی غلطی — isErrorEnabled کی کمی۔ اگر setError سے پہلے setErrorEnabled کو کال نہ کیا جائے تو خرابی کا پیغام ظاہر ہونے پر لے آؤٹ منتقل ہو سکتا ہے۔ یہ خاص طور پر اہم ہے اگر فیلڈ اسکرین کے وسط میں ہو — صارف اپنی سکرول پوزیشن کھو دیتا ہے۔ خرابی مقرر کرنے سے پہلے XML میں app:errorEnabled="true" کے ذریعے یا پروگراماتی طور پر ہمیشہ setErrorEnabled(true) کو فعال کریں۔

دوسری غلطی — بہت لمبا خرابی کا پیغام۔ لمبا متن متعدد سطروں میں تقسیم ہو جاتا ہے اور پڑوسی فیلڈز کو ڈھانپ سکتا ہے۔ خرابی کے پیغام کی تجویز کردہ لمبائی 20-40 حروف ہے۔ اگر مزید معلومات کی ضرورت ہو تو معمول کی حالت میں helperText یا اضافی وضاحت کے لیے ٹول ٹپ استعمال کریں۔ اختصار اچھے Error State کی بنیاد ہے۔

تیسری غلطی — رسائی کو نظر انداز کرنا۔ Error State اسکرین ریڈرز کے لیے قابل رسائی ہونا چاہیے۔ TextInputLayout contentDescription کے ذریعے خود بخود خرابی کا اعلان کرتا ہے، لیکن کسٹم نفاذ کو یہ دستی طور پر کرنا چاہیے۔ خرابی کے پیغامات کے لیے announceForAccessibility() یا android:importantForAccessibility استعمال کریں۔ TalkBack صارفین کو خرابی ظاہر ہونے کے فوراً بعد سننی چاہیے۔