بالتفاعل مع التطبيق ، نقوم في مرحلة ما بتنشيط لوحة مفاتيح النظام لكتابة رسالة أو ملء الحقول المطلوبة. هل واجهت مواقف عندما يتم عرض لوحة المفاتيح ، ولكن لا يوجد حقل لإدخال رسالة ، أو العكس - لوحة المفاتيح موجودة ، حيث إدخال النص غير مرئي؟ يمكن أن تكون الأخطاء متعلقة بمشاكل في تطبيق معين ، وكذلك بأوجه القصور العامة في لوحة مفاتيح النظام.

رأى قسطنطين موردان ، وهو مطور لنظام iOS من Mail.ru ، كل شيء في عمله: بعد تحليل طرق التحكم في لوحة المفاتيح في نظام iOS ، قرر مشاركة الأخطاء والطرق الرئيسية التي استخدمها لاكتشافها وإصلاحها.



تحذير: تحت القطع ، وضعنا الكثير من صور متحركة لإظهار الأخطاء بوضوح. ستجد المزيد من الأمثلة في تقرير الفيديو الخاص بـ Konstantin على AppsConf.

تطبيق استدعاء لوحة مفاتيح النظام

لنبدأ بفهم كيفية تنفيذ مكالمة لوحة المفاتيح بشكل عام.

تخيل أنك تقوم بتطوير تطبيق مهمته تجميع Aika (حرف South Park) في كندي كامل باستخدام لوحة المفاتيح. عندما تضغط على Aiku على المعدة ، تغادر لوحة المفاتيح ، وبذلك ترفع ساقي بطلنا إلى الرأس.

لتنفيذ المهمة ، يمكنك استخدام InputAccessoryView أو معالجة إعلامات النظام.

InputAccessoryView

دعنا ننظر إلى الخيار الأول.

في ViewController ، قم بإنشاء طريقة عرض ستظهر مع لوحة المفاتيح ، ثم قم بإعطاءها إطارًا. من المهم عدم إضافة طريقة العرض هذه كطريقة عرض فرعية. بعد ذلك ، فإننا نتجاوز خصائص canBecomeFirstResponder ونعود صائبة . بعد أن نقوم بإعادة تعريف خاصية UIResponder - inputAccessoryView ووضع العرض هناك. لإغلاق لوحة المفاتيح ، أضف tapGesture وفي معالجها ، قم بإعادة تعيين أول مستجيب للعرض الذي أنشأناه .

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.

لتنفيذ قضيتنا ، دعنا نأخذ keyboardWilChangeFrameNotification ، حيث يتم إرسال هذا الإشعار عند عرض لوحة المفاتيح وعندما تكون مخفية.

نقوم بإنشاء لوحة المفاتيح Tracker ، حيث نشترك في استلام إخطار keyboardWillChangeFrame ، وفي المعالج نحصل على إطار لوحة المفاتيح ، ونحوله من نظام إحداثيات الشاشة إلى نظام إحداثيات النافذة ، ونحسب ارتفاع لوحة المفاتيح ونغير قيمة Y للعرض ، والتي ينبغي رفعها بواسطة لوحة المفاتيح ، إلى هذا الارتفاع.

 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: افتح لوحة المفاتيح ، وقم بالتبديل إلى Notes ، وطباعة شيء والعودة إلى التطبيق.



ما هي المشاكل مرئية بالفعل؟ أولاً ، لا توجد لوحة مفاتيح في App Switcher ، على الرغم من أنه عندما يتم تصغير التطبيق إلى الحد الأدنى ، وبدلاً من ذلك ، يكون المحتوى الآخر مرئيًا. ثانياً ، عند العودة إلى التطبيق ، لا تزال لوحة المفاتيح غير موجودة ، وتسقط أرجل Ike أسفل الشاشة.

لنلقِ نظرة على أسباب هذا السلوك. كما نتذكر جميعًا من مخطط دورة حياة التطبيق ، فإن الانتقال من تطبيق ما من حالة نشطة إلى حالة غير نشطة أولاً في المقدمة ثم في الخلفية يستغرق بعض الوقت.

ماذا عن دورة حياة لوحة المفاتيح؟ في نظام التشغيل iOS ، لكل وحدة زمنية ، يمكن امتلاك لوحة المفاتيح لواحد فقط من التطبيقات قيد التشغيل ، لكن يتم تلقي الإخطارات حول التغييرات في حالة لوحة المفاتيح من قبل جميع التطبيقات الموقعة عليها.

عند التبديل من تطبيق إلى آخر ، يقوم النظام بإعادة ضبط أول رده ، والذي يعمل بمثابة مشغل لإخفاء لوحة المفاتيح. يرسل النظام إخطار keyboardWillHide أولاً حتى تختفي لوحة المفاتيح ، ثم keyboardDidHideNotification. ينتقل الإشعار إلى التطبيق الثاني. في التطبيق الجديد ، نفتح لوحة المفاتيح: يرسل النظام keyboardWillShowNotification حتى تظهر لوحة المفاتيح ثم يرسل keyboardDidShowNotification - عرض توضيحي ، مع مراحل الدورة.



إذا نظرت إلى مقتطف من التقرير (من 8:39) ، سترى اللحظة التي يقوم فيها النظام ، بعد إخفاء لوحة المفاتيح ، بإرسال keyboardDidHideNotification لوضع التطبيق الأول في حالة غير نشطة. عندما تقوم بالتبديل إلى التطبيق الرياضي وتشغيل لوحة المفاتيح ، يرسل النظام keyboardWillShowNotification. ولكن نظرًا لأن عملية التبديل والبدء تكون سريعة ، ويمكن أن يكون وقت الانتقال بين مراحل دورة الحياة أطول ، فإن الإخطار المستلم لن يعالج فقط تطبيق الرياضة ، ولكن أيضًا تطبيق البيرة ، التي لم تتمكن بعد من الانتقال إلى الخلفية.

بعد معرفة الأسباب ، دعونا الآن نجد حلاً لمشكلة Ike.

قرار سيء

أول ما يتبادر إلى الذهن هو فكرة إلغاء الاشتراك / الاشتراك في الإشعارات عند تصغير / تعظيم تطبيق من خلال تمكين / تعطيل KeyboardTracker.

لإلغاء الاشتراك ، نستخدم طريقة applicationWillResignActive أو معالج إعلام مماثل من النظام ؛ للاشتراك ، نستخدم applicationDidBecomeActive ، ولكن حتى لا نضيع أي شيء ، سنقوم أيضًا بإخطار طريقة applicationWillEnterForeground ، والتي يتم استدعاؤها عندما يدخل التطبيق المقدمة ، ولكن لا تصبح نشطة حتى الآن.

عند بدء تشغيل لوحة المفاتيح في التطبيق ، من المرجح أن يكون كل شيء ناجحًا ، ولكن مع اختبارات أكثر تعقيدًا ، على سبيل المثال ، فتح لوحة المفاتيح ومحاولة تسجيل الاتصال الصوتي ، لن ينجح الحل.



ماذا حدث بعد النقر على زر الاتصال بالرسائل الصوتية ، تمت إعادة تعيين التطبيق أولاً ، وتم إغلاق لوحة المفاتيح ، وتم استدعاء طريقة applicationWillResignActive وتم إلغاء اشتراكنا. بعد إغلاق التنبيه ، استعاد النظام حالة التطبيق ، ولكن قبل أن يتم استدعاء طريقة applicationWillEnterForeground ، وخاصة applicationDidBecomeActive.

قرار جيد

حل آخر هو استخدام مرق واقية (Bool).

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

نتذكر ما إذا كان قد تم فتح لوحة المفاتيح قبل الموضوع ، وكيف توقف التطبيق عن العمل ، وفي طريقة applicationWillEnterForeground ، نستعيد الحالة السابقة. الشيء الوحيد المتبقي لإصلاح هو ثقب في الجلاد التطبيق.

الجلاد التطبيق

يعرض تطبيق الجلاد لقطات التطبيق التي يقوم بها النظام بعد دخول التطبيق إلى الخلفية. توضح لقطة الشاشة أن لقطة تطبيقنا قد تم إجراؤها في وقت كانت لوحة المفاتيح قيد الاستخدام بالفعل من قبل تطبيق آخر. هذا ليس بالأمر الحاسم ، لكن الأمر يتطلب بضع نقرات لإصلاحه.

حل جيد

يمكن استعارة الحل من التطبيقات المصرفية التي تعلمت إخفاء البيانات الحساسة ، وكذلك القراءة من Apple .

يمكنك إخفاء البيانات في طريقة applicationDidEnterBackground ، وطمس وإظهار شاشة البداية ، وفي طريقة applicationWillEnterForeground ، نعود إلى التسلسل الهرمي للعرض المعتاد.

لا يناسبنا هذا الخيار ، لأنه بحلول الوقت الذي يتم فيه استدعاء طريقة applicationDidEnterBackground ، لم يعد تطبيقنا يحتوي على لوحة مفاتيح.

قرار جيد

سوف نستخدم الطرق المألوفة التي سوف نقوم بتصميمها و إجابتها و أرضها و didBecomeActive.

بينما لا يزال تطبيقنا يحتوي على لوحة مفاتيح ، ستحتاج إلى إنشاء لقطة خاصة بك من التطبيق بطريقة willResignActive ووضعها في التسلسل الهرمي.

 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 لدينا سقطت أدناه.



هذه ليست مشكلة في تطبيقنا فحسب ، بل يتم ملاحظة هذا السلوك أيضًا على Facebook ، والذي يعمل مع الإشعارات ، وحتى بالنسبة لـ 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

تحتوي لوحة المفاتيح على iPad على حالة إلغاء التثبيت إلى جانب حالتها المعتادة. يمكن للمستخدم تحريكه حول الشاشة ، وتقسيمه إلى جزأين ، وحتى تشغيل التطبيق في وضع الانزلاق (أعلى الجزء الآخر). بالطبع ، من المهم أن تعمل لوحة المفاتيح في جميع هذه الأوضاع دون أخطاء.

دعونا التحقق من Hayke لدينا.



للأسف ، هذا ليس هو الحال الآن. بعد أن يبدأ المستخدم في تحريك لوحة المفاتيح حول الشاشة ، تطير أرجل Ike فوق رأسه وتظهر في مكانها فقط بعد الافتتاح التالي للوحة المفاتيح. دعنا نحاول إصلاحه في حالة باستخدام لوحة مفاتيح مقسمة.

أسباب

لنبدأ بتحليل الإشعارات. بعد النقر على زر التقسيم ، نحصل على مجموعتين من الإخطارات - keyboardWillChangeFrameNotification ، keyboardWillHideNotification ، keyboardDidChangeFrameNotification ، keyboardDidHideNotification. الفرق بين المجموعات هو فقط في إحداثيات لوحة المفاتيح.

عندما نقر على زر التقسيم ، تنخفض لوحة المفاتيح وتصل المجموعة الأولى من الإخطارات. عندما انقسمت لوحة المفاتيح وصعدت - حصلنا على حزمة ثانية من الإخطارات.

الشيء المهم هو أننا نتلقى إخطارات بأن لوحة المفاتيح قد اختفت ، ولكن لا يتم عرضها. هذا ، بالمناسبة ، هو إضافة أخرى لصالح استخدام keyboardWillChangeFrameNotification.

لماذا ، إذن ، تطير أرجل Ike بمجرد أن نبدأ في تحريك لوحة المفاتيح حول الشاشة؟

في هذه اللحظة ، يرسل النظام إلينا لوحة المفاتيح WillChangeFrameNotification ، لكن الإحداثيات الموجودة هناك (0.0 ، 0.0 ، 0.0 ، 0.0) ، لأن النظام لا يعرف عند أي نقطة ستكون لوحة المفاتيح بعد اكتمال الحركة.

إذا قمنا باستبدال الأصفار في الكود الحالي الذي يعالج تغيير إطار لوحة المفاتيح ، يتضح أن ارتفاع لوحة المفاتيح يساوي ارتفاع النافذة. هذا هو السبب في أن أرجل Ike تطير من الشاشة.

قرار جيد

لحل مشكلتنا ، أولاً سنتعلم فهم عندما تكون لوحة المفاتيح في وضع إلغاء التثبيت ويمكن للمستخدم تحريكها حول الشاشة.

للقيام بذلك ، ما عليك سوى مقارنة ارتفاع النافذة ولوحة المفاتيح maxY. إذا كانت متساوية ، فإن لوحة المفاتيح في حالتها العادية ، وإذا كان maxY أقل من ارتفاع النافذة ، فإن المستخدم ينقل لوحة المفاتيح. نتيجة لذلك ، يظهر الرمز التالي في keyboardTracker:

 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 ويتم إصلاحها هناك.



سوء التفاهم الوحيد المتبقي هو حقيقة أنه عند تقسيم لوحة المفاتيح ، لا تسقط أرجل 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 الماضي .

الوكالة الدولية للطاقة هي عملية أو سلسلة رسائل تراقب عملية أو سلسلة رسائل أخرى. تتيح لك هذه الآلية مراقبة حالة لوحة المفاتيح وطرق العرض التي تعتمد عليها والإبلاغ عن المشكلات.

لتنفيذ هذه الوظيفة ، نقوم بإنشاء جهاز توقيت يقوم مرة واحدة في الثانية بفحص الموقع الصحيح للعرض بأرجل Hayk أو تسجيل ذلك إذا كان خطأ.

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

بالمناسبة ، يمكنك تسجيل ليس فقط النتائج النهائية ، ولكن أيضًا الحسابات الوسيطة.

نتيجة لذلك ، أعطت وفرة تسجيل + الوكالة الدولية للطاقة بيانات دقيقة عن المشكلة ، وحالة لوحة المفاتيح وتقليل الوقت لإصلاح الأخطاء ، لكنه لم يفعل الكثير لمساعدة مستخدمي بيتا الذين اضطروا إلى تحمل الأخطاء حتى الإصدار التالي.

ولكن ماذا لو كان يمكن تدريب الوكالة الدولية للطاقة ليس فقط للعثور على المشاكل ، ولكن أيضا لإصلاحها؟

في الكود حيث تعطي الوكالة الدولية للطاقة الاستنتاج بأن إحداثيات العرض لا تتلاقى ، نضيف طريقة fixTummyPosition ونضع الإحداثيات تلقائيًا في مكانها.

في هذا الخيار ، يتم تجميع الكثير من المعلومات المفيدة في سجلاتي ، ولا يلاحظ المستخدمون أي مشاكل مرئية على الإطلاق. يبدو ذلك رائعًا ، لكن الآن لا يمكنني معرفة أي مشاكل في لوحة المفاتيح.

يساعد في إضافة القدرة على إنشاء ذاكرة تخزين مؤقت للاختبار عند اكتشاف خطأ ما. بالطبع ، يتم إضافة هذا الرمز تحت التكوين remout.

الآن ، بعد الإصدار التالي ، يمكنك تشغيل إنشاء اختبار التعطل ، وإذا واجه المستخدم مشاكل مع لوحة المفاتيح ، تعطل تطبيقه وبفضل السجلات المجمعة ، يمكنك إصلاح الخلل.

لوحة القيادة

الحيلة الأخيرة التي قدمناها هي إرسال الإحصائيات في الوقت الحالي الذي سجل فيه wahtchdog الإحصاءات. بناءً على البيانات التي تم الحصول عليها ، قمنا برسم عدد الأخطاء المكتشفة وبعد التكرار الأول ، تم تقليل عدد العمليات بأربع مرات. بالطبع ، لم يكن من الممكن تقليل المشكلات إلى الصفر ، لكن الشكاوى الرئيسية من المستخدمين توقفت.

سيتم عقد Saint AppsConf في الأسبوع القادم في مدينة سانت بطرسبرغ ، حيث يمكنك توجيه الأسئلة ليس فقط إلى Konstantin ، ولكن أيضًا إلى العديد من المتحدثين في مسار iOS.