Comments 13
К сожалению, у первого подхода был явный недостаток: программно создавая кнопку и вешая ее на навигейшен бар, я не смог бы добиться легко стандартной стрелочки и кнопки назад (у меня просто не было этой иконки, она походу берется из стандартных asset-ов (наборов)).
А в чём проблема?
self.navigationController.navigationBar.topItem.backBarButtonItem = [[UIBarButtonItem alloc] initWithTitle:@"" style:UIBarButtonItemStylePlain target:nil action:nil];
+2
>на 7й прошивке имеется правый свайп interactivePopGestureRecognizer, который позволяет делать переходы назад (он вызывал только метод navigation controller delegate will, из-за чего намертво блочил пользовательское взаимодействие).
Отловить «did» в этом случае можно через transitionCoordinator, подписавшись на завершение транзишена, и в коллбэеке проверив что он не был отменен.
Отловить «did» в этом случае можно через transitionCoordinator, подписавшись на завершение транзишена, и в коллбэеке проверив что он не был отменен.
0
не пробовал пользоваться) методы на завершение транзишена с 7й прошивки, а у меня текущий проект с ios 6 sdk, к тому-же если будет такое поведение только на устройствах с такой вот прошивкой — это будет не слишком хорошо, так как поведение везде должно быть идентичным. Но интересный способ отлавливания
0
фак мой мозг
Возникает мысль о том, что раз в приложении начинает происходить _такое_, то подключение этого кода только усугубляет печальное положение дел в проекте.
Раз уж прям заниматься этим вопросом, то вместо таймеров и retain-циклов предпочел бы private api.
В статье говорится, что
Но ведь
Возникает мысль о том, что раз в приложении начинает происходить _такое_, то подключение этого кода только усугубляет печальное положение дел в проекте.
Раз уж прям заниматься этим вопросом, то вместо таймеров и retain-циклов предпочел бы private api.
В статье говорится, что
Так как анимация по своей сути — действие асинхронное (то есть неизвестен точный момент времени, когда вызовется кусок кода, означающий окончание действия, вследствие чего его невозможно синхронизировать с другими кусками кода.
Но ведь
NSLog(@"animation begin");
[CATransaction begin];
UIViewController *tmp = [UIViewController new];
tmp.view.backgroundColor = [UIColor redColor];
[navigationController pushViewController:tmp animated:YES];
[CATransaction setCompletionBlock:^{
NSLog(@"animation end");
}];
[CATransaction commit];
0
разве begin / commit методы здесь служат не для группировки анимаций? При вызове коммита — создается явная транзакция, и на GPU отдельно обрабатывается в отдельном потоке (асинхронно). Разве не?
Проект не мой, на него меня посадили, потому-что другие от него отказывались. Я же пустил тяжелую артиллерию рефакторинга и архитектурных изменений, с багами уж так вышло, но дела идут более менее успешно
Проект не мой, на него меня посадили, потому-что другие от него отказывались. Я же пустил тяжелую артиллерию рефакторинга и архитектурных изменений, с багами уж так вышло, но дела идут более менее успешно
0
if(self.delegate && [self.delegate conformsToProtocol:@protocol(MyProtocol)] && [self.delegate respondsToSelector: @selector(aMethod)]){ [delegate aMethod]; }
В Obj C не нужно делать проверку на то что объект существует перед тем как послать сообщение.
В этом случае вернется NO.
Зачем проверять что объект поддерживает протокол? Лучше объявить его правильно:
@property (weak, nonatomic) id < MyProtocol> delegate;
Поэтому для optional методов остается так:
if ([delegate respondsToSelector:@selector(aMethod)]){ [delegate aMethod]; }
Для @required без проверок, метод же и так обязательный:
[delegate aMethod];
Не делайте так. Если endIgnoringInteractionEvents не вызовется потом будет очень сложно понять в чем баг.[[UIApplication sharedApplication] beginIgnoringInteractionEvents]; [[UIApplication sharedApplication] endIgnoringInteractionEvents];
Я один раз сталкивался с кодом где это сломалось. Было очень плохо.
Если уж очень надо, выключайте у вью. А лучше все-таки делать проверку по флагу.
Чтобы заблокировать двойные пуши из-за двойных тапов или асинхронных вызовов я бы сначала попробовал проверять контроллер который должен отобразиться на isEqual: с тем что сейчас видимый или с теми что в стеке если необходимо.
Эквивалентность определяем по эквивалентности объекта который нужен контроллеру.
Например для PostViewController это должен быть Post.
А эквивалентность постов проверяем по uid.
Пробовали такой подход?
+1
1) я привел наиболее общий подход проверки перед вызовом метода
2) ранее я тоже писал через weak, но в последнее время в большинстве мест у Apple встречаю запись через assign. Тоже, на самом деле, удивило. Но привел здесь вариант со спецификатором assign
3) если аккуратно использовать метод endIgnoringInteractionEvents — то ничего, а что лочило, пока не довел до ума — такое было. Я не упомянул один недостаток блочить чисто вьюхи. Блокирую таким образом — кнопка back так и останется подсвеченной. Видимо по какой-то причине приходит touchDown, а touchUpInside/touchUpOutside не приходит
4) нет, не пробовал. По правде, даже и не до конца понял суть данного подхода, как его применить
2) ранее я тоже писал через weak, но в последнее время в большинстве мест у Apple встречаю запись через assign. Тоже, на самом деле, удивило. Но привел здесь вариант со спецификатором assign
3) если аккуратно использовать метод endIgnoringInteractionEvents — то ничего, а что лочило, пока не довел до ума — такое было. Я не упомянул один недостаток блочить чисто вьюхи. Блокирую таким образом — кнопка back так и останется подсвеченной. Видимо по какой-то причине приходит touchDown, а touchUpInside/touchUpOutside не приходит
4) нет, не пробовал. По правде, даже и не до конца понял суть данного подхода, как его применить
0
Поясните, пожалуйста, что вы понимаете под экранированием ассинхронного кода. Спасибо!
0
я имею в виду то, что если сделать определенную манипуляцию над данными во время исполнения асинхронного кода, то мы можем получить в результате, что при дальнейшем исполнении обработаются некорректные данные. С сетевыми запросами, например так. Если во время запроса перейти на другое представление выше в иерархии, то указатель на контроллер высвободится, и в результате мы можем получить где-нибудь эксепшен. Простые блокировки, критические секции и мьютексы не всегда способны решить все проблемы с данными, используемыми одновременно более, чем одним потоком.
0
То есть вместо я предлагаю в некоторых случаях блокировать некоторые вызовы методов, подвергающие данные изменениям. В случае с анимациями — это пользовательское взаимодействие, блокирование обработчиков событий
0
Sign up to leave a comment.
UINavigationController и с чем его едят: базовые принципы, субклассирование, защита от двойных переходов и многое другое