Я не знаком с MultipleDownload
, но в случае, если он не отвечает вашим потребностям, я решаю, что у вас есть один объект, который является делегатом для многих NSURLConnections
, и вы хотите знать, как держать их прямо.
Все методы делегата возвращают сам NSURLConnection
в качестве первого параметра. Таким образом, вы можете отслеживать, какие данные куда идут, проверяя, какой NSURLConnection
перезванивает вам. Один из способов сделать это - NSDictionary
, который сопоставляет соединение с его NSMutableData
объектом. Хитрость заключается в том, что вы не можете сделать ключом в словаре NSURLConnection
, потому что он не соответствует NSCopying
(и вы бы этого не хотели). Один из способов обойти это - использовать адрес соединения, такой как:
NSString *key = [NSString stringWithFormat:@"%p", connection];
Это вернет уникальный ключ для любого объекта (шестнадцатеричное представление его адреса). Некоторые люди используют description
для этой цели, но мне это не нравится, потому что это плохо определенный интерфейс. Там нет обещания, что он будет уникальным. В системах, где я часто это делаю, я реализую выше -stringWithFormat:
в методе с именем -uniqueIdentifier
и делаю его категорией в NSObject
, чтобы в словаре можно было отследить что угодно.
Я часто нахожу, что проще просто создать небольшой объект-обертку, чтобы каждый объект управлял своим собственным NSURLConnection
, как я уверен, MultipleDownload
делает, но все же эта техника полезна во многих случаях, управляете ли вы несколькими табличными представлениями или чем-то еще, у кого есть делегат.
РЕДАКТИРОВАТЬ: заменил% x у меня было выше на% p, как отметил Питер. Он прав, а я не думал правильно. Дважды проверив мой код, я фактически использовал% p, столкнувшись с этой ошибкой раньше ....