›

Mise à  jour de données entre différentes vues après modifications

heliohelio Membre
dans API UIKit #1
Bonsoir à  tous,

 

Je voudrais connaitre votre manière de faire lorsque vous êtes dans la situation que je vais vous présenter :

 

Je récupère des données d'un webservice sous format XML, notamment toutes les infos concernant un produit (nom, description, s'il est dans mon stock, si je le souhaite etc...)

 

Mon application est construite à  partir du template Tabbed app, j'ai donc une rubrique accueil, recherche, produits et mon compte.

 

Mon problème : 

Admettons que je sois dans la rubrique produit, je vois tous les produits affichés par l'intermédiaire d'une TableView avec nom, description mais pas si je l'ai dans mon stock ni si je souhaite l'avoir dans mon stock car je ne suis pas connecté.

Maintenant je bascule sur mon compte, je me connecte et je reviens dans la rubrique produit, je souhaiterais avoir les infos - si le produit est dans mon stock, si je le souhaite - qui s'affichent (je mets une petite icône pour ces infos). Comment vous procédez ?

 

A l'heure actuelle, je reparse les données à  chaque fois dans viewWillAppear de la vue Produits, cela fonctionne mais le problème est que je voudrais éviter de trop solliciter le web service. 

 

Merci 

Réponses

  • DrakenDraken Membre
    #2

    A première vue, il n'y a aucune raison de recharger les données à  partir du web service. Une seule fois suffit. Tu devrais créer une classe de stockage pour archiver le résultat du parsage et s'y référer à  chaque affichage de la vue produits. Cela évite de solliciter le web service, et accélère la vitesse de l'application, le téléchargement du XML et le parsage prenant forcément du temps.

  • Joanna CarterJoanna Carter Membre, Modérateur
    novembre 2017 modifié #3

    Le plus simple est de construire un Singleton (un objet dont on ne peut pas avoir plus d'un) que l'on puisse accéder de n'importe où dans ton code.


     


    e.g.



    
public struct DataProvider
    
{
    
private init() { }
    

    
public static let sharedInstance = DataProvider()
    

    
public lazy var donnees: Donnees =
    
{
    
// récuperer tes données
    
}()
    
}

    Maintenant, tu peux l'accéder comme :



    
{
    
let donnees = DataProvider.sharedInstance.donnees
    

    
...
    
}

  • MagiicMagiic Membre
    #4

    Tout dépend des sdk que tu utilises actuellement mais pour moi, si c'est pour un usage immédiat sans persistence permanente, j'entends par là  sans vouloir réutiliser la même réponse du web service après avoir tué l'application par exemple, je stockerais la réponse dans le disque.


  • CéroceCéroce Membre, Modérateur
    novembre 2017 modifié #5

    Tout dépend des sdk que tu utilises actuellement mais pour moi, si c'est pour un usage immédiat sans persistence permanente, j'entends par là  sans vouloir réutiliser la même réponse du web service après avoir tué l'application par exemple, je stockerais la réponse dans le disque.

    [ironie]
    Si on part de ce principe, on peut aussi dire que comme NSURLSession a un cache disque, autant relancer la requête. Vu qu'on va déjà  se retaper le parsing du XML, on n'est plus à  ça près.
    D'ailleurs, du coup, il n'y a même peut-être plus besoin de régler le problème, puisque le serveur ne sera pas sollicité, grâce au cache.
    [/ironie]
  • CéroceCéroce Membre, Modérateur
    novembre 2017 modifié #6

    A première vue, il n'y a aucune raison de recharger les données à  partir du web service. Une seule fois suffit. Tu devrais créer une classe de stockage pour archiver le résultat du parsage et s'y référer à  chaque affichage de la vue produits. Cela évite de solliciter le web service, et accélère la vitesse de l'application, le téléchargement du XML et le parsage prenant forcément du temps.

    Bonne réponse de l'élève Draken.

    A l'heure actuelle, je reparse les données à  chaque fois dans viewWillAppear de la vue Produits, cela fonctionne mais le problème est que je voudrais éviter de trop solliciter le web service.

    Voir ici:
    http://forum.cocoacafe.fr/topic/15453-problème-de-mémoire-avec-la-carte/page-2#entry149818
  • heliohelio Membre
    #7

    Merci pour vos conseils,


    en revanche si l'utilisateur met à  jour son stock (par exemple en ajoutant un produit), cela se fait par une méthode de l'API, donc je suis bien obligé de recharger les données à  un moment ? 


  • heliohelio Membre
    #8

    Sinon j'ai pensé que je pouvais utiliser NotificationCenter, ça fonctionne, je recharge seulement après une mise à  jour du stock, on m'en avait parlé ici sur ce forum.


    Mais depuis que j'ai lu cet article :


    https://davidnix.io/post/stop-using-nsnotificationcenter/


    je ne sais pas si c'est bien ? 


  • CéroceCéroce Membre, Modérateur
    novembre 2017 modifié #9
    ça fonctionne, et c'est de toute façon mieux que re-parser.

    J'ai survolé l'article, mais il identifie bien les divers problèmes suscités par les notifications. En gros, le principal inconvénient est que les notifications sont globales. On a donc du mal à  suivre les flux d'informations, et si ça change à  un seul endroit, ça casse à  d'autres qui n'ont pas un lien évident " et pire, à  l'exécution, pas à  la compilation.

    Il n'y a rien de plus fiable que l'injection de dépendance. Ce n'est malheureusement pas toujours faisable avec Cocoa, et parfois, il faudra passer par des setters. Avec ces deux solutions, les passages de paramètres se font de proche en proche, aussi les flux d'informations sont limpides.
  • heliohelio Membre
    #10

    Merci Ceroce pour les explications.


  • iLandesiLandes Membre
    #11

    Moi j'adore les protocoles : Tellement plus clair que les notifications


  • CéroceCéroce Membre, Modérateur
    #12
    C'est un outil différent. Pour pouvoir invoquer une méthode d'un protocole, il faut déjà  avoir une référence sur l'objet destinataire.

    Les notifications ont souvent l'air de bidouilles, mais il se trouve qu'on a souvent besoin de bidouilles pour contourner les limitations du SDK. Il faut donc éviter d'y recourir pour les choses standard, mais ça rend service.
Connectez-vous ou Inscrivez-vous pour répondre.