- 01
- 02
- 03
- 04
- 05
- 06
- 07
- 08
- 09
- 10
- 11
- 12
- (void)viewDidLoad
{
// ...
float os_verson = [[[UIDevice currentDevice] systemVersion] floatValue];
NSString* dev_ver_str = [[UIDevice currentDevice] systemVersion];
if (os_verson >= 4 || [dev_ver_str hasPrefix:@"3.2"]) {
[self viewWillAppear:NO];
[self viewDidAppear:NO];
}
}
Follow us!
например вот:
[[self parentViewController] performSelector:@selector(dismissModalVi ewController) withObject:nil afterDelay:0.0001];
что он курил, я не знаю
Надо только afterDelay:0 делать. Ну а сейчас проще через GCD.
Берите пример с гуманизма Российской империи. Никакой смертной казни. Максимум - 12000 шпицрутенов.
Смысл расстрела не уменьшении числа говнокодеров. а в удовлетворении садистских наклонностей расстреливающего. Я хочу видеть ужас в глазах провинившегося :)
Гражданин начальник, мне эти наркотики подбросили!
- Это ик... корнет Оболенский на балу... ик... подбежал ко мне и как наблюёт на меня!
- Да он вам и в штаны насрал...
А отложить анимацию на 0,3 тоже нормально. Как еще сделать закрытие модального контроллера, а после этого сразу открытие нового с анимацией. Или поп и пуш в навигейшне оба с анимацией. У них же нет action на конец анимации.
Так что это вполне нормальный интерфейсный код :)
На тему вполненормальности - не соглашусь ещё раз, делал то же самое без задержек. Если уж очень захотелось сделать что-то, для чего не хватает данных при запуске анимации - прицепитесь к колбеку. А то захотите время анимации поменять, и привет.
Ты путаешь способ обучения и аргумент для принятия решения.
afterDelay:0, насколько я помню, еще помогает, если у нас идет скролл scrollView, а что-то хочется в главном потоке сделать, чтобы скролл не тормозил. Откладываем и наслаждаемся.
Вот, например, по-мойму вполне нормальный код. Если на экране несколько полей, и нам надо перестраивать view в зависимости от того, видна клавиатура или нет, то когда с одного поля переключается на другой - дергается перестраивание (вызывается end, потом сразу begin). А если отложить - отлично работает. Если писать по-честному - будет в три раза длинее и менее красиво.
В остальном - это все откладывание, чтобы анимации не накладывались или типо того.
Ну и это не тот performSelector, о котором шла речь. Единственное приемлемое использование из вcех вариантов, что я видел для performSelector:withObject:afterDelay: - скрытие сплэш-скрина.
Как я понял тут все вообще против использования afterDelay на интерфейсе. Я вот и защищаю.
Я без вот этой функции жить не могу:
Можно писать вот так:
В последнем проекте на 1 человеко-месяц 17 использований :)
Оба варианта анимации работают нормально, ищите баги в проекте
Там если кликаем на фон - клавиатура пропадает. Воспроизводится глюк так: кликаем на одно поле, потом переключаем на другое - дергается.
Замените в вашем проекте метод layoutAnimated на следующий
или без блока, что мне нравится больше (нужный метод в форме блока слишком длинный):
и наслаждайтесь ;)
Все переменные после запуска анимации переходят в состояние конечной точки анимации. Дальше меняется только картинка. Запуская анимацию по тем же свойствам, что уже анимируются - вы обрываете анимацию свойств старую.
В данном случае работало всё это так:
При выборе первого поля запускалась анимация и перемещала поля вверх.
Про выборе 2го поля происходило сразу 2 события друг за другом - endEditing и beginEditing
В endEditing запускалась анимация, перемещения полей вниз, но сразу за ней прилетала 2я анимация на те же свойства - перемещение полей вверх. 1я - изменяла состояния переменных, но завершится не успевала. 2я же работала уже целиком, от нижней позиции, выставленной первой.
Опция же BeginFromCurrentState делает ровно то, что написано в её названии - говорит CoreAnimation, что в качестве стартового значения надо использовать текущее состояние анимируемой картинки, а не старые значения свойств. Двойной вызов это не убирает, но избавляет от глюков.
А как работало ваше решение, я даже не представляю, могу предположить только race condition.
В моем случаем layout откладывался до момента, когда курсор уже установился во второе поле. Поэтому он отрабатывал оба раза как надо (обе анимации делали одно и то же).
К стыду своему я не нашёл другого решения, кроме как обрабатывать scrollViewDidEndDragging с задержкой в 0.05 сек )
Тут бы переписать нафиг.