Input-mask-ios: الرموز الثابتة في القناع
سيكون من الرائع أن يكون لديك القدرة على استخدام الرموز الثابتة.
على سبيل المثال ، أحتاج إلى قناع رقم الهاتف: +7 (111) 111-11-11
لذلك وفقًا للوثائق ، يمكنني إنشاء قناع لهذه الحالة: +7 ([000]) [000] - [00] - [00]
وهذا جيد. لكني أحتاج أن لا يستطيع المستخدم مسح قبضة اثنين من الرموز (+7). لذلك في كل مرة يجب أن يكون "+7" مرئيًا دائمًا في حقل النص.
razalur
ال 3 كومينتر
ياrazalur
شكرا على اقتراحك. سأعود بتعليقاتي لاحقًا هذا الأسبوع ، ترقبوا ذلك!
taflanidi
في ٢ مارس ٢٠١٧
أي تحديثات؟
TikhonovAlexander
في ٤ مايو ٢٠١٧
تضمين التغريدة razalur قد يكون مهتمًا أيضًا.
شكرا لتذكيري حول طلب الميزة هذا. لقد أجرينا حديثًا قصيرًا مع اثنين من المبشرين من Apple حول وجود نص غير قابل للتحرير داخل حقل النص.
TL ؛ DR: لن ندعم هذه الميزة.
لا ينتهك HIG مباشرة على الرغم من أنها فكرة سيئة لتقييد سيطرة المستخدم على التطبيق وتولي عملية صنع القرار. لا تتصرف حقول النص الأصلي على هذا النحو ، وتحتوي iOS SDK بالفعل على مكون لنص ثابت - UILabel .
لا يمكنك تعطيل زر Backspace للوحة المفاتيح الأصلية أو تعطيله ، وستؤدي الرموز غير القابلة للمسح إلى حدوث ارتباك ، حيث لن يتمكن المستخدم النهائي من تحديد ما إذا كان سلوكًا مصممًا أم خطأ. "لماذا لا يعمل زر Backspace بالضبط؟" - ولا يمكنك إعطاء تلميح واضح.
من منظور تصميم مكتبتنا ، من الواضح أن المطور قد يضع رمزًا "ثابتًا" في منتصف السطر. ولكن ماذا تتوقع أن يحدث عندما يبدأ المستخدم في حذف الأحرف من بداية السطر؟
تظهر المزيد من الأسئلة عندما تقرر تضمين زر مسح UITextField .
لن تسمح لك طريقة المندوب المقابلة -textFieldShouldClear() بمسح حقل النص جزئيًا ، فهي تهدف إلى محو كل النص. يعد تجاوز سلوك الزر الواضح أو تمديده قرارًا تصميميًا غامضًا وبالتالي مسؤولية كبيرة لمكتبتنا ، لأنه سيتعين علينا تغطية جميع حالات الاستخدام. سيريد بعض الأشخاص (المطورين والمستخدمين ) زر المسح الأصلي لمحو كل النص ، وسيتوقع شخص ما بقاء جميع الرموز "الثابتة" بعد المسح ، وسيفترض البعض الآخر أن البادئة "الثابتة" فقط يجب أن تبقى و "ثابتة" يجب محو الأحرف الموجودة في منتصف السطر.
الشيء الوحيد الذي يمكنني مساعدتك به هو نصيحة للتفكير في الأهداف التي تهدف إلى تحقيقها.
لا تقاتل SDK لأن SDK يفوز دائمًا.
taflanidi
في ٤ مايو ٢٠١٧
القضايا ذات الصلة
LinusGeffarth
·
4تعليقات
DamascenoRafael
·
4تعليقات
beltik
·
6تعليقات
caioremedio
·
6تعليقات
KompoD
·
5تعليقات
التعليق الأكثر فائدة
تضمين التغريدة razalur قد يكون مهتمًا أيضًا.
شكرا لتذكيري حول طلب الميزة هذا. لقد أجرينا حديثًا قصيرًا مع اثنين من المبشرين من Apple حول وجود نص غير قابل للتحرير داخل حقل النص.
TL ؛ DR: لن ندعم هذه الميزة.
لا ينتهك HIG مباشرة على الرغم من أنها فكرة سيئة لتقييد سيطرة المستخدم على التطبيق وتولي عملية صنع القرار. لا تتصرف حقول النص الأصلي على هذا النحو ، وتحتوي iOS SDK بالفعل على مكون لنص ثابت -
UILabel.لا يمكنك تعطيل زر Backspace للوحة المفاتيح الأصلية أو تعطيله ، وستؤدي الرموز غير القابلة للمسح إلى حدوث ارتباك ، حيث لن يتمكن المستخدم النهائي من تحديد ما إذا كان سلوكًا مصممًا أم خطأ. "لماذا لا يعمل زر Backspace بالضبط؟" - ولا يمكنك إعطاء تلميح واضح.
من منظور تصميم مكتبتنا ، من الواضح أن المطور قد يضع رمزًا "ثابتًا" في منتصف السطر. ولكن ماذا تتوقع أن يحدث عندما يبدأ المستخدم في حذف الأحرف من بداية السطر؟
تظهر المزيد من الأسئلة عندما تقرر تضمين زر مسح
UITextField.لن تسمح لك طريقة المندوب المقابلة
-textFieldShouldClear()بمسح حقل النص جزئيًا ، فهي تهدف إلى محو كل النص. يعد تجاوز سلوك الزر الواضح أو تمديده قرارًا تصميميًا غامضًا وبالتالي مسؤولية كبيرة لمكتبتنا ، لأنه سيتعين علينا تغطية جميع حالات الاستخدام. سيريد بعض الأشخاص (المطورين والمستخدمين ) زر المسح الأصلي لمحو كل النص ، وسيتوقع شخص ما بقاء جميع الرموز "الثابتة" بعد المسح ، وسيفترض البعض الآخر أن البادئة "الثابتة" فقط يجب أن تبقى و "ثابتة" يجب محو الأحرف الموجودة في منتصف السطر.الشيء الوحيد الذي يمكنني مساعدتك به هو نصيحة للتفكير في الأهداف التي تهدف إلى تحقيقها.
لا تقاتل SDK لأن SDK يفوز دائمًا.