objcio / issue-13-viper Goto Github PK

just saw these two lines code in the method (presentListInterfaceFromWindow:) of file VTDListWireframe.m and wondering will it cause the reference cycle problem ?

    listViewController.eventHandler = self.listPresenter;
    self.listPresenter.userInterface = listViewController;

Here's a few of things I am having a hard time figuring out using VIPER architecture:

If I have an entity that is just a data structure, and I have a presenter which is responsible for formatting data, why would I not want to pass the entity from interactor to presenter? I find myself unnecessarily creating two separate data structures (one on the interactor/entity side and one on the presenter side) which the interactor does a 1 to 1 mapping on. Is this correct?

How does data get passed from one module to the next? Let's say I have a module that lists categories and a module that lists items in a category. When a user selects a category, that selections needs to be passed from the category module to the item module so that the item module interactor knows which category to retrieve. Data should be owned by the interactors, yet the transition between modules happens at the presenter/wireframe level. It seems I am stuck passing data from one interactor to another through their respective presenters/wireframes which results in a lot of unnecessary code and seems to violate the single responsibility of the presenter only presenting data to a view and a wireframe just transitioning between views. Should the interactors in different modules know about each other? What's the best way to pass data between modules?

Related to last question. How should wireframes interact with the rest of the module? Should wireframes know about interactors? If so, this would seem to make the passing of information easier between them. Should wireframes be responsible for instantiating their entire module? In the VIPER ToDo list, most all of the instantiation and configuration happens in a separate class called AppDependencies and the wireframes don't seem to know at all about interactors. In a much larger app with many more modules, I imagine AppDependencies becoming a bit of a nightmare as well as the issue of instantiating a lot of objects well before you need them.

Thanks!

When you cancel the Add Todo, the screen becomes blank (black).
There's also a weird navigation bar strange artifact (movement) when triggering the Add Todo button.

I really like what this (and other similar) architecture offers but I’m wondering about the reusability of the views and the role of the view controllers.
In the majority of the occasions I create custom views and then compose them all in the viewController creating the screen that I want.
I would like to see how this is approached in this architecture since I see that the VC/Views are really tied and only can represent one screen.
For example how you would handle if we want to use the “Add” view in another place? For example if we want to use the add as a view on top of the table.
Thank you!

very big issue of course ;)

Even though this project seems to be abandonware, there aren't any better forums for discussing VIPER, so I hope there's someone actually implementing it IRL. (i'm gonna ask on StackOverflow as well).

Every example of VIPER I have found only provides a contrived example of communicating from module to module. The TODO app opens a blank Add screen. No information is needed from the previous (list) screen. That's the most simple (and contrived) example possible. But in reality there are lots of situations where you need to pass info from screen to screen.

For example, lets say we wanted to extend the TODO app to allow editing of todo items. In order to edit, you need to pass some info to the edit screen (module). Because communication happens between modules via wireframes, would I modify the VTDListWireframe so that the VTDListPresenter can call something like this:

// I'm passing the todo string here which will be used by the edit module to load the todo item for presenting on the edit screen
- (void)presentEditInterfaceWithToDo:(NSString*)todo
{
    [self.editWireframe presentEditInterfaceFromViewController:self.listViewController withTodo:todo];
}

Notice how my wireframe is now taking todo string. Is this in keeping with the VIPER pattern, or am I violating the boundaries between presenter and wireframe? Is there another way I should be communicating this to the next wireframe?

I have a problem dealing with the return of some info from a module that had been presented by another module. In my case I have two modules, Map and Search. The MapView notifies that it wants to search an address, so the MapPresenter begins the actions to show the Search module. Inside the Search module I make a text search, obtain the results, show it and select one. That selection has to be returned to the Map module. How can I achieve that?

Taking into account, and please correct me if I'm wrong, that the communication inter-module has to be achieved only via routing (not jumping between modules with notifications, closures and so on), I implemented this scenario:

(Sorry, maybe a sequence diagram would be better)

MapWireframe implements the regular interface but also another one I called MapModuleInput, so I pass to the SearchWireframe a MapWireframe implementing that interface when I begin the search action (blue).

After that, in the red flow, in the SearchView I begin the search case, it obtains the results from the interactor, etc. After that the results are presented and the user selects one (green), so the selected result is returned to the map via the MapModuleInput interface.

So, is that correct?

Thank you!

Hi,

This architecture is intriguing to me and I'm itching to give it a try on my next project, but has anyone used this [successfully] on large[r] scale apps -- not just example TODO list type things?

Thanks!

After adding todo task screen becomes black

iOS 9.3 iPhone 6s

Where does UITabBar fits in VIPER architecture?

If you delete VTDAddPresentationTransition.m line 59, the issue goes away