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 के माध्यम से अंतर्निहित सत्यापन तीसरे पक्ष की लाइब्रेरी के बिना बुनियादी परिदृश्यों को कवर करता है। जटिल परियोजनाओं (फिनटेक, हेल्थकेयर) के लिए, संयोजन का उपयोग करना बेहतर है: Material Components + Clean Architecture की डोमेन परत से पैटर्न के साथ कस्टम सत्यापन।

फ़ील्ड सत्यापन में सामान्य त्रुटियाँ

पहली त्रुटि है इनपुट शुरू होने से पहले त्रुटि दिखाना। यदि कोई फ़ील्ड अनिवार्य है लेकिन उपयोगकर्ता ने इसे भरना शुरू नहीं किया है, तो “फ़ील्ड अनिवार्य है” न दिखाएँ। यह समस्या की झूठी भावना पैदा करता है। त्रुटि केवल तब दिखनी चाहिए जब उपयोगकर्ता ने फ़ील्ड के साथ बातचीत की हो: टाइप करना शुरू किया, फ़ील्ड छोड़ा, या फ़ॉर्म सबमिट करने का प्रयास किया।

दूसरी त्रुटि है अस्पष्ट त्रुटि संदेश। संदेश विशिष्ट होना चाहिए और समस्या को ठीक करने का सुझाव देना चाहिए। “अमान्य ईमेल” खराब है। “ईमेल में @ और एक डोमेन होना चाहिए, जैसे user@example.com” अच्छा है। उपयोगकर्ता को यह समझना चाहिए कि वास्तव में क्या गलत है और दस्तावेज़ीकरण का संदर्भ दिए बिना इसे कैसे ठीक किया जाए।

तीसरी त्रुटि है बिना स्पष्टीकरण के सबमिशन को अवरुद्ध करना। यदि सत्यापन त्रुटियों के कारण सबमिट बटन निष्क्रिय है, तो उपयोगकर्ता को देखना चाहिए कि कौन से फ़ील्ड अमान्य हैं। संदेशों के बिना एक ग्रे बटन उपयोगकर्ता के लिए एक मृत अंत है। हमेशा त्रुटियों वाले फ़ील्ड को हाइलाइट करें और प्रत्येक अमान्य फ़ील्ड के बगल में त्रुटि टेक्स्ट दिखाएँ।