iOS VIPER - Should a custom alert (similar to UIAlertView) be a different module?

Question

I have a module, e.g module A, and after doing some work and clicking on a button of viewControllerA, I should receive a custom "alert" that the request I tried was successful. The "alert" should have a close button, to let the user close the view and get back to the viewControllerA.

So, I think there are two possibilities:

1) Just create the UIView with its UILabels tied with constraints and a UIButton and show it while hiding the current container view that contains most of the subviews.

2) Create a module for the result called and navigate between viewControllerA's view and the alert view by wireframes (routers).

So, here is my doubt. It seems like by the guidelines of VIPER I should use (2) and create a module so that the navigation is controlled by the wireframe, but the alert view is only composed of some labels and one button. There is no data to manipulate here. Therefore, the interactor would be useless in the ResultModule.

Should I then just show the alert view by alertView.alpha = 1 while containerView.alpha = 0 and reverse this when the close button on alert view is clicked or should I go all VIPER, creating a new module?

Answer 1

I am going to politely ignore OP's usage of module as a vertical slicing to focus on the V I P E R zones of VIPER. The reasoning about OP's question/topic is zone-based, not based vertical slicing within each zone. (Yes, I know that there exist different viewpoints on how VIPER is taught/presented in recent years, but I will utilize this https://theswiftdev.com/the-ultimate-viper-architecture-tutorial original purer definition of VIPER, which is less module-centric and more architectural-subsystem-centric.)

• While active, the modal dialog would prevent the router zone from navigating to a different scene/view. Hence, if view zone as a private matter pops up a modal dialog of any kind for any purpose, that blinds router from doing its navigation job based on, say, incoming events from an interactor or some other nonUI-originated state change in the app. The router zone should never be blinded by another zone why it cannot perform its navigation mission. Furthermore, view zone as a purely UI matter did not make the decision display the alert; either the underlying OS or the presenter zone is enforcing a restrictive rule of some sort, which means that view zone is not acting on its own volition but rather is merely a puppet of some other puppeteer.
• Whatever is the topic of the alert, it almost certainly affects the app-domain layer somewhere among all of the I P R zones (perhaps expressed in by data in the E zone flowing among I P and/or R). To keep the rule violation that caused the alert as a private matter within view zone, the app-domain awareness of the rule violation is kept blind (or it is communicated via less-than-stellar near-violations of VIPER). Hence, the rule violation that caused the alert must be made known to, say, presenter zone because that rule violation might trigger a different set of rule-enforcement behaviors in the app domain, as presenter zone is realizes in effect “Oh, we're in that situation. Well that means we need to go this instead until that subsides.” This different app-domain behavior while in this condition might cause presenter zone to perform interzone behaviors with, say, router's scene navigations and interactor's datastore retrievals/storing to behave differently. Therefore the rule violation that caused the alert almost certainly has an app-domain aspect as well as whatever Apple thought was UI-to-UI matters in the pre-VIPER era (and somewhat similar pre-MVVM-C era where MVVM-C's C = VIPER's R).

When pondering a topic as in OP, three thought processes help structure one's thoughts:

1. What if the design was changed to not pop up a modal dialog box, but rather to show the alert in some nonmodal view (pane) among other views concurrently/nonmodally active? Then this really really has full-fledged impact on interzone app-domain-representation of app-domain data/concepts among the V I P R zones. VIPER (as effectively within the Clean architecture school of thought) is all about keeping matters quarantined so that x in isolation can by substituted by y without changing any non-x and non-y portions of the other zones.
2. What if the app were ported to MacOS or even to Android? All the app-domain interzone messaging/concepts should not change one iota just because the UI in view zone got swapped out and the navigation in router zone got modified some and thus swapped out too. If Apple-think is anywhere in the pure-app-domain interzone messaging/data/concepts, then VIPER was insufficiently present in the app between zones. This usually means that UI quarantining in view zone has some form of façade that communicates purely app-domain data/messaging/concepts to the other zones, perhaps in the view-models or perhaps as an actual façade layer as per local taste.
3. What if the other zones were blind to anything related what view zone (unwisely) thought was a UI-to-UI short-cut? Does that blindness in other zones cause malfunction, bug, or lack of useful feature? If so, then that UI-to-UI short-cut that lacked interzone messaging of purely-app-domain data/concepts starved one or more other I P R zones of some app-domain-centric (instead of UI-internal-matters-centric) information flow interzone.