Bon, eh bien, à cause de la NDA, je ne peux pas poster des exemples de code sur la façon de faire les choses en utilisant les SDK iPhone encore, mais je peux poster régulièrement le code de cacao anciens sans se soucier des avocats d'Apple. Si ce code se trouve être utilisable sur l'iPhone also... Oh, bien.
Avec le fait que tant de gens ont téléchargé le SDK, Je dois penser au moins sept ou huit de ces personnes n'ont aucune expérience préalable en utilisant Objective-C ou de cacao. Ces gens ont un peu d'un grokkng courbe. Je dis "grokking» au lieu «d'apprentissage», car la syntaxe de l'Objective-C est simple et relativement facile à apprendre. Toutefois, l'approche qu'il prend est décidément différent des cadres d'application utilisé avec Visual Basic, C # et Java, il prend un peu de temps pour vraiment comprendre la façon dont tout ça fonctionne ensemble et de commencer à travailler avec les cadres plutôt que contre elle.
Une des choses que je suis sûr que beaucoup de développeurs iPhone aspirant voulez faire dans leurs applications est de communiquer avec des serveurs distants. Maintenant, l'un des programmeurs C vieille école qui veulent le faire auront accès aux sockets BSD et peut faire des réseaux de programmation comme ils l'ont toujours fait. Parce que l'Objective-C et Cocoa construire au-dessus de C, vous avez toujours à votre disposition tout ce que vous ne lors de la rédaction de procédure C.
Mais, souvent, il ya un monde meilleur, ou tout au moins, un moyen plus facile de faire des choses en utilisant des classes Cocoa existants. Malheureusement, ce que «meilleure façon» serait pour ce n'est pas si simple. Une option est d'utiliser CFNetwork. FC est synonyme de Core Foundation, Et quand vous voyez quelque chose en commençant par les FC dans le monde du développement logiciel Apple, vous cherchez à faible niveau de fonctions C qui sont utilisés par les bibliothèques de niveau supérieur, comme Cocoa et Carbon. Sous-tend CFNetwork de nombreuses classes de niveau supérieur capable de communiquer avec des serveurs distants. Lorsque vous utilisez NSURLConnection, Ou instancier une NSString using stringWithContentsOfURL:encoding:error:, Vous utilisez des classes qui sont assis sur le dessus de CFNetwork.
Et CFNetwork est grand - il est robuste et écrite de travailler avec un mécanisme de boucle s'exécutent existants, ce qui signifie que vous n'avez pas à détacher les discussions pour éviter de bloquer. Malheureusement, CFNetwork est conceptuellement difficile et il l'aide à Cocoa crée déroutant, difficile à maintenir les classes. Contraindre rappels C dans une instance d'une classe de cacao fonctionne, et il fonctionne bien, mais il n'a tout simplement pas se sentir droit dans le contexte de Objective-C/Cocoa.
Malheureusement, il n'existe pas de classe de cacao générique pour accéder à des serveurs distants. Il ya beaucoup de spéciales à usage de méthodes et de classes qui sont assis sur le dessus de CFNetwork et laissez-vous obtenir des informations de manière transparente sur le réseau en utilisant des URL. Mais que pouvez-vous faire si vous souhaitez implémenter votre propre protocole, ou accéder à un autre type de serveur?
Eh bien, il ya plusieurs classes de tierce partie que vous pourriez utiliser pour cela, y compris sans Dustin Voss AsyncSockets et l'open source SmallSockets du projet. Ce sont deux bonnes options si vous voulez les utiliser.
Quelqu'un sur le Liste de diffusion Dev-cacao récemment souligné que NSFileHandle est capable de gérer la communication socket, mais vous devez réellement créer le socket à l'ancienne et de le nourrir à l'aide NSFileHandle initWithFileDescriptor: pour ce faire. Merci à la beauté de l'Objective-C catégories, cependant, vous n'avez qu'à le faire une fois si vous écrivez le code générique et le mettre dans une catégorie.
Ainsi, grâce à l'aide de plusieurs personnes sur la liste de cacao-Dev, je présente une catégorie sur NSFileHandle qui vous permet d'obtenir une conection à un serveur distant. Vous pouvez télécharger la bonne catégorie here.
L'utilisation de cette catégorie est très simple. Vous pouvez créer une nouvelle NSFileHandle qui est connecté à un serveur distant comme ceci:
NSFileHandle *fh = [NSFileHandle fileHandleToRemoteHost:@"theremoteserver.com" onPort:80];
Pour envoyer une commande et obtenir la réponse, vous devez créer une méthode (probablement sur votre classe contrôleur) qui sera appelée à chaque donnée n'est disponible sur le flux de lecture. Cette méthode pourrait ressembler à ceci:
-(void)process:(id)notification
{
NSFileHandle *fh = [notification object];
NSMutableData *data = [fh availableData];
NSString *dataString = [[NSString alloc]
initWithData:data
encoding:NSUTF8StringEncoding];
/* Process the data however you need to here */
[dataString release];
if (booleanVariableThatIndicatesIfWeExpectMoreData)
[fh readInBackgroundAndNotify];
}
Si vous appelez readInBackgroundAndNotify et il n'ya rien à lire, votre programme ne seront pas lésés, mais votre méthode sera pas appelée à nouveau à moins que vous envoyer un autre message par le serveur. Donc, si vous avez à faire sur le traitement des données récupérées une fois que vous obtenez tout, vous avez besoin de comprendre dans votre code lorsque vous avez reçu tout. Habituellement le protocole vous donne un mécanisme pour le faire. NNTP, Par exemple, envoie une ligne avec juste une seule période sur elle pour vous dire quand c'est fait de vous envoyer des données, mais il laisse la connexion ouverte au cas où vous voulez envoyer plusieurs commandes à travers.
La bonne chose ici: pas de fils. Notre application va sur ses bonhomme de chemin, et nous appelle en arrière quand il ya quelque chose à faire pour nous. À ce stade, nous avons créé le descripteur de fichier, et nous avons créé une méthode pour traiter les réponses du serveur, donc maintenant nous avons juste besoin d'envoyer quelque chose vers le serveur distant, afin que nos processus: la méthode a quelque chose à attendre , que nous faire comme ceci:
[fh writLine:@"HELO\r\n" withObserver:self andProcessWith:@selector(process:)];
C'est tout ce qu'il ya à faire.
Comme je l'ai dit avant, c'est le code de cacao, sans code de Cocoa Touch, mais depuis NSFileHandle fait partie du cadre de la Fondation et non pas le AppKit, il devrait (en théorie) de travail inchangée en Cocoa Touch. Je n'ai pas encore testé, mais je vais, et dès que les ascenseurs NDA en Juin, je vais vous dire si des changements sont nécessaires pour le faire fonctionner sur l'iPhone.
Aucun commentaire:
Enregistrer un commentaire