Cas d'utilisation 2 possibilités pour la même action
Question 1: Quelle est la bonne façon de construire un Cas d'Utilisation (ou plusieurs) avec 2 façons de faire la même action?
Par exemple:
J'ai 3 écrans d'une application iOS:
1. Une vue de la carte, qui peut être pressé" et dispose d'un bouton de la caméra.
2. Une vue de la caméra, qui est affichée si l'utilisateur appuie sur le bouton de la caméra dans la vue de la carte.
3. Un lieu/pin écran d'édition, qui est affichée si l'utilisateur "long presses" la vue de la carte, ou après que l'utilisateur choisit une photo dans la vue de la caméra. Cette édition de point de vue a un bouton "enregistrer" pour créer de la place avec une photo et l'emplacement (appui long de coordonner ou de l'emplacement actuel dans le cas où le bouton de la caméra a été presses).
Titre: Créer Un Lieu
Flux de base:
1. Utilisateur “appui long” sur la carte.
2. Application des gouttes d'un nip temporaire et l'affiche de l'édition à la vue.
3. Utilisateur modifie la place de l'information et appuie sur le bouton enregistrer.
4. Application crée de la place et de l'enregistrer.
Titre: Créer Un Lieu
Flux de base:
1. Utilisateur appuie sur le bouton plus.
2. Application affiche une vue de la caméra.
3. L'utilisateur prend une photo.
4. Application crée lieu avec emplacement actuel et de l'image.
Mise à JOUR sur la base des commentaires échangés avec bhavik.
Question 2: (Basé sur bhavik réponse)
Je n'ai pas besoin d'un présentateur d'un interacteur précisément, je peux avoir 1 interacteur et 3 présentateurs/points de vue.
- Dans mon cas, je devrais avoir un présentateur/affichage de la carte, qui est où il commence,
- alors que je devrais avoir un présentateur/la vue de la caméra, dans le cas où l'utilisateur appuie sur le bouton de la caméra
- et un présentateur/vue pour la vue d'édition, dans le cas où l'utilisateur "des pressions longues" ou après que l'utilisateur choisit la photo de la caméra présentateur/affichage et est redirigé vers la même vue d'édition.
Est-ce exact?
Question 3: mon frontière méthodes pour l'interacteur toujours de retour void?
Dans bhavik l'exemple, ils sont de retour à quelque chose, mais dans le VIPER blog et l'oncle Bob vidéo elles retournent toujours nulle, et le résultat se présente sous la forme d'une autre limite de la méthode que l'interacteur appelle le présentateur/contrôleur.
Question 4: La VIPER ne pas utiliser un contrôleur, seul un présentateur de parler à l'interacteur, lorsque l'oncle Bob vidéo utilise un contrôleur et un présentateur de différentes interactions avec l'interacteur. Quelle approche doit-je prendre?
Question 5: Si mon Cas d'Utilisation est quelque chose comme "Aller à l'autre de l'écran", devrait-il y a même un interacteur? Depuis le point de vue actuel dira son présentateur quel bouton a été pressé (la vue qu'à l'aller) et ce courant présentateur va dire à son fil de fer ", "changer pour cet autre fil de fer".
OriginalL'auteur Rodrigo Ruiz | 2014-09-24
Vous devez vous connecter pour publier un commentaire.
Question 1: Quelle est la bonne façon de construire un Cas d'Utilisation (ou plusieurs) avec 2 façons de faire la même action?
Dans VIPÈRE de conception, vous pouvez créer deux méthodes dans la même Interacteur adapté à chacun des principaux titulaires et suppléants du cas d'utilisation.
Question 2: (Basé sur bhavik réponse)
Je n'ai pas besoin d'un présentateur d'un interacteur précisément, je peux avoir 1 interacteur et 3 présentateurs/points de vue.
D'après notre discussion et vos mises à jour, je crois que je comprends mieux.
CameraView
.Donc, vous devriez avoir une seule
EditPlacePresenter/View
pourEditPlaceInteractor
que transmettre des données à l'Endroit de données, avec ou sans Photo.Question 3: mon frontière méthodes pour l'interacteur toujours de retour void?
Dans bhavik l'exemple, ils sont de retour à quelque chose, mais dans la VIPER blog, et l'oncle Bob est la vidéo qu'ils retournent toujours nulle, et le résultat se présente sous la forme d'une autre limite de la méthode que l'interacteur appelle le présentateur/contrôleur.
Je pense que vous faites référence à l'-dessous Présentateur méthode qui reçoit les résultats de l'Interacteur.
Pour la ci-dessus pour le travail, l'Interacteur aura délégué instances qui sera câblé/patché par le Présentateur/Contrôleur à la recherche pour de suite ou de données. Cela signifie que le Présentateur/Contrôleur est liée à l'Interacteur ou leur référence ou de retour de la fonction de pointeur est passé dans chaque Interacteur appel de méthode. Est-ce par choix?
Je pense, Interacteur doit retourner des données par les cas d'utilisation. Par exemple Interacteur doit retourner le EditPlaceResult avec succès ou l'échec.
Cela devrait faire partie du cas d'utilisation. Si non, alors, il ne devrait pas retourner quoi que ce soit. Il sera de retour nulle et un autre Interacteur va être interrogé par le Présentateur pour vérifier si la Carte le Lieu a été ajouté avec succès ou non.
Références dans le blog:
Question 4: La VIPER ne pas utiliser un contrôleur, seul un présentateur de parler à l'interacteur, lorsque l'oncle Bob vidéo utilise un contrôleur et un présentateur de différentes interactions avec l'interacteur. Quelle approche doit-je prendre?
Vous devez définir la VIPÈRE routes de navigation suivantes:
MapView
àCameraView
(Utilisation d'Emplacement)MapView
àEditPlaceView
(Utilisation de Coordonnées)CameraView
àEditPlaceView
MapView
en cas de succèsQue par la VIPÈRE blog, afficher les contrôleurs et les contrôleurs de la navigation sont utilisés par les Présentateurs et les Wireframes.
VIPER Filaire gère la Navigation et rend la vue des contrôleurs de devenir maigre, moyenne, affichage de la commande de machines.
Fondamentalement Filaire résumés loin manette de navigation et fournit plutôt une définition de la route.
Filaire
Présentateur
Question 5: Si mon Cas d'Utilisation est quelque chose comme "Aller à l'autre de l'écran", devrait-il y a même un interacteur? Depuis le point de vue actuel dira son présentateur quel bouton a été pressé (la vue qu'à l'aller) et ce courant présentateur va dire à son fil de fer ", "changer pour cet autre fil de fer".
Pas. La Navigation dans le cadre de cas d'utilisation ne peuvent pas besoin d'Interacteur. C'est la transition. La cible Présentateur peut avoir besoin d'un Interacteur. Par exemple,
CameraView/Presenter
n'a pas besoin d'Interacteur maisEditPlaceView
besoin pour économiser de la place.Globale:
L'idée derrière modèles architecturaux est de diviser une application de logiciel en parties reliées entre elles, de manière à séparer les représentations internes de l'information à partir de la façon de présenter l'information ou acceptées par l'utilisateur. MVC, MVP, MVVM, la VIPÈRE à chacun de se concentrer sur les isoler de la Vue, de la Logique et de la Navigation d'une manière ou d'une autre.
Modèles architecturaux sont limités dans ce qu'ils ont l'intention de se décomposer. Nous devons comprendre que les modèles architecturaux ne se décomposent pas ou isoler le tout. Aussi si un modèle architectural délègue certaines responsabilités à certaines partie, d'autres ne le font pas du tout probable ou attribuer des responsabilités multiples à une seule partie.
Nous a permis d'étendre ou de limiter l'isolement et de la décomposition dans la mesure où il justifie la cause et n'impose pas inutile de séparation des préoccupations qui dépassent le coût. Vous pouvez choisir d'utiliser des manettes de navigation et votre animateur peut prendre dépendance sur eux, sans fil de fer de définir des itinéraires. Ces contrôleurs, alors, sera responsable de la navigation entre les écrans.
Pour la question 3: je voudrais utiliser (Articles)findItems(). Dans ce cas, il doit être asynchrone, un moyen d'appeler findItems() dans async façon de Presenter. L'Interacteur n'ont pas de savoir qu'il est utilisé de façon asynchrone. C'est le Présentateur qui devrait prendre de telles décisions. Pour le TDD et les tests Unitaires, vous n'auriez pas besoin async comportement. Juste séquentielle des appels de méthode.
Pour la question 4: le Présentateur serait les seuls devraient être les yeux et les oreilles pour la Vue. Il n'est pas nécessaire pour un Contrôleur dédié à cette conception jusqu'à présent parce que l'iOS fournir aux Contrôleurs de la zone dans le cadre du kit de développement. Ils sont câblés dans l'ensemble de l'INTERFACE utilisateur de la Trousse à outils. Donc, il n'y a aucun moyen d'y échapper et de VIPÈRE ne semblent pas prendre avantage de celui-ci sous le capot. Alors que, de l'oncle Bob vidéo, c'est pour le Web (Rails) en général et pour le Rubis en particulier. Donc il y aura des besoins de contrôleur dédié pour gérer certaines Affichage et de Navigation spécifique de comportement.
Plus qu'une question, quand vous dites "Présentateur/ne devrait pas interagir avec plus que sur l'Interacteur.", que dois-je faire lorsque 2 cas d'utilisation sont liées à la même présentateur/view? Par exemple, j'ai un présentateur/vue qui doit vérifier si l'utilisateur est connecté et a également pour demander l'emplacement de l'utilisateur l'autorisation avant de faire quelque chose d'autre.
Pour la question 3: j'ai besoin de certaines choses pour être asynchrone, car la connexion, par exemple, est un facebook login, j'ai donc besoin d'attendre pour l'utiliser pour le retour de l'facebook app.
OriginalL'auteur bhavik shah
Question: Que faire quand 2 cas d'utilisation sont liées à la même présentateur/view? Par exemple, j'ai un présentateur/afficher que
Réponse
Cas D'Utilisation De La Modélisation
Il semble que vous êtes face à non négligeable de cas d'utilisation de scénarios de modélisation.
"Vérification de l'utilisateur de connexion" n'a pas besoin de cas d'utilisation. De même, si l'emplacement de l'autorisation n'est pas mis à jour dans le cadre des paramètres de configuration, puis c'est pas non plus un cas d'utilisation. Ils ne sont pas de bons candidats pour le cas d'utilisation de la modélisation, mais plutôt les conditions préalables ou les "étapes" dans d'autres complexes de cas d'utilisation. Je pense qu'ils sont plus comme des conditions préalables puis "étapes" et certainement pas un individu "cas d'utilisation" eux-mêmes.
Conditions préalables doivent être accompagnés par des cas d'utilisation des exceptions et non-trivial "étapes" des relents de cas d'utilisation et de réutilisation via incluent des dépendances. Si les conditions préalables ne parvient pas, vous pouvez fournir des messages et des options pour remplir ces conditions. Pour les étapes complexes, un cas d'utilisation rediriger vers d'autres cas d'utilisation.
L'idée est d'opter pour les exceptions qui va mettre fin à l'utilisation de cas valides le message sur l'échec de conditions préalables OU inclure d'autres cas d'utilisation qui va demander à l'utilisateur d'ouvrir une session dans la première et la reprise actuelle de cas d'utilisation.
L'objectif est de briser les exigences complexes et à les réutiliser. Citant Cas D'Utilisation, De Réutilisation Inclure La Dépendance. "Vous utilisez inclure les dépendances à chaque fois qu'un cas d'utilisation, les besoins le comportement de l'autre. L'introduction d'un nouveau cas d'utilisation qui encapsule la logique similaire qui se produit dans plusieurs cas d'utilisation est tout à fait commun."
Dans VIPÈRE Façon
Ainsi,
CreatePlaceInteractor
devrait prendre dépendance surUserLogInInteractor
etLocationAuthorizationInteractor
et de les appeler si nécessaire.CreatePlaceInteractor
doit renvoyer les données que le Présentateur peut interpréter et demander fil de fer pour lancerUserLoginPresenter
et/ouLocationAuthorizationPresenter
.Cela impliquera soigneusement conçu des interactions et la navigation pour le contrôle de flux et de flux de données en utilisant des Interacteurs, les Présentateurs et les Wireframes. Dans le processus, il vous sera difficile, beaucoup d'hypothèses fondamentales et caché non gérée comportement du système.
Depuis d'autres cas d'utilisation peut également inclure l'utilisateur de connexion ou de l'autorisation d'accès pour terminer leur tâche, ces actions devraient être inclus, mais pas nécessairement exécuté tout le temps, à la condition de l'appel de fonction à UserLogInInteractor et LocationAuthorizationInteractor. Si l'utilisateur est connecté et l'autorisation d'accès est déjà autorisés, ils seront ignorés. Lorsque l'utilisateur choisit CameraView, vérifier pour l'utilisateur de connexion et d'accès aux données de localisation. Lorsque l'utilisateur choisit EditView directement à partir de MapView, vérifier pour l'utilisateur de connexion.
Je pense que vous devriez mettre en œuvre condition logique dans votre Interacteurs et Présentateur peut l'utiliser pour faire des Présentations et des Navigations des décisions connexes.
Considérant, voici une liste de Cas d'Utilisation:
UC004: Créer un Endroit sur la Carte (Avec Conditions)
Conditions préalables:
Suit:
UC004-E1: l'Utilisateur n'est PAS connecté ou session a expiré
Suit:
[utilisateur peut choisir de revenir à la vue de carte ou aller à l'écran d'ouverture de session]
UC004-E2: Accès à la Localisation n'a PAS été autorisé.
Suit:
[utilisateur peut choisir de revenir à la vue de carte ou aller dans les paramètres options]
UC004: Créer un Endroit sur la Carte (Sans conditions Préalables)
Suit:
UC004 > UC001: l'Utilisateur n'est PAS connecté ou session a expiré
Suit:
UC004 > UC002: Accès à la Localisation n'a PAS été autorisé
Suit:
Dois-je créer un seul cas d'utilisation (interacteur) pour afficher, de modifier et de créer?
bhavik, pourriez-vous m'aider avec cette dernière question? Juste pour être plus clair, est un autre exemple: mon MapViewController a un bouton que lorsque vous appuyez sur le suivi de l'emplacement de l'utilisateur et le MapViewController affiche également des broches pour les places récupérées à partir du serveur. Dans ce cas, j'ai pensé à 2 interacteurs, PlacesInteractor et CurrentLocationInteractor. Le PlacesInteractor récupère les lieux et les CurrentLocationInteractor est responsable de la demande de l'utilisateur de l'emplacement de l'autorisation et obtenir le plus de mise à jour des coordonnées. Alors que dois-je faire pour l'avoir au plus un interacteur pour chaque présentateur/view?
Bonjour Rodrigo, des excuses pour ne pas répondre plus tôt. Cependant, pendant le temps que j'ai moi-même été confronté à certains problèmes de conception et de je suis venu avec l'idée de la division des différentes parties de l'application, entre les Front-End-les Participants et les Participants. Il m'encourage à penser clairement. Juste pensé à partager avec vous, même si je suis encore en train d'essayer d'exploiter cette idée plus loin où il fait sens. Voir ma réponse à vos questions ci-dessous.
OriginalL'auteur bhavik shah
Cas d'utilisation de la Modélisation et de la VIPÈRE des considérations de Conception pour Créer, Modifier et Afficher "Un Lieu sur la Carte" pour un iOS en fonction de l'application mobile
Vos questions
Que faire si - Créer, Modifier et Afficher les actions finir dans le même ViewController?
Est-ce une bonne idée si MapViewController utilise PlacesInteractor pour récupérer les lieux et les CurrentLocationInteractor pour demander à l'utilisateur l'emplacement d'autorisation et obtenir le plus de mise à jour des coordonnées?
Il n'est pas un problème pour combiner la logique en un seul Interacteur. Mais il ne sera pas plus être un "Interacteur". Il va devenir un "service" ou "manager" dans MapPlaceManager/MapPlaceService qui ont des méthodes telles que:
Je pense que l'idée était seulement à exposer le but Api par cas d'utilisation et donc Interacteur - qui peut dire ce que l'utilisateur de l'Interacteur va faire avec elle. Si elle a de multiples Api qui peut faire des choses différentes, par exemple, créer/modifier/supprimer la carte des lieux, puis nous devons vérifier les appels de méthode en l'appelant pour savoir ce que l'appelant va faire. Les interacteurs dans ce sens, pour moi, ce sont de très haut niveau - business/exigences niveau des interfaces. Vous pouvez cacher vos services de back-end et les gestionnaires à l'intérieur de chacun de ces Interacteurs.
Vous pouvez profiter de cette notion dans la mesure du possible et/ou faisable, Possible de plutôt possible. Il y aura une extrême où tracer la ligne, au lieu de suivre trop religieusement. Systèmes d'entreprise ont tendance à être plus formel et méthodique pour vous donner un exemple.
Dans votre cas, lorsqu'un bouton est pressé sur votre écran principal qui change votre
MapPlaceView
enMapPlaceEditView
, vous changez les cas d'utilisation que le nouveau point de vue va à satisfaire. En place les changements de vue sont appropriées en vue des considérations de conception pour mobile et il est également à une utilisation conviviale. Cependant, souvent, il encourage complexe de GUI et de désordre présentateur de la logique. Si c'est gérable, plus propre et plus facile pour votre ViewController/Présentateur de switch "modes" entre "Créer, Visualiser, Modifier" - vous êtes bon pour aller. Il n'est pas parfait, mais il n'est pas faux. Ils sont à l'Avant-End les Participants et ont le niveau le plus élevé de la liberté et de la fréquence des changements de toute façon.Une autre bonne conception de l'INTERFACE utilisateur, j'ai trouvé utile au lieu de champs de lieu d'édition, est "retournement" de la vue ou de l'un quelconque de ces points de vue effet de transition. Vous pouvez avoir un
MainMapPlacePresenter/ViewController
et il dispose de 3 sous-points de vue - pour Créer, Modifier et Afficher. De ce point de vue est alors responsable de la commutation entre ces trois points de vue. Il permet une navigation, nettoyeur de cas d'utilisation, de mise en œuvre et de conception soignée.De même pour
CurrentLocationInteractor
, il fait deux choses - 1. demander l'autorisation d'utiliser de dispositif "service de localisation" et 2. utilisation de périphériques "service de localisation". Maintenant, il semble qu'il n'est pas un Interacteur. C'est Avant la Fin de la fonctionnalité. Mais vous pouvez utiliserSaveAuthorizationInteractor
pour enregistrer les choix de l'utilisateur. Mais c'est autre chose. Plus je pense à ce, les Interacteurs sont responsables pour des choses qui traitent de votre système et non pas avec votre utilisateur.Présentateur n'tous d'utilisateur "parler" et "prise de décision" travail -, ils peuvent utiliser l'Api de périphérique si ils ont besoin par exemple le Service de Localisation. Vous pouvez créer des interface abstraite
ILocationService
et l'enveloppe de la mise en œuvre appeléeLocationService
qui va absorber de l'utilisateur de l'emplacement de l'appareil de service - un faible niveau de mise en œuvre de la plate-forme et des détails précis.Dans la mise en œuvre modalités:
Vous pouvez avoir:
Et comme pour le service de localisation, vous pensez que c'est ok pour le présentateur d'avoir un CLLocationManager alors?
Je pense que l'animateur doit utiliser CLLocationManager. Il est fourni par la plate-forme iOS et il n'est pas directement encapsulé par votre application. Cependant, comme je l'ai mentionné avant, vous pouvez l'envelopper par l'intermédiaire d'un régisseur d'interface si vous souhaitez isoler votre animateur de la mise en œuvre de la dépendance sur CLLocationManager - ce qui est une bonne idée.
À mon avis, un bien-conçu logiciel ne ont tendance à être de plus en plus fine et maigre. Cela signifie très petites classes avec quelques champs et méthodes. Si fait correctement, vous aurez des tonnes de classes, oui! J'ai beaucoup de classes dans mes projets. Même les filtres sont classes par exemple avec LocationFilterCritera champ (peut être enum) et ainsi de suite. Dans mes projets, j'utilise de tels objets du filtre. Vous pouvez ajouter d'autres critères de votre filtre d'objet ou de créer de nouvelles classes de filtre - là en ne changeant pas l'ancien code. Comme pour les Interacteurs avec juste un couple de méthodes - eh bien, si elle rend tout à fait clair, il vaut la peine!
Lieux avec des Critères de Filtre devrait faire partie d'un point de vue. Son présentateur aura un Interacteur qui extrait filtré des sites en fonction des critères prévus à l'Interacteur. ------- En passant, je ne dis pas qu'il est obligatoire de créer par cas d'utilisation interacteurs - vous devez trouver un équilibre entre le niveau de verbosité, la granularité, de la redondance et de la quantité de travail concernant le gain devrait vous choisir très maigre Interacteurs. J'ai vu des cadres et des architectures qui favorise de telles idées et ils offrent une grande flexibilité lorsque vous utilisez de tels cadres, en raison de leur concentré de classes. Qu'en pensez-vous?
OriginalL'auteur bhavik shah
Il semble que les deux cas d'utilisation semblent identiques, les résultats de fin c'est "Créer un Lieu avec /sans image" à deux voies "Avec la Caméra et le Service de Localisation" vs "la Saisie Manuelle des Données".
"Avec une Caméra et des Services de Localisation de cas d'utilisation" ajoute photo.
Cependant, je me demande si les deux façons d'atteindre le même résultat ou un résultat identique est considéré comme l'unique cas d'utilisation.
Je voudrais concevoir les deux que l'utilisation séparée des cas, si je peux, sinon je voudrais faire un primaire ou un défaut d'utilisation et d'autres approche comme une alternative pour obtenir le même /le même résultat final.
Cas D'Utilisation: Créer Place
Flux de base: Utilisation de la Caméra et le Service de Localisation
Utilisateur appuie sur le bouton plus.
Application affiche une vue de la caméra.
Utilisateur prend une photo.
Application crée lieu avec emplacement actuel "et l'image".
Suppléant flux A: Utilisation de la saisie manuelle des données
A. 1. Utilisateur “appui long” sur la carte.
A. 2. Application des gouttes d'un nip temporaire et l'affiche de l'édition à la vue.
A. 3. Utilisateur modifie la place de l'information et appuie sur le bouton enregistrer.
A. 4. Application crée le lieu "sans image" et de l'enregistrer.
Cela fait-il sens?
Mises à jour avec les détails spécifiques
La-Vue-Contrôleur responsable de traiter avec Vue dans iOS, est en fait traitée comme Vue dans la VIPÈRE. Voir la "Vue" de l'alinéa. Un UIViewController, ou un de ses sous-classes, de mettre en place le protocole de Vue. Par conséquent, ce contrôleur est votre point de Vue.
L'idée est que vous devez isoler votre animateur de la connaissance de l'iOS Afficher ou iOS contrôleur. Il devrait traiter avec iOS spécifiques vue et contrôleur via la plaine des structures de données comme les ViewModels. Si vous pouvez faire cela, vous avez réussi à isoler le Présentateur du SDK iOS dépendances spécifiques et vous pouvez écrire et d'exécuter des tests Unitaires, TDD ou directement sur vos Présentateurs, si vous le souhaitez.
Cependant, le plus intéressant une fois que vous réussir à isoler le Présentateur de la Vue et ViewController, vous pouvez isoler Interacteur à partir de Presenter facilement. Présentateur devra transmettre les données dans le formulaire qui est acceptable pour l'Interacteur. Donc Interacteur ne sais rien à propos de l'animateur. Il est indépendant et vous pouvez cet Interacteur (cas d'Utilisation) en ligne de commande, web ou de bureau-GUI application aussi facilement.
Je pense qu'il devrait être un Interacteur par cas d'utilisation. Si il y a d'autres flux le cas d'utilisation, l'interacteur aura méthodes avec ces autres structures de données.
Dans votre cas, la CreatePlaceInteractor aura deux méthodes:
Il y aura trois View/Présentateurs:
CreatePlaceChoicePresenter/Vue de capturer le choix de l'utilisateur et envoyer la demande à la NavigationController ou de fil de fer comme appropriés qui sera de retour nouveau Présentateur/Afficher selon le choix de l'utilisateur.
CreatePlaceWithManualDataEntryPresenter/Vue de créer et de convertir
CreatePlaceWithManualDataEntry ViewModel en
CreatePlaceWithManualDataEntry Demande et recevra
CreatePlaceWithManualDataEntry Résultat et processus en conséquence pour afficher les cas d'utilisation résultat sur l'affichage.
CreatePlaceWithCameraAndLocationservicepresenter/Vue de créer et de convertir CreatePlaceWithCameraAndLocationservice ViewModel en
CreatePlaceWithCameraAndLocationservice Demande et recevra
createPlaceWithCameraAndLocationservice Résultat et processus en conséquence pour afficher les cas d'utilisation résultat sur l'affichage.
Excuses pour le détaillé sur demande, resonse, viewmodel et noms de méthode.
Si "Interacteur" est une partie de votre VIPER conception, tel que décrit dans la VIPER Introduction, vous devriez probablement aller avec deux Interacteurs. La raison en est simple Interacteur traite Présentateur unique et la Vue, et dans votre cas, vous aurez deux différents présentateur/vue pour deux types de flux.
Je vais d'ailleurs avoir plus d'un présentateur/afficher pour chaque Cas d'Utilisation, semblable à un formulaire à étapes multiples sur le web (dans mon cas, l'affichage de la carte, la vue de la caméra et l'affichage d'édition). Dois-je utiliser 1 interacteur avec 2 présentateurs pour chaque Cas d'Utilisation?
Aussi, que de VIPÈRE lien, il ne montre qu'un Présentateur, ne devrais-je pas aussi une manette? Le Contrôleur responsable de la réception des avis de la vue et le Présentateur en charge de présenter le point de vue?
Je n'ai regarder la vidéo de la nuit dernière. Très bonne vidéo et merci pour le partage. Voir ma mise à jour de la réponse ci-dessus.
OriginalL'auteur bhavik shah