Input-mask-ios: एकाधिक नकाबपोश पाठ क्षेत्र

अरे @LinusGeffarth!
आपके दयालुता भरे शब्दो के लिए धन्यवाद।

आपके प्रश्न का उत्तर इस बात पर निर्भर करता है कि आपके टेक्स्ट फ़ील्ड में आपके पास किस प्रकार का डेटा है।

यदि आपके पास फ़ोन नंबरों के साथ कई फ़ील्ड हैं - तो आप उन सभी के लिए एक ही MaskedTextFieldDelegate ऑब्जेक्ट शामिल कर सकते हैं क्योंकि मास्क समान होने जा रहे हैं।

ठीक है तो प्रत्येक मुखौटा के लिए एक प्रतिनिधि वस्तु।
जिज्ञासा से बाहर: आपने इसे लागू क्यों नहीं किया ताकि मुखौटा टेक्स्ट फ़ील्ड की संपत्ति हो और सभी टेक्स्ट फ़ील्ड एक ही प्रतिनिधि को साझा करें?

आपने इसे लागू क्यों नहीं किया ताकि मुखौटा टेक्स्ट फ़ील्ड की संपत्ति हो और सभी टेक्स्ट फ़ील्ड एक ही प्रतिनिधि को साझा करें?

@LinusGeffarth , मैं इसे एक बुद्धिमान डिजाइन निर्णय नहीं कहूंगा।

कस्टम टेक्स्ट फ़ील्ड अन्य कस्टम टेक्स्ट फ़ील्ड और समग्र इनहेरिटेंस पदानुक्रम में हस्तक्षेप करेगा। आप अन्य लाइब्रेरी के कस्टम टेक्स्ट फ़ील्ड के साथ मास्किंग का उपयोग नहीं कर पाएंगे; या अन्यथा, आप अपने सभी टेक्स्ट फ़ील्ड के साथ एक मुखौटा संपत्ति के साथ समाप्त हो जाएंगे, जो सामान्य ज्ञान के विपरीत है। आपके UITextView s के साथ भी यही कहानी होगी, और यह और भी बड़ी बात है।

एक ओकाम के रेजर का उपयोग करते हुए, केवल एक चीज जो हमारी लाइब्रेरी संचालित करती है, वह है टेक्स्ट परिवर्तन। इस दृष्टिकोण से, इसकी कार्यक्षमता को लागू करने का सबसे अच्छा तरीका on text changed कॉलबैक से जुड़ना है, जैसा कि एंड्रॉइड समकक्ष के लिए किया गया था।

इसकी सबसे करीबी चीज एक बेवकूफ गधा UITextFieldDelegate प्रोटोकॉल और delegate संपत्ति है; onEditingChanged ईवेंट स्थगित, async और अविश्वसनीय हैं, साथ ही UITextView ऑब्जेक्ट के लिए लक्ष्य-क्रिया संबंध जैसी कोई चीज़ नहीं है।

इस प्रकार, यह सिंथेटिक संस्थाओं की सबसे छोटी मात्रा और उपयोगकर्ता की परियोजना पर सबसे कम प्रभाव के साथ सबसे इष्टतम तरीका है।

आईओएस और मैकओएस एसडीके पहले से ही खराब तरीके से डिजाइन किए गए हैं, आइए अपने सहयोगी डेवलपर्स के लिए जीवन को जटिल न बनाएं। (-:

यदि आपके कोई संबंधित प्रश्न हैं, तो कृपया उन्हें तुरंत पूछें; अन्यथा कृपया इस धागे को बंद करें।

समझ में आता है, विस्तार के लिए धन्यवाद!