Concept

Motivation

The primary objective of the framework is to ensure scalability of the project, providing high reusability of code hierarchies by decoupling them from each other. This can be especially beneficial for a large projects to support parallel development by different teams.

Solution

This is achieved by breaking the application logic up into separate independent parts called black-boxes. Each black-box has a simple and strictly defined interface that hides the implementation from external context. Each black-box can be seen as a sub-application that can be used separately from the context of the app.

The hierarchy of black boxes forms a tree-like structure of the entire application, where each black box performs a specific task and influences the application's state at a specific moment in time.

To maintain reusability the following rule must be followed: the parent black box is aware of the existence of the child black box, whereas child blackboxes know nothing about the parent and the caller context.

Any UI element can be represented as a black-box: views, screens, or a collection of screens organised into a navigation flow. These elements are defined declaratively as @Composable functions with the following interface:

💡 Blackbox : F(config, dependencies, io) → Composable

Such functions grouped by a specific domain forms a feature, which also follows the Blackbox principles. Every feature is a black-box that can be described by the aforementioned @Composable function. But in more complex scenarios, it can be represented as a factory class or a set of factory methods, producing different @Composables based on the Feature API.

Since a black-box is represented by a @Composable function, in addition to visual elements, every function may have Logic and State that are mapped to that elements.

Each function has its own Scope, which is tied to its lifecycle. This scope allows to define the dependency graph required for the function logic to operate. When the black-box is no longer active the Scope gets cleared automatically along with Dependency graph, resulting in proper memory management.

Components

1. View. An abstract user interface component, that may represent a screen or a part of it.
2. Scope. Lifecycle aware container that is used for creating, keeping and disposing black-box function DI graph.
3. Config. A set of parameters or arguments that are used to configure the black-box during initialisation.
4. Dependencies. A set of external dependencies that are used by black-box function to operate.
5. IO. Reactive Input/Output used for exchanging events between black-boxes.
6. NavigationFlow: A component used to describe declarative navigation between black boxes.
7. Coordinator. A component that encapsulates navigation logic by taking navigation details out of black-box functions, making them context-independent.
8. Feature