J'ai une application qui effectue des appels SOAP. Pour empêcher le blocage de l'interface utilisateur, nous placons chaque appel SOAP dans une sous-classe de NSOperation. Cela fonctionne bien, mais nous avons une tonne de différents types d'appels SOAP. Donc, si nous utilisons 3 WSDL chacun avec 10 ports ou opérations, alors nous avons 30 appels différents dans SOAP et si nous mettons chacun de ceux-ci dans un thread en utilisant NSOperation, nous nous retrouvons avec 30 sous-classes NSOperation.L'utilisation de NSOperation pour le filetage crée trop d'objets
Cela peut ne pas être une mauvaise chose, mais nous essayons de créer une bibliothèque réutilisable, nous avons donc un objet par WSDL qui encapsule les appels. C'est bien parce que nous utilisons WSDL2ObjC et ceci encapsule toute cette logique. Mais il semble étrange alors d'avoir une bonne api que nous appelons dans ces nombreux NSOperations. En outre, nous faisons le threading dans l'api lui-même, de sorte que l'invocateur peut l'utiliser comme il/elle le juge approprié.
Toutes les suggestions seraient super.
Je l'ai fait. J'espérais utiliser l'opération enverrait une notfication quand elle était complète. Peut-être que je pourrais ajouter la notification à l'API et c'est ainsi que les valeurs de retour sont récupérées, mais cela semble être un mauvais design. Je vais réfléchir un peu plus pour voir si cela va fonctionner. Je vais travailler dessus et voir ce que je peux faire. Merci. – Brian
Le problème avec NSIvocationOperation est qu'il vous permet seulement de passer un objet. Y at-il un travail ou une sorte de liaison dynamique que je peux faire pour contourner cela? – Brian
La meilleure façon de contourner le problème d'un seul objet que je peux penser est de faire un autre objet qui peut contenir tout ce que vous devez passer. Je vais devoir penser à la partie notifiée. Est-ce que tous vos objets WSDL ont à peu près la même méthode? – criscokid