- 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];
}
}
QuickNick 21.01.2013 23:49 # 0
tyler 22.01.2013 00:08 # 0
например вот:
[[self parentViewController] performSelector:@selector(dismissModalVi ewController) withObject:nil afterDelay:0.0001];
что он курил, я не знаю
krypt 22.01.2013 00:25 # 0
pilot34 22.01.2013 01:11 # 0
Надо только afterDelay:0 делать. Ну а сейчас проще через GCD.
krypt 22.01.2013 04:44 # +1
QuickNick 22.01.2013 14:06 # 0
Берите пример с гуманизма Российской империи. Никакой смертной казни. Максимум - 12000 шпицрутенов.
krypt 22.01.2013 15:07 # +2
Смысл расстрела не уменьшении числа говнокодеров. а в удовлетворении садистских наклонностей расстреливающего. Я хочу видеть ужас в глазах провинившегося :)
QuickNick 22.01.2013 15:11 # 0
krypt 22.01.2013 15:17 # 0
QuickNick 22.01.2013 15:20 # 0
QuickNick 22.01.2013 15:12 # 0
krypt 22.01.2013 15:16 # +1
bormand 22.01.2013 15:30 # +6
Гражданин начальник, мне эти наркотики подбросили!
krypt 22.01.2013 16:11 # 0
TarasB 22.01.2013 15:55 # +3
- Это ик... корнет Оболенский на балу... ик... подбежал ко мне и как наблюёт на меня!
- Да он вам и в штаны насрал...
pilot34 22.01.2013 15:36 # 0
А отложить анимацию на 0,3 тоже нормально. Как еще сделать закрытие модального контроллера, а после этого сразу открытие нового с анимацией. Или поп и пуш в навигейшне оба с анимацией. У них же нет action на конец анимации.
Так что это вполне нормальный интерфейсный код :)
QuickNick 22.01.2013 15:49 # 0
pilot34 22.01.2013 15:51 # 0
QuickNick 22.01.2013 15:53 # 0
roman-kashitsyn 22.01.2013 16:01 # +1
pilot34 22.01.2013 16:12 # 0
roman-kashitsyn 22.01.2013 16:20 # 0
QuickNick 22.01.2013 16:27 # 0
roman-kashitsyn 22.01.2013 16:30 # 0
krypt 22.01.2013 16:15 # 0
На тему вполненормальности - не соглашусь ещё раз, делал то же самое без задержек. Если уж очень захотелось сделать что-то, для чего не хватает данных при запуске анимации - прицепитесь к колбеку. А то захотите время анимации поменять, и привет.
krypt 22.01.2013 16:18 # 0
QuickNick 22.01.2013 16:20 # +1
krypt 22.01.2013 16:34 # +1
Ты путаешь способ обучения и аргумент для принятия решения.
pilot34 22.01.2013 16:20 # 0
afterDelay:0, насколько я помню, еще помогает, если у нас идет скролл scrollView, а что-то хочется в главном потоке сделать, чтобы скролл не тормозил. Откладываем и наслаждаемся.
krypt 22.01.2013 16:36 # 0
pilot34 22.01.2013 17:02 # +1
Вот, например, по-мойму вполне нормальный код. Если на экране несколько полей, и нам надо перестраивать view в зависимости от того, видна клавиатура или нет, то когда с одного поля переключается на другой - дергается перестраивание (вызывается end, потом сразу begin). А если отложить - отлично работает. Если писать по-честному - будет в три раза длинее и менее красиво.
В остальном - это все откладывание, чтобы анимации не накладывались или типо того.
krypt 22.01.2013 17:15 # 0
Ну и это не тот performSelector, о котором шла речь. Единственное приемлемое использование из вcех вариантов, что я видел для performSelector:withObject:afterDelay: - скрытие сплэш-скрина.
pilot34 22.01.2013 17:26 # +1
Как я понял тут все вообще против использования afterDelay на интерфейсе. Я вот и защищаю.
Я без вот этой функции жить не могу:
Можно писать вот так:
В последнем проекте на 1 человеко-месяц 17 использований :)
krypt 22.01.2013 18:49 # 0
krypt 22.01.2013 18:47 # 0
Оба варианта анимации работают нормально, ищите баги в проекте
pilot34 22.01.2013 23:21 # 0
Там если кликаем на фон - клавиатура пропадает. Воспроизводится глюк так: кликаем на одно поле, потом переключаем на другое - дергается.
krypt 22.01.2013 23:58 # +1
Замените в вашем проекте метод layoutAnimated на следующий
или без блока, что мне нравится больше (нужный метод в форме блока слишком длинный):
и наслаждайтесь ;)
krypt 23.01.2013 00:03 # 0
pilot34 23.01.2013 00:55 # 0
krypt 23.01.2013 02:11 # 0
Все переменные после запуска анимации переходят в состояние конечной точки анимации. Дальше меняется только картинка. Запуская анимацию по тем же свойствам, что уже анимируются - вы обрываете анимацию свойств старую.
В данном случае работало всё это так:
При выборе первого поля запускалась анимация и перемещала поля вверх.
Про выборе 2го поля происходило сразу 2 события друг за другом - endEditing и beginEditing
В endEditing запускалась анимация, перемещения полей вниз, но сразу за ней прилетала 2я анимация на те же свойства - перемещение полей вверх. 1я - изменяла состояния переменных, но завершится не успевала. 2я же работала уже целиком, от нижней позиции, выставленной первой.
Опция же BeginFromCurrentState делает ровно то, что написано в её названии - говорит CoreAnimation, что в качестве стартового значения надо использовать текущее состояние анимируемой картинки, а не старые значения свойств. Двойной вызов это не убирает, но избавляет от глюков.
А как работало ваше решение, я даже не представляю, могу предположить только race condition.
pilot34 23.01.2013 02:17 # 0
В моем случаем layout откладывался до момента, когда курсор уже установился во второе поле. Поэтому он отрабатывал оба раза как надо (обе анимации делали одно и то же).
krypt 23.01.2013 02:27 # 0
krypt 23.01.2013 02:38 # 0
К стыду своему я не нашёл другого решения, кроме как обрабатывать scrollViewDidEndDragging с задержкой в 0.05 сек )
krypt 23.01.2013 00:01 # +1
QuickNick 23.01.2013 03:49 # 0
krypt 23.01.2013 04:21 # 0
QuickNick 23.01.2013 10:39 # 0
QuickNick 22.01.2013 16:23 # 0
QuickNick 22.01.2013 14:14 # 0
Тут бы переписать нафиг.
tyler 22.01.2013 22:54 # 0
QuickNick 24.01.2013 08:30 # 0
absolut 24.01.2013 10:29 # +3
QuickNick 24.01.2013 13:19 # +3