आवेदन के साथ बातचीत करते हुए, हम कुछ बिंदु पर एक संदेश टाइप करने या आवश्यक फ़ील्ड भरने के लिए सिस्टम कीबोर्ड को सक्रिय करते हैं। क्या आपको कीबोर्ड प्रदर्शित होने की स्थिति में सामना करना पड़ा है, लेकिन संदेश में प्रवेश करने के लिए कोई क्षेत्र नहीं है, या इसके विपरीत - कीबोर्ड वहाँ है, जहां पाठ दर्ज करने के लिए दिखाई नहीं दे रहा है? कीड़े एक विशिष्ट एप्लिकेशन के साथ-साथ सिस्टम कीबोर्ड की सामान्य कमियों के साथ समस्याओं से संबंधित हो सकते हैं।

Mail.ru के एक iOS डेवलपर, कॉन्स्टेंटिन मोर्डन ने अपने काम में सब कुछ देखा: iOS में कीबोर्ड नियंत्रण विधियों का विश्लेषण करने के बाद, उन्होंने मुख्य बग और दृष्टिकोणों को साझा करने का फैसला किया और उन्हें पता लगाने के लिए इस्तेमाल किया।



सावधानी: कटौती के तहत, हम कीड़े को स्पष्ट रूप से प्रदर्शित करने के लिए बहुत सारे जिफ़ डालते हैं। एप्सकॉन्फ पर कोंस्टेंटिन की वीडियो रिपोर्ट में आपको और भी अधिक उदाहरण मिलेंगे।

एक सिस्टम कीबोर्ड कॉल को लागू करना

आइए सामान्य रूप से कीबोर्ड कॉल को कैसे लागू करें, यह समझकर शुरू करें।

कल्पना कीजिए कि आप एक ऐसा एप्लिकेशन विकसित कर रहे हैं जिसका कार्य कीबोर्ड का उपयोग करके एक कनाडाई (एक दक्षिण पार्क चरित्र) को पूरे कनाडाई में इकट्ठा करना है। जब आप ऐकू को पेट पर दबाते हैं, तो कीबोर्ड निकल जाता है, जिससे हमारे नायक के पैर सिर की ओर उठ जाते हैं।

कार्य को कार्यान्वित करने के लिए, आप InputAccessoryView या सिस्टम सूचनाओं का उपयोग कर सकते हैं।

InputAccessoryView

पहले विकल्प पर नजर डालते हैं।

ViewController में, एक दृश्य बनाएं जो कीबोर्ड के साथ एक साथ उठेगा, और इसे एक फ्रेम देगा। यह महत्वपूर्ण है कि इस दृश्य को सबव्यू के रूप में नहीं जोड़ा जाना चाहिए। अगला, हम canBecomeFirstResponder गुण को ओवरराइड करते हैं और सही लौटाते हैं। बाद में हम UIResponder गुण - inputAccessoryView को फिर से परिभाषित करते हैं और वहां व्यू डालते हैं। कीबोर्ड को बंद करने के लिए, टैपग्रेचर और उसके हैंडलर में जोड़ें, हमने जो व्यू बनाया है, उसके पहले रीस्पोंडर को रीसेट करें ।

class ViewController: UIViewController { var tummyView: UIView { let frame = CGRect(x: x, y: y, width: width, height: height) let v = TummyView(frame: frame) return v } override var canBecomeFirstResponder: Bool { return true } override var input AccessoryView: UIView? { return tummyView } func tapHandler ( ) { tummyView.resignFirstResponder ( ) } } 

कार्य पूरा हो गया है, और सिस्टम स्वयं कीबोर्ड स्थिति में परिवर्तन करता है, इसे दिखाता है और दृश्य उठाता है, जो इस पर निर्भर करता है।

सिस्टम अधिसूचना प्रसंस्करण

प्रसंस्करण सूचनाओं के मामले में, हमें स्वयं निम्नलिखित समूहों से सूचनाओं को संसाधित करना होगा:

• जब कीबोर्ड होगा / दिखाया गया था: keyboardWillShowNotification, keyboardDidShowNotification;
• जब कीबोर्ड होगा / छिपा हुआ था: keyboardWillHideNotification, keyboardDidHideNotification;
• जब कीबोर्ड फ्रेम बदल जाएगा / बदल दिया जाएगा: KeyboardWilChangeFrameNotification, keyboardDidChangeFrameNotification।

हमारे मामले को लागू करने के लिए, आइए कीबोर्डवैलचेंजफ्रेमनामोटिफिकेशन लेते हैं, क्योंकि यह नोटिफिकेशन दोनों को भेजा जाता है जब कीबोर्ड दिखाया जाता है और जब यह छिपा होता है।

हम एक KeyboardTracker बनाते हैं , इसमें हम एक KeyboardWillChangeFrame नोटिफिकेशन प्राप्त करने के लिए सदस्यता लेते हैं, और हैंडलर में हमें कीबोर्ड फ़्रेम मिलता है, इसे स्क्रीन कोऑर्डिनेट सिस्टम से विंडो कोऑर्डिनेट सिस्टम में कनवर्ट करें, कीबोर्ड की ऊँचाई की गणना करें और कीबोर्ड द्वारा उठाए जाने वाले व्यू का मान बदलकर इस ऊँचाई पर देखें।

 class KeyboardTracker { func enable ( ) { notificationCenter.add0observer(self, seletor: #selector( keyboardWillChangeFrame), name: UIResponder.keyboardWillChangeFrameNotification, object: nil) } func keyboardWillChangeFrame ( notification: NSNotification) { let screenCoordinatedKeyboardFrame = (userInfo [ UIResponder.keyboardFrameEndUserInfoKey ] as! NSValue ) .cgRectValue let keyboardFrame = window.convert ( screenCoordinatedKeyboardFrame, from: nil ) let windowHeight = window.frame.height let keyboardHeight = windowHeight - keyboardFrame.minY delegate.keyboardWillChange ( keyboardHeight ) } } 

इस पर, हमारा कार्य पूरा हो गया है, कीबोर्ड उगता है, कनाडा में इके एकत्र करता है।

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

कीड़े की तलाश में

यदि कीबोर्ड को कॉल करने का तरीका इतना सरल है, तो कीड़े कहां से आते हैं? बेशक, यदि एप्लिकेशन कीबोर्ड खोलने और बंद करने के लिए केवल स्क्रिप्ट को पुन: पेश करता है, तो कोई समस्या नहीं होगी। लेकिन अगर आप सामान्य चीजों को बदलते हैं, तो याद रखें कि न केवल हमारे एप्लिकेशन कीबोर्ड का उपयोग कर सकते हैं, बल्कि अन्य भी, और उपयोगकर्ता भी उनके बीच स्विच कर सकते हैं, फिर आश्चर्य से बचा नहीं जा सकता है।

आइए एक उदाहरण देखें। ऐसा करने के लिए, Ike के साथ हमारे एप्लिकेशन का उपयोग करें: कीबोर्ड खोलें, नोट्स पर स्विच करें, कुछ प्रिंट करें और एप्लिकेशन पर वापस जाएं।



क्या समस्याएं पहले से ही दिखाई दे रही हैं? सबसे पहले, ऐप स्विचर में कोई कीबोर्ड नहीं है, हालांकि जब आपने एप्लिकेशन को कम से कम किया था, और इसके बजाय, अन्य सामग्री दिखाई दे रही है। दूसरे, जब आप एप्लिकेशन पर लौटते हैं, तब भी कीबोर्ड वहां नहीं होता है, और स्क्रीन पर Ike के पैर नीचे गिर जाते हैं।

आइए इस व्यवहार के कारणों को देखें। जैसा कि हम सभी को एप्लिकेशन के जीवनचक्र आरेख से याद है, एक सक्रिय राज्य से एक निष्क्रिय अवस्था में पहले अग्रभूमि में और फिर पृष्ठभूमि में समय के साथ एक आवेदन के परिवर्तन।

कीबोर्ड जीवन चक्र के बारे में क्या? IOS में, समय की प्रत्येक इकाई के लिए, कीबोर्ड का स्वामित्व केवल चल रहे एप्लिकेशनों में से एक के पास हो सकता है, लेकिन कीबोर्ड की स्थिति में बदलाव के बारे में सूचनाएं उन पर हस्ताक्षर किए गए सभी अनुप्रयोगों द्वारा प्राप्त की जाती हैं।

जब एक एप्लिकेशन से दूसरे में स्विच किया जाता है, तो सिस्टम अपने फर्स्टResponder को रीसेट करता है, जो कीबोर्ड को छिपाने के लिए ट्रिगर के रूप में कार्य करता है। सिस्टम कीबोर्ड को गायब करने के लिए पहले एक KeyboardWillHide नोटिफिकेशन भेजता है, और फिर KeyboardDidHideNotification। अधिसूचना दूसरे आवेदन के लिए उड़ान भरती है। नए एप्लिकेशन में, हम कीबोर्ड खोलते हैं: सिस्टम कीबोर्ड को प्रदर्शित करने के लिए कीबोर्ड भेजता है। तब प्रदर्शित होता है और फिर चक्र के चरणों के साथ एक कीबोर्ड-DIDShowNotification - एक डेमो भेजता है।



यदि आप रिपोर्ट के एक अंश (8:39 से) को देखते हैं, तो आपको वह क्षण दिखाई देगा, जब कीबोर्ड को छिपाने के बाद, सिस्टम पहले एप्लिकेशन को निष्क्रिय अवस्था में रखने के लिए कीबोर्डडायहाइडनेटिफिकेशन भेजता है। जब आप खेल ऐप पर स्विच करते हैं और कीबोर्ड लॉन्च करते हैं, तो सिस्टम कीबोर्डव्हीलशूटॉटिफिकेशन भेजता है। लेकिन चूंकि स्विचिंग और शुरू करने की प्रक्रिया त्वरित है, और जीवन चक्र के चरणों के बीच संक्रमण का समय लंबा हो सकता है, प्राप्त अधिसूचना न केवल खेल के लिए आवेदन प्रक्रिया करेगी, बल्कि बीयर के लिए भी आवेदन करेगी, जो अभी तक पृष्ठभूमि में जाने में कामयाब नहीं हुई है।

कारणों का पता लगाने के बाद, आइए अब आइके के साथ समस्या का हल खोजें।

बुरा निर्णय

पहली बात जो दिमाग में आती है, वह है कीबोर्ड सक्षम करने / अक्षम करने के माध्यम से किसी एप्लिकेशन को न्यूनतम / अधिकतम करने पर सूचनाओं को अनसब्सक्राइब / सब्सक्राइब करने का।

सदस्यता समाप्त करने के लिए, हम ApplicationWillResignActive मेथड या सिस्टम से मिलते-जुलते नोटिफिकेशन हैंडलर का उपयोग करते हैं। सब्स्क्राइबिंग के लिए, हम applicationDidBecomeActive का उपयोग करते हैं, लेकिन कुछ भी याद न रखने के लिए, हम ApplicationWillEnterForeground मेथड को भी सूचित करेंगे, जिसे तब कहा जाता है जब एप्लिकेशन अग्रभूमि में प्रवेश करता है लेकिन अभी तक सक्रिय नहीं होता है।

जब आप एप्लिकेशन में कीबोर्ड शुरू करते हैं, तो सबसे अधिक संभावना है कि सब कुछ सफल होगा, लेकिन अधिक जटिल परीक्षणों के साथ, उदाहरण के लिए, कीबोर्ड खोलना और वॉयस डायलिंग रिकॉर्ड करने की कोशिश करना, समाधान काम नहीं करेगा।



क्या हुआ? वॉयस मैसेज डायलिंग बटन पर क्लिक करने के बाद, एप्लिकेशन फर्स्टResponder रीसेट हो गया, कीबोर्ड बंद हो गया, ApplicationWillResignActive पद्धति को कॉल किया गया और हमने सदस्यता समाप्त कर दी। चेतावनी को बंद करने के बाद, सिस्टम ने एप्लिकेशन स्थिति को पुनर्स्थापित किया, लेकिन ApplicationWillEnterForeground विधि और विशेष रूप से ApplicationDidBecomeActive से पहले, को कॉल किया गया था।

अच्छा निर्णय

एक अन्य समाधान एक सुरक्षात्मक शोरबा (बूल) का उपयोग है।

 var wasTummyViewFirstResponderBeforeApp0idEnterBackground func willResignActive( notification: NSNotification) { wasTextFieldFirstResponderBeforeAppDidEnterBackground = tummyView.isFirstResponder } func willEnterForeground ( notification: NSNotification) { if wasTextFieldFirstResponderBeforeAppDidEnterBackground { UIView.performWithourAnimation { tummyView.becomeFirstResponder ( ) } } } 

हमें याद है कि क्या विषय से पहले कीबोर्ड खोला गया था, कैसे एप्लिकेशन सक्रिय होना बंद हो गया था, और एप्लिकेशनविलेटरफॉरग्राउंड विधि में हम पिछली स्थिति को पुनर्स्थापित करते हैं। फिक्स करने के लिए केवल एक चीज बची है जो ऐप स्विचर में छेद है।

ऐप स्विचर

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

अच्छा समाधान

समाधान को उन बैंकिंग अनुप्रयोगों से उधार लिया जा सकता है, जिन्होंने संवेदनशील डेटा को छिपाना सीखा है, और Apple से भी पढ़ा है।

आप ApplicationDidEnterBackground विधि में डेटा छिपा सकते हैं, कलंक स्क्रीन दिखा सकते हैं, और ApplicationWillEnterForeground विधि सामान्य दृश्य पदानुक्रम में वापस आ सकते हैं।

यह विकल्प हमें शोभा नहीं देता, क्योंकि जब तक ApplicationDidEnterBackground विधि को कॉल किया जाता है, तब तक हमारे आवेदन में कीबोर्ड नहीं होता है।

अच्छा निर्णय

हम परिचित तरीकों का उपयोग करेंगे ।ResignActive, willEnterForeground और didBecomeActive।

जबकि हमारे एप्लिकेशन में अभी भी एक कीबोर्ड है, आपको विल-आर्किटेक विधि में एप्लिकेशन का अपना स्नैपशॉट बनाने और इसे पदानुक्रम में रखने की आवश्यकता होगी।

 func willResignActive( notificaton: NSNotification) { let keyWindow = UIApplication.shared.keyWindow imageView = UIImageView( frame: keyWindow.bounds) imageView.image = snapshot ( ) let lastSubview = keyWindow.subviews.last lastSubview( imageView) } 

WillEnterForeground और didBecomeActive विधियों में, हम पदानुक्रम को पुनर्स्थापित करते हैं और हमारे स्नैपशॉट को हटाते हैं।

 func willEnterForeground( notification: NSNotification) { imageView.removeFromSuperview( ) } func didBecomeActive( notification: NSNotification) { imageView.removeFromSuperview( ) } 

नतीजतन, हमने दोनों मामलों को निर्धारित किया: ऐप स्विचर में, एक सुंदर तस्वीर और स्विच करते समय कीबोर्ड अब नहीं कूदता। ऐसा लगता है कि ये ऐसी महत्वपूर्ण चीजें नहीं हैं, लेकिन उत्पाद विकास के लिए, ये बिंदु बेहद महत्वपूर्ण हैं।

बुरी खबर

Ike की समस्या के लिए हमारा सफल समाधान उस मामले से संबंधित है जब आवेदन को कम करने से पहले कीबोर्ड खोला गया था। यदि कीबोर्ड का विस्तार किए बिना स्विचिंग होती है, तो फिर से हम देखेंगे कि हमारे Ike के पैर नीचे गिर गए।



यह न केवल हमारे आवेदन के लिए एक समस्या है, यह व्यवहार फेसबुक के लिए भी मनाया जाता है, जो सूचनाओं के साथ काम करता है, और यहां तक ​​कि iMessage के लिए भी, जो कीबोर्ड को नियंत्रित करने के लिए inputAccessoryView का उपयोग करता है। यह इस तथ्य के कारण है कि पृष्ठभूमि पर स्विच करने से पहले, अनुप्रयोग अन्य लोगों के कीबोर्ड सूचनाओं को संसाधित करने का प्रबंधन करते हैं।

अंतःक्रियात्मक कीबोर्ड बर्खास्तगी

Ike के साथ हमारे एप्लिकेशन में कुछ कार्यक्षमता जोड़ें, कार्यक्रम को अंतःक्रियात्मक रूप से कीबोर्ड को छिपाने के लिए सिखाएं।

बुरा निर्णय

इस कार्यक्षमता को बनाने का एक तरीका कीबोर्ड दृश्य के फ्रेम को बदलना है। हम panGestureRecognizer बनाते हैं, इसके हैंडलर में हम कीबोर्ड के लिए Y निर्देशांक के नए मान की गणना करते हैं, हमारी उंगली की स्थिति के आधार पर, कीबोर्ड दृश्य ढूंढते हैं और इसे Y निर्देशांक मान के साथ अद्यतन करते हैं।

 func panGestureHandler( ) { let yPosition: CGFloat = value keyboardView( )?.frame.origin.y = yPosition } 

कीबोर्ड को एक अलग विंडो में प्रदर्शित किया जाता है, इसलिए आपको एप्लिकेशन में खिड़कियों के पूरे सरणी पर जाने की आवश्यकता है, सरणी के प्रत्येक तत्व की जांच करें कि क्या यह कीबोर्ड विंडो है और यदि हां, तो इससे एक दृश्य प्राप्त करें जो कीबोर्ड दिखाता है।

 func keyboardView( ) -> UIView? { let windows = UIApplication.shared.windows let view = windows.first { (window) -> Bool in return keyboardView( fromWindow: window) != nil } return view } 

दुर्भाग्य से, यह समाधान सामान्य रूप से iPhone X और उच्चतर पर काम नहीं करेगा, क्योंकि जब आप अपनी उंगली को हिलाते हैं, तो आप निचले संकेतक को थोड़ा छू सकते हैं, जो अनुप्रयोग को कम करने के लिए जिम्मेदार है। उसके बाद, इंटरैक्टिव छिपाना काम करना बंद कर देता है।



समस्या खिड़कियों के सरणी में है।



इशारे के बाद, सिस्टम मौजूदा एक के ऊपर एक नया कीबोर्ड विंडो बनाता है। यह अकल्पनीय है, लेकिन सच है। नतीजतन, यह पता चला है कि सरणी में समान निर्देशांक के साथ दो कीबोर्ड विंडो हैं, लेकिन पहले छिपा हुआ है।



यह पता चला है कि, खिड़कियों के सरणी पर चलने से, हम पहले वाले को ढूंढते हैं जो शर्तों को संतुष्ट करता है, और इसके साथ काम करना शुरू कर देता है, इस तथ्य के बावजूद कि यह छिपा हुआ है।

यह कैसे तय हुआ? खिड़कियों की एक सरणी मोड़ना।

 func panGeastureHandler( ) { let yPosition: CGFloat = 0.0 keyboardView( )?.frame.origin.y = yPosition } func keyboardView( ) -> UIView? { let windows = UIApplication.shared.windows.reversed( ) let view = windows.first { (window) -> Bool in return keyboardView( fromWindow: window) != nil } return view } 

IPad पर कीबोर्ड सुविधाएँ

आईपैड पर कीबोर्ड, सामान्य स्थिति के अलावा, एक अनडॉकड स्टेट है। उपयोगकर्ता इसे स्क्रीन के चारों ओर ले जा सकता है, इसे दो भागों में विभाजित कर सकता है और यहां तक ​​कि एप्लिकेशन को स्लाइड ओवर मोड (दूसरे के शीर्ष पर) में भी लॉन्च कर सकता है। बेशक, यह महत्वपूर्ण है कि इन सभी मोड में कीबोर्ड बग के बिना काम करता है।

आइए हमारे हायके पर जांच करें।



काश, अब ऐसा नहीं होता। जब उपयोगकर्ता स्क्रीन के चारों ओर कीबोर्ड ले जाने लगता है, तो इके के पैर उसके सिर के ऊपर से उड़ जाते हैं और कीबोर्ड के अगले खुलने के बाद ही दिखाई देते हैं। चलो एक विभाजन कीबोर्ड के साथ एक मामले पर इसे ठीक करने की कोशिश करते हैं।

कारणों

चलो सूचनाओं का विश्लेषण करके शुरू करते हैं। स्प्लिट बटन पर क्लिक करने के बाद हमें दो नोटिफिकेशन ग्रुप मिलते हैं - KeyboardWillChangeFrameNotification, KeyboardWillHideNotification, keyboardDidChangeFrameNotification, keyboardDidHideNotification। समूहों के बीच अंतर केवल कीबोर्ड के निर्देशांक में है।

जब हम विभाजित बटन पर क्लिक करते हैं, तो कीबोर्ड कम हो जाता है और सूचनाओं का पहला समूह आता है। जब कीबोर्ड अलग हो गया और ऊपर चला गया - हमें सूचनाओं का दूसरा पैकेट मिला।

महत्वपूर्ण बात यह है कि हमें सूचनाएं प्राप्त होती हैं कि कीबोर्ड गायब हो गया है, लेकिन ऐसा नहीं है कि यह प्रदर्शित हो। यह, वैसे, KeyboardWillChangeFrameNotification का उपयोग करने के पक्ष में एक और प्लस है।

क्यों, जैसे ही हम स्क्रीन के चारों ओर कीबोर्ड को हिलाना शुरू करते हैं, इके के पैर उड़ जाते हैं?

इस समय, सिस्टम हमें एक KeyboardWillChangeFrameNotification भेजता है, लेकिन निर्देशांक जो वहां झूठ बोलते हैं (0.0, 0.0, 0.0, 0.0), क्योंकि सिस्टम को यह पता नहीं है कि आंदोलन पूरा होने के बाद कीबोर्ड किस बिंदु पर होगा।

यदि आप कीबोर्ड कोड को बदलने वाले वर्तमान कोड में शून्य स्थानापन्न करते हैं, तो यह पता चलता है कि कीबोर्ड की ऊंचाई खिड़की की ऊंचाई के बराबर है। यही कारण है कि Ike के पैर स्क्रीन से दूर उड़ते हैं।

अच्छा निर्णय

हमारी समस्या को हल करने के लिए, पहले हम यह समझना सीखेंगे कि कीबोर्ड अनडॉक किए गए मोड में है और उपयोगकर्ता इसे स्क्रीन के चारों ओर ले जा सकता है।

ऐसा करने के लिए, बस विंडो की ऊंचाई और अधिकतम कीबोर्ड की तुलना करें। यदि वे समान हैं, तो इसकी सामान्य स्थिति में कीबोर्ड, यदि अधिकतम खिड़की की ऊंचाई से कम है, तो उपयोगकर्ता कीबोर्ड को स्थानांतरित करता है। परिणामस्वरूप, कीबोर्ड कोडर में निम्न कोड दिखाई देता है:

 class KeyboardTracker { func enable( ) { notificationCenter.addObserver( self, selector:#selector( keyboardWillChangeFrame), name:UIResponder.keyboardWillChangeFrameNotification, object:nil) } func keyboardWillChangeFrame( notification: NSNotification) { let screenCoordinatedKeyboardFrame = (userInfo[UIResponder.keyboardFrameEndUserInfoKey] as! NSValue).cgRectValue let leyboardFrame = window.convert ( screenCoordinatedKeyboardFrame, from: nil) let windowHeight = window.frame.height let keyboardHeight = windowHeight - keyboardFrame.minY let isKeyboardUnlocked = isIPad ( ) && keyboardFrame/maxY < windowHeight if isKeyboardUnlocked { keyboardHeight = 0.0 } delegate.keyboardWillChange ( keyboardHeight) } } 

हम कस्टम को ऊंचाई शून्य पर सेट करते हैं, और अब कीबोर्ड के आंदोलन के साथ, इके के पैर नीचे जाते हैं और वहां तय होते हैं।



केवल शेष गलतफहमी यह तथ्य है कि कीबोर्ड को विभाजित करते समय, Ike के पैर तुरंत नीचे नहीं गिरते हैं। इसे कैसे ठीक करें?

हम KeyboardTracker को KeyboardWillChangeFrameNotification से ही नहीं, बल्कि KeyboardDidChangeFrame के साथ भी काम करना सिखाएंगे। आपको नया कोड लिखने की ज़रूरत नहीं है, बस एक चेक जोड़ें कि यह एक iPad है ताकि अनावश्यक गणना न करें।

 class KeyboardTracker { func keyboardDidChangeFrame( notification: NSNotification) { if isIPad ( ) == false { return } 

बग का पता कैसे लगाएं?

प्रचुर मात्रा में प्रवेश

हमारी परियोजना पर, लॉग निम्न प्रारूप में लिखे गए हैं: वर्ग कोष्ठक में, मॉड्यूल और सबमॉड्यूल का नाम, जिसमें लॉग संबंधित है, और फिर लॉग का पाठ। उदाहरण के लिए, इस तरह:
[keyboard][tracker] keyboardWillChangeFrame: calculated height - 437.9

कोड में, यह निम्नानुसार दिखता है - एक लकड़हारा एक शीर्ष-स्तरीय टैग के साथ बनाया गया है और ट्रैकर को प्रेषित किया गया है। ट्रैकर के अंदर, दूसरे स्तर के टैग के साथ एक लॉगर, जिसका उपयोग कक्षा के अंदर लॉगिंग के लिए किया जाता है, लकड़हारे से दूर हो जाता है।

 class KeyboardTracker { init(with logger: Logger) { self.trackerLogger = logger.dequeue(withTag: "[tracker]") } func keyboardWillChangeFrame(notification: NSNotification) { let height = 0.0 trackerLogger.debug("\(#function): calculated height - \(height)") } } 

इसलिए मैंने पूरे कीबोर्ड को तैयार किया, जो अच्छा है। अगर परीक्षकों को समस्या मिली, तो मैंने लॉग फ़ाइल ली और ठीक उसी जगह की तलाश की जहां फ्रेम फिट नहीं था। इसमें बहुत अधिक समय लगा, इसलिए, लॉगिंग के अलावा, अन्य तरीके लागू होने लगे।

निगरानी

हमारे प्रोजेक्ट में, यूआई स्ट्रीम को ऑप्टिमाइज़ करने के लिए वॉचडॉग का उपयोग किया जाता है। यह दिमित्री कुर्किन ने पिछले AppsConf में से एक में बताया था।

वॉचडॉग एक प्रक्रिया या धागा है जो किसी अन्य प्रक्रिया या थ्रेड को देखता है । यह तंत्र आपको कीबोर्ड की स्थिति और उस पर निर्भर विचारों की निगरानी करने और समस्याओं की रिपोर्ट करने की अनुमति देता है।

ऐसी कार्यक्षमता को लागू करने के लिए, हम एक टाइमर बनाते हैं जो एक बार एक सेकंड में हेक के पैरों के साथ दृश्य के सही स्थान की जांच करेगा या यदि यह त्रुटि है तो इसे लॉग इन करें।

 class Watchdog { var timer: Timer? func start ( ) { timer = Timer ( timeInterval: 1.0, repeats: true, block: { ( timer ) in self.woof ( ) } ) } } 

वैसे, आप न केवल अंतिम परिणाम लॉग कर सकते हैं, बल्कि मध्यवर्ती गणना भी कर सकते हैं।

परिणामस्वरूप, प्रचुर लॉगिंग + वॉचडॉग ने समस्या, कीबोर्ड की स्थिति के बारे में सटीक डेटा दिया और बग को ठीक करने के लिए समय कम कर दिया, लेकिन इसने बीटा उपयोगकर्ताओं को मदद करने के लिए बहुत कम किया, जिन्हें अगली रिलीज तक त्रुटियों को सहना पड़ा।

लेकिन क्या होगा अगर वॉचडॉग को न केवल समस्याओं को खोजने के लिए प्रशिक्षित किया जा सकता है, बल्कि उन्हें ठीक करने के लिए भी?

उस कोड में जहां वॉचडॉग यह निष्कर्ष देता है कि दृश्य के निर्देशांक अभिसरण नहीं करते हैं, हम FixTummyPosition विधि जोड़ते हैं और स्वचालित रूप से निर्देशांक डालते हैं।

इस विकल्प में, मेरे लॉग में बहुत सारी उपयोगी जानकारी जमा है, और उपयोगकर्ता दृश्य समस्याओं को बिल्कुल भी नहीं देखते हैं। यह बहुत अच्छा लगता है, लेकिन अब मुझे कीबोर्ड की किसी भी समस्या के बारे में पता नहीं चल पाएगा।

यह वॉचडॉग पद्धति को एक त्रुटि का पता चलने पर टेस्ट कैश उत्पन्न करने की क्षमता को जोड़ने में मदद करता है। बेशक, यह कोड रीमाउट कॉन्फिगर के तहत जोड़ा गया है।

अब, अगली रिलीज़ के बाद, आप परीक्षण क्रैश पीढ़ी को चालू कर सकते हैं और, यदि उपयोगकर्ता को कीबोर्ड की समस्या है, तो उसका एप्लिकेशन क्रैश हो जाता है और एकत्र किए गए लॉग्स के लिए धन्यवाद, आप बग्स को ठीक कर सकते हैं।

डैशबोर्ड

हमने जो आखिरी ट्रिक शुरू की है, वह उस समय के आंकड़े भेज रही है, जब वाहटचोग ने आंकड़े दर्ज किए। प्राप्त आंकड़ों के आधार पर, हमने ज्ञात त्रुटियों की संख्या को प्लॉट किया और पहले पुनरावृत्ति के बाद, संचालन की संख्या चार गुना कम हो गई। बेशक, समस्याओं को शून्य तक कम करना संभव नहीं था, लेकिन उपयोगकर्ताओं की मुख्य शिकायतें बंद हो गईं।

अगले हफ्ते सेंट एप्सकॉन्फ सेंट पीटर्सबर्ग में आयोजित किया जाएगा, जहां आप न केवल कोंस्टेंटिन से सवाल पूछ सकते हैं, बल्कि आईओएस-ट्रैक के कई वक्ताओं से भी पूछ सकते हैं।