3

I have the following viewDidLoad method:

- (void)viewDidLoad {
    NSLog(@"didLoad");
    if (self.loginField.text.length > 0) [self.passwordField becomeFirstResponder];
    else [self.loginField becomeFirstResponder];
}

I also add log times in viewWillAppear and viewDidAppear.

There are some situations when push animation takes much time. I have measured the time with commented (and without) if-else lines (see: the times are shown below). I don't know what can slow down my app between viewWillAppear and viewDidAppear calls.

I tried to anayze this fragment of code with Time Profiler (Instruments), but it shows nothing. I have no clue what should I do, to show my view faster. Any ideas?

With becomeFirstResponder, first call

2014-07-11 16:51:41.090 didLoad
2014-07-11 16:51:41.133 willAppear
2014-07-11 16:51:44.223 did appear
diffAppear = 3090ms

With becomeFirstResponder, second call

2014-07-11 16:52:01.370 didLoad
2014-07-11 16:52:01.400 willAppear
2014-07-11 16:52:02.109 did appear
diffAppear = 709ms

Without becomeFirstResponder, first call

2014-07-11 16:57:21.720 didLoad
2014-07-11 16:57:21.754 willAppear
2014-07-11 16:57:22.420 did appear
diffAppear = 666ms

Without becomeFirstResponder, second call

2014-07-11 16:57:31.851 didLoad
2014-07-11 16:57:31.870 willAppear
2014-07-11 16:57:32.541 did appear
diffAppear = 671ms
rmaddy
  • 314,917
  • 42
  • 532
  • 579
Szu
  • 2,254
  • 1
  • 21
  • 37
  • 1
    the `–becomeFirstResponser` normally loads the _input views_ for the actual object which takes time. on the other hand, you should call this method _after_ your view is in the navigation stack and in the view-hierarchy properly, which means in that case: _in_ or _after_ the `–viewDidAppear:` method, not sooner. – holex Jul 11 '14 at 15:28
  • But then keyboard will not appear immidietly – Szu Jul 11 '14 at 15:36
  • yes, that is true, but that is not a good practice and as you have seen – is extremely slow. – holex Jul 11 '14 at 15:38
  • Maby it is not a good practice, but my solution show keyboard immidietly and on faster devices (4s and higher) is almost invisible. – Szu Jul 11 '14 at 15:48
  • if the speed is okay for you on faster devices, I don't understand your question then... slower devices obviously do the same procedure slower than the faster siblings. the only thing you can do is reorganise your code finding some balance and try to not stress the slower devices too hard. – holex Jul 11 '14 at 15:54
  • As you mention the speed is okey, but only on faster devices. On my iPhone 4 it takes 2.3 second to start animate. Anyway: I accept that I should call -becomeFirstResponder in -viewDidAppear: but when my keyboard won't appear fast. – Szu Jul 11 '14 at 16:15

1 Answers1

0

As @holex metion in comments:

the –becomeFirstResponser normally loads the input views for the actual object which takes time. on the other hand, you should call this method after your view is in the navigation stack and in the view-hierarchy properly, which means in that case: in or after the –viewDidAppear: method, not sooner.

I moved –becomeFirstResponser to -viewDidAppear:. Now according to this question I added these observers as shown below and now app as it should.

- (void)willShowKeyboard:(NSNotification *)notification {
    [UIView setAnimationsEnabled:NO];
}

- (void)didShowKeyboard:(NSNotification *)notification {
    [UIView setAnimationsEnabled:YES];
}

    [[NSNotificationCenter defaultCenter] addObserver:self selector:@selector(willShowKeyboard:) name:UIKeyboardWillShowNotification object:nil];
    [[NSNotificationCenter defaultCenter] addObserver:self selector:@selector(didShowKeyboard:) name:UIKeyboardDidShowNotification object:nil];

It is not a perfect solution (push animation haven't got keyboard) but is good enough for me.

Community
  • 1
  • 1
Szu
  • 2,254
  • 1
  • 21
  • 37