NSURLConnection сохраняет своего делегата?
Или возможно это - реальный вопрос: как можно представить (2) как BST? Это - часть, которая сбивает меня с толку.
Рекурсия.
2 ответа
Не так много сеттеров, которые не копируют или не сохраняют переданную ему переменную, чтобы память указанной переменной не была перераспределена для чего-то еще, когда ее счетчик сохранения достигнет нуля. .
Однако ответ - ДА, это так. Небольшой фрагмент тестового кода показывает, что счетчик удержания делегата увеличивается:
NSLog(@"Retain count before: %d", [self retainCount]);
NSURLRequest* request = [NSURLRequest requestWithURL:[NSURL URLWithString:@"http://google.com"]];
NSURLConnection* conn = [NSURLConnection connectionWithRequest:request delegate:self];
NSLog(@"Retain count after: %d", [self retainCount]);
, что дает в журнале:
Running…
2009-07-09 02:13:40.516 delegateRetain[45123:a0f] Retain count before: 1
2009-07-09 02:13:40.525 delegateRetain[45123:a0f] Retain count after: 2
Debugger stopped.
Таким образом, вы можете довольно ясно видеть, что в connectionWithRequest: delegate: "self" действительно имеет его счетчик удержания увеличился на +1. Если вы чувствуете себя храбрым и хотите возиться с богами EXC_BAD_ACCESS, добавьте
[conn dealloc];
NSLog(@"Retain count after dealloc: %d", [self retainCount]);
, который снова выведет «1», показывая декремент после освобождения. Однако вы получите хороший сигнал, полученный программой: «EXC_BAD_ACCESS».
Большинство свойств делегата не сохраняются, а назначаются для предотвращения циклических ссылок. См. Также этот вопрос об этом.
Однако NSUrlConnection не имеет определенного свойства делегата. Вы должны указать делегата вместе с инициализацией соединения. Думаю, именно поэтому он получает вознаграждение, как показал Дэйв Марторана.