des questions d'échec NSURLConnection

Question

J'utilise NSURLConnection comme indiqué ci-dessous. J'ai trois questions au sujet de cette classe. 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. Utilisation de la première mission d'URL (en commentaire) fonctionne très bien.

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 lorsque

    - (void)connectionDidFinishLoading:(NSURLConnection   *)connection

est touché. Est-il possible 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 je demandé n'a pas été là, mais rien n'indique que?

3.) Je le fais dans mon délégué app. Le seul protocole il y a UIApplicationDelegate. Comment faire pour toutes les méthodes NSURLConnection travail s'il n'y a pas un délégué pour eux?

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 alloc, le copier, ou conserver, de sorte que vous ne possédez pas, alors ne la relâchez.

Comme un détail de mise en œuvre, les chaînes littérales ne mettent pas en œuvre de comptage de référence. objets de chaîne littérale vous ignorer lorsque vous essayez de conserver ou de les libérer. Voilà pourquoi la version où vous relâchez un littéral chaîne ne tombe pas en panne, et la version où vous créez une nouvelle chaîne et la libération qui. Mais ceci est une mise en œuvre du détail de ne pas compter sur elle pour quoi que ce soit. Il faut toujours présumer que la libération de quelque chose que vous ne possédez pas va provoquer un plantage.

  

Y at-il un moyen de vérifier avec précision si receivedData a les données réelles que vous demandez.

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

Contrairement à d'autres données? Vous pouvez utiliser hash, bien que la façon dont vous déterminez le hachage correct d'attendre serait à vous. Cependant, il est probablement plus facile d'avoir juste la foi que le serveur ne vous donnera pas le mauvais fichier.

  

La ressource j'ai demandé était pas là, mais rien n'indique que?

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 retourner un exemple d'erreur pour, en changeant le « afile.mp » que vous avez demandé au « afile.mp4 » qui existe en réalité .

  

3.) Je le fais dans mon délégué app. Le seul protocole il y a UIApplicationDelegate. Comment faire pour toutes les méthodes NSURLConnection travail s'il n'y a pas un délégué pour eux?

Vous avez dit delegate:self, vous êtes délégué de la connexion.

Sur le Mac, au moins, les catégories NSURLConnection les méthodes NSObject, donc ONTO ils sont toujours disponibles, au moins en no-op forme. Vous remplacez ces mises en œuvre, alors quand NSURLConnection envoie votre délégué de connexion (vous) ces messages, ils passent par les implémentations que vous avez fournies.