Architecture overview

Introduction

NavidaPro is designed around a modular architecture with a base app and a series of plug-and-play plugins. This structure promotes scalability, maintainability, and flexibility. Each plugin is built using an open contract, ensuring consistent integration and interaction across the application. The development adheres to the MVVM (Model-View-ViewModel) architectural pattern, facilitating clear separation of concerns and efficient data binding.The Navida Pro framework, with its modular design and industry-best practices, enables organizations to build and deploy complex applications that can evolve to meet changing business needs.

Base App

This Base App will be the foundation for the Bundle that is later shipped to the App- and Play-Store.

It links the plugins dynamically and has hardcoded links to the open Contract and the navida specific plugin.

Since the Base App is build and shipped in the end, it should also hold the information about used Backend URLs, AppName, AppIcon and many more based on the Flavor and schema selected for the build

Open Contract

The open contract defines the interface and dependencies for each plugin. It ensures that all plugins adhere to a standard structure and can interact seamlessly with the base app and other plugins. The contract mainly includes UIComponent, Modules and the common utils which every plugin would consume. This ensures that every plugin has a uniform look and behaviour. Every component created has to undergo snapshot testing and all the module related code are unit tested to make sure everything works correctly

Plugins

Plugin is built on top of the open contract and would consume the UI components and modules. Each plugin is designed to encapsulate specific business logic and network operations, which allows for independent development, maintenance, and updates. This modular approach reduces complexity and increases the system's agility.The adherence to the MVVM pattern across all plugins ensures that the UI, viewmodel, and model within each plugin can interact seamlessly. This standardization supports easier testing and contributes to the robustness of the application infrastructure. The content and the localisation of the plugin comes from the CMS and this would help to give dynamic content for the application. If we want to support a new language, its a matter of adding new localisation. Also platform is designed in such a way that a new AOK can be added without much trouble by leveraging the power of CMS

MVVM (Model-View-ViewModel)

MVVM is an architectural pattern that separates an application into three main components:

Model

Represents the data and business logic of the application. It encapsulates the data model and operations related to data manipulation, retrieval from APIs, and local storage.

View

The UI layer that displays data to the user and captures user interactions. It is responsible for the presentation of data and user interface elements.

ViewModel

Acts as a mediator between the View and the Model. It exposes data and commands required by the View and handles user interactions. ViewModel doesn't have direct references to the View but uses data binding to communicate changes. This separation promotes reusability, testability, and maintainability by keeping business logic separate from UI logic.

MVVM architecture encourages a clear separation of concerns, making it easier to maintain and test each component independently. It also facilitates better collaboration between UI designers and developers by defining clear boundaries between presentation and business logic layers.

Please refer this guide to read more about our MVVM style this

How it all connects together

To bundle the App, we have to connect multiple dependencies like the open contract and plugins. Base app will have dependencies added for all these and build would be generated based on the plugin dependencies which are added. For more details how the base app is envisioned please refer this

Architecture