Hello, Habr! I, Alexey , am a leading developer in the Alfa-Business Mobile platform team. In this article we will talk about the Alfa-Business application and one of the architectural problems that any medium/large project faces, we will consider several ways in which such problems can be solved, and we will tell you why we chose to share the presentation layer. A bit of context. Alpha-Business Mobile is a classic multi-module Android project. We have a main module app — this is a mediator module that knows about all other modules of the project.
Its main task is to collect the entire dependency graph and provide them to other modules of the project. We also have base modules, which off page seo service contain common utilities, and base classes that may be needed in any module of the project. For example, this could be code that is needed to work with the network, or base classes for mvi. For features, we create two modules, with the prefixes -api and -impl with the interface and implementation of the feature. On the diagram, it will look like this: Standard cases with modules are solved simply For example, when we need to launch feature2 from feature1,
feature2 can have several screens inside, then: We create a mediator that launches a new navigation flow. The mediator interface is located in the -api module. Feature1 can start Feature2FragmentFlow by calling the startFlow method. Feature2FragmentFlow, in our case, hosts all fragments of feature2. Further, all switching occurs inside the -impl module of the feature launched via Feature2Navigator. But what to do when the case is non-standard? Let's say we have a screen for some complex feature. For example, let's look at a simplified version of the user profile screen.