NSURLConnection questions d'échec

Question

J'utilise NSURLConnection comme indiqué ci-dessous. J'ai trois questions à propos de ce cours. Quand je concaténer la valeur URL, le débogueur frappe cette ligne deux fois, mais pas la ligne au-dessus:

if (theConnection){ 

La deuxième fois que je reçois EXC_BAD_ACCESS. L'utilisation de la première affectation d'URL (commentée) fonctionne correctement.

1.) Quelle est la différence?

- (void)applicationDidFinishLaunching:(UIApplication *)application { 

//NSString *url = @"http://www.abc.com/afile.mp4"; 

NSString *temp = @"afile.mp4"; 
NSString *url = [@"http://www.abc.com/" stringByAppendingString:temp]; 

theRequest = [NSMutableURLRequest requestWithURL:[NSURL URLWithString:url] 
            cachePolicy:NSURLRequestUseProtocolCachePolicy timeoutInterval:30.0]; 
[url release]; 

NSURLConnection *theConnection = [[NSURLConnection alloc] initWithRequest:theRequest delegate:self]; 
if (theConnection) { 
    receivedData=[[NSMutableData data] retain]; 
} 

2.) Si je change le nom du fichier à afile.mp, la demande passe par et [longueur receivedData] a une valeur d'environ 1600 quand

- (void)connectionDidFinishLoading:(NSURLConnection *)connection 

fait frapper. Existe-t-il un moyen de vérifier avec précision si receivedData a les données réelles que vous demandez. Le fichier cible est d'environ 7 Mo mais peut varier de 1,5 Mo à 9 Mo. La ressource que j'ai demandée n'était pas là mais est-ce que quelque chose l'indique?

3.) Je fais ceci dans mon délégué d'application. Le seul protocole disponible est UIApplicationDelegate. Comment toutes les méthodes NSURLConnection fonctionnent-elles s'il n'y a pas de délégué pour elles?

Answer 1

1.) Quelle est la différence?

- (void)applicationDidFinishLaunching:(UIApplication *)application { 
    //NSString *url = @"http://www.abc.com/afile.mp4"; 
    NSString *temp = @"afile.mp4"; 
    NSString *url = [@"http://www.abc.com/" stringByAppendingString:temp]; 

    theRequest = [NSMutableURLRequest requestWithURL:[NSURL URLWithString:url] 
                      cachePolicy:NSURLRequestUseProtocolCachePolicy timeoutInterval:30.0]; 
    [url release]; 

La différence est que l'un de ceux-ci vous permet de vous en sortir avec quelque chose de libérer vous ne possédez pas et l'autre ne fonctionne pas.

Vous ne l'avez pas alloué, copié ou conservé, donc vous ne le possédez pas, alors ne le relâchez pas. En ce qui concerne la mise en œuvre, les littéraux de chaîne n'implémentent pas le comptage de références. Les objets littéraux de chaîne vous ignoreront lorsque vous tenterez de les conserver ou de les libérer. C'est pourquoi la version dans laquelle vous libérez un littéral de chaîne ne plante pas, et la version dans laquelle vous créez une nouvelle chaîne et une version qui le fait. Mais ceci est un détail d'implémentation - ne comptez pas dessus pour quoi que ce soit. Supposez toujours que la libération de quelque chose que vous ne possédez pas entraînera un crash. Y at-il un moyen de vérifier avec précision si receivedData a les données réelles que vous demandez.

Par opposition à un document d'erreur? Vérifiez le code de réponse.

Contrairement à d'autres données? Vous pouvez utiliser des hachages, bien que la manière dont vous déterminez le hachage correct dépend de vous. Cependant, il est probablement plus facile de croire que le serveur ne vous donnera pas le mauvais fichier.

La ressource que j'ai demandée n'était pas là mais est-ce que quelque chose l'indique?

Oui. Mettre en œuvre connection:didReceiveResponse: et vérifier le code de réponse. Notez que si le serveur utilise mod_speling ou quelque chose de similaire, il peut corriger votre URL au lieu de renvoyer une erreur, par exemple en modifiant le fichier "afile.mp" que vous avez demandé à "afile.mp4". existe.

3.) Je fais ceci dans mon délégué d'application. Le seul protocole disponible est UIApplicationDelegate. Comment toutes les méthodes NSURLConnection fonctionnent-elles s'il n'y a pas de délégué pour elles? Vous avez dit delegate:self, vous êtes donc le délégué de la connexion. Sur le Mac, au moins, NSURLConnection classe les méthodes sur NSObject, donc elles sont toujours disponibles, au moins en mode non-op. Vous surchargez ces implémentations, donc quand NSURLConnection envoie votre connexion déléguer (vous) ces messages, ils passent par les implémentations que vous avez fournies.