Récupérer des données via JSON + API_Key

frenche

Bonjour à  tous.

 

J'essaye depuis plusieurs jours de me connecter à  un service WEBAPI.

Mon application est sensé récupérer des données sur un site internet.

Pou s'y connecter j'ai besoin de renseigner un LOGIN + PASSWORD, le site me génère une ID_KEY que je dois réutiliser pour un HTTP REQUEST.

 

Voici l'extrait de mon code.

NSURL *urlkey = [NSURL URLWithString:@http://www.siteweb.com/api/auth/login.json?user=USER&pwd=PASSWORD];

NSURLRequest *request2 = [NSURLRequest requestWithURL:urlkey];

[NSURLConnection sendAsynchronousRequest:request2

queue:[NSOperationQueue mainQueue]

completionHandler:^(NSURLResponse *response,

NSData *data, NSError *connectionError)

{

if (data.length > 0 && connectionError == nil)

{

NSDictionary *greeting = [NSJSONSerialization JSONObjectWithData:data

options:0

error:NULL];

self.Key.text = [greeting objectForKey:@SessionId];

NSString *ID_KEY= Key.text;

//affichage dans un UILABEL pour vérification

}

}];









//Récup des valeurs suivantes

NSString *urlString = [NSString stringWithFormat:@http:;//www.siteweb.com/api/get.json?SessionId=%@&;id=738", ID_KEY];

NSURL *url1 = [NSURL URLWithString:urlString];



NSURLRequest *request3 = [NSURLRequest requestWithURL:url1];

[NSURLConnection sendAsynchronousRequest:request3

queue:[NSOperationQueue mainQueue]

completionHandler:^(NSURLResponse *response,

NSData *data, NSError *connectionError)

{

if (data.length > 0 && connectionError == nil)

{

NSDictionary *greeting = [NSJSONSerialization JSONObjectWithData:data

options:0

error:NULL];

self.X1.text = [[greeting objectForKey:@Value] stringValue];

}

}];

Mon problème à  l'heure actuelle est de conserver mon API_KEY pour le "réinjecter" dans les adresses suivantes.

 

Si quelqu'un a une solution je suis preneur.

 

Merci d'avance.

 

 

Céroce

Crée une classe avec une propriété qui conserve l'API Key.

Ensuite, tous les appels au web service passeront par un objet de cette classe.

frenche

Merci je n'y avais pas pensé...

 

Je vais essayer çà .

Am_Me

Alors frenche je ne sais pas quel est ton niveau en programmation :

 

Connais tu la notion d'UML ?

 

Bon que tu ne connaisse ou pas : avant de créer une application prend un stylo et dessine, à  la fois ton interface, et à  la fois les classes susceptibles à  utiliser : le but étant que tu réussisse virtuellement (sans le code) à  faire un scénario :

 

Et la tu pourras mieux t'organiser, tu va perdre du temps à  faire des dessins et des scénarios mais tu vas gagner en temps dans le code après

 

C'est un conseil, d'autres ne seront pas d'accord avec cela

Joanna Carter

Après 23 ans d'expérience, je suis totalement d'accord

frenche

Je suis effectivement totalement novice...

J'ai déjà  une première application faite dans un désordre le plus total.....

 

Je suis en train de finir sa mise à  jour, et j'ai cette fois travailler en amont avec des dessins entre CLASS et interface.

 

Je confirme vos affirmations, mieux vaut commencer par de bons vieux dessins avant toute chose...

 

Je vais créer ma class à  partir de demain et je vous tiens informer..

Am_Me

Ok. 

 

Après il y a une notion que je ne maitrise pas et que pas mal de développeur ne maitrise pas est de codé de façon modulable.

 

Alors je m'explique : le but est de créer une application facilement modifiable dans le long terme : 

Le but étant que tu puisses facilement rajouter des fonctionnalités etc ... sans trop toucher à  tout ton code. 

 

Mais bon les dessins te permettras déjà  de mieux t'en sortir

Céroce

Après il y a une notion que je ne maitrise pas et que pas mal de développeur ne maitrise pas est de codé de façon modulable.

Il n'y a pas une réponse à  ce problème mais des dizaines. La base, c'est de savoir découper une application en couche et en modules. Il y a une raison si les vétérans vous ennuient toujours avec leur "MVC, fais du MVC, petit scarabée"! Respecter les principes SOLID aide bien également.

 

C'est ce que j'explique sans arrêt aux débutant en programmation: la difficulté de notre métier n'est pas de savoir comment répondre à  une exigence " même si c'est ce qui paraà®t difficile quand on débute " mais de gérer la complexité. 

AliGator

Ok. 

 

Après il y a une notion que je ne maitrise pas et que pas mal de développeur ne maitrise pas est de codé de façon modulable.

 

Alors je m'explique : le but est de créer une application facilement modifiable dans le long terme : 

Le but étant que tu puisses facilement rajouter des fonctionnalités etc ... sans trop toucher à  tout ton code. 

 

Mais bon les dessins te permettras déjà  de mieux t'en sortir

Ouais dans l'ensemble je suis d'accord, au sens où il faut respecter les designs patterns plutôt que de partir dans tous les sens.

Cependant, il ne faut pas oublier le KISS et le YAGNI et éviter d'overcompliquer les choses quand ce n'est pas nécessaire. Donc disons ne pas prévoir l'usine à  gaz dès le départ juste pour imaginer un éventuel usage complexe à  long terme qui n'arrivera peut-être jamais, mais plutôt faire évoluer l'architecture au fur et à  mesure des besoins. Mais bon on est d'accord que pour ça il faut déjà  qu'au départ elle soit un minimum modulable et donc respecte quelques bases d'architecture quand même, genre pas faire n'importe quoi et un sac de nouilles dès le début ^^

 

Ceci étant dit, je suis le premier à  être d'accord avec SOLID (normal, pour un architecte logiciel de métier, vous allez me dire ^^) et le fait d'isoler les responsabilités. Une classe dédiée à  la communication avec tes WebServices, qui mémorise l'APIKey entre autres et centralise la logique WS est un classique (je le fais pour toutes mes applications d'ailleurs) incontournable.

 

---

 

Sinon je ne saurai que te sur-conseiller de respecter les conventions de nommage dans ton code, et de prendre cette habitude rapidement (au risque de prendre de mauvaises habitudes difficiles à  perdre par la suite). Tant pour aider à  la lisibilité de ton code par d'autres personnes que pour permettre à  divers mécanismes de Cocoa (ARC, KVC, KVO, ...) de fonctionner correctement automatiquement.

 

Quand je vois ta propriété "Key" avec une majuscule par exemple, ou le fait que tu fais parfois référence à  ta propriété (self.Key) et parfois à  sa variable d'instance de stockage (Key) directement (sans doute sans avoir conscience des différences et impacts que cela a), qui en plus a certainement été synthétisée à  la main (@synthesize) vu que son nom ne suit pas le nommage automatique qui aurait été fait sinon... ça fait mal aux yeux ^^

Sans parler du fait que tu mélanges Modèle et Vue (et donc les différentes parties du MVC) en récupérant ta clé dans ID_KEY (encore un non respect des conventions de nommage) " en plus déclarée localement (méconnaissance de la notion de "scope" des variables ?) " à  partir de la propriété text d'un UILabel... le label ne doit pas servir de source pour le modèle, c'est plutôt l'inverse !