IOS Keyboard notifications run unnecessarily when alerts appear on iOS8.3

We are seeing unusual behavior with respect to the Keyboard willshow and will hide the iOS 8.3 notification.

The view controller (listening to keyboard notifications) has text information and when you press and when you press the submit button, the method first resets the first responder from the text field and displays a warning for the warning. Everything works fine, it rejects the keyboard and displays a warning as expected. (also calls the UIKeyboardWillHideNotification method).

However, in 8.3, after clicking OK / Cancel on the Alertview, it rejects the warning, and it calls UIKeyboardWillShowNotification and UIKeyboardWillHideNotification respectively, although it should not have been called! This was not expected, as the keyboard had already been fired before sending a warning!

Here is a piece of code that we are trying:

- (void)viewDidLoad { [super viewDidLoad]; // Do any additional setup after loading the view, typically from a nib. [[NSNotificationCenter defaultCenter] addObserver:self selector:@selector(keyboardWillHide:) name:UIKeyboardWillHideNotification object:nil]; [[NSNotificationCenter defaultCenter] addObserver:self selector:@selector(keyboardWillShow:) name:UIKeyboardWillShowNotification object:nil]; } - (IBAction)ShowAlert:(id)sender { [self.TxtField resignFirstResponder]; //This woudln't make any diff either :( [self.view endEditing:YES]; [self ShowAlertForTest]; } -(void)ShowAlertForTest{ UIAlertView *theAlertView= [[UIAlertView alloc]initWithTitle:@"Title" message:@"msg" delegate:self cancelButtonTitle:@"Cancel" otherButtonTitles:@"Yes", nil]; [theAlertView show]; } - (void)alertView:(UIAlertView *)alertView clickedButtonAtIndex:(NSInteger)buttonIndex { NSLog(@"buttonIndex = %ld",buttonIndex); } - (void)keyboardWillShow:(NSNotification *)aNotification { NSLog(@"keyboardWillShow"); } - (void)keyboardWillHide:(NSNotification *)aNotification { NSLog(@"keyboardWillHide"); } 

This behavior causes problems in our application when cascading warnings appear, triggered from the previous alertview'd delegate - bringing the keyboard to unnecessary situations.

Any help / advice is appreciated!

+6
source share
4 answers

In our case, the keyboard was hidden manually by the application (for example, when the user enters the system, we hide the keyboard and call the server login API). After a crash, the application presents a UIAlertView error message. When the user closes the warning, iOS messages will / hide and will / will show notifications. Of course, the keyboard is not displayed or hidden during this sequence, because it is already hidden by the application.

However, we noticed that we do not hide the keyboard manually, but instead allow iOS to do this for us, fixes the problem. So, the keyboard automatically hides in two cases:

  • when UIAlertView displayed
  • when view manager is released

Note. the keyboard is automatically displayed when the UIAlertView rejected.

+2
source

My team did the work simply by unsubscribing from the keyboard notifications before submitting the warning and re-signing these notifications after the warning was rejected. Not perfect, but he solved the problem for us.

+1
source

In my case, the user presses the login button, then I call;

 [self.view endEditing: YES]; //server request here and in completion/fail alert. 
The keyboard was closed, the warning was shown well, but when canceled / applied, the click keyboard was shown again and disappeared. But the problem was that sometimes this happened if the server request took a long time, it is not visible if Alertview immediately displays the problem is still there. Therefore, I decided to delay my alerts. Setting a warning delay resolved my problem. Hope this helps.
0
source

I just fixed a similar problem. The keyboard continues to pop up after the warning goes off. It seems to be an apple mistake. I recommend you use UIAlertController instead of UIAlertView. This will avoid many potential problems. There is a simple solution: if you use the UIAlertController, you can simply set up animated NO

 [self presentViewController:alert animated:NO completion:nil]; 

Let me know if your problem has fixed

0
source

Source: https://habr.com/ru/post/987544/


All Articles