Architectural Design - Group22-MobileApp/Grupo22-Moviles GitHub Wiki

Architectural Design

Flutter Aplication:

For our flutter aplication we decided to use an Architectural Pattern MVVM because it was the recommended pattern for an android aplication. The MVVM is composed of the following components:

  • View: Represents the UI of the application. In flutter, the view is represented by the widgets and the elements. In flutter,the widgets are the building blocks of the UI, are a set of instructions that describe how to render the UI (Napolli, 2020). On the other hand, the elements are the actual visual elements that are rendered on the screen. This elements are created based on the instructions given by the widgets.

  • ViewModel: Is an intermediary between the view and the model. It contains a representation of the logic and also manages the state of the application. In flutter the viewmodel is represented by the different classes that are created to manage the state of the application. For example, widgets can be Stateful or Stateless. The Stateful widgets are used when the state of the application changes dynamically, while the Stateless widgets are used when the state of the application does not change.

  • Model: Represents the data and the business logic of the application. In flutter, the model is represented by the different classes that are created to manage the data of the application. Also, in our case, we used Firebase as an external service that provides data and other logic services to the application.

Bibliography: Napoli, Marco L. 2020. BEGINNING Flutter® A HANDS ON GUIDE TO APP DEVELOPMENT. ISBN: 978-1-119-55082-2

Kotlin Aplication:

Blank diagram (2)

Design patterns use in Kotlin

Provider Pattern

The Provider pattern is a design pattern that facilitates data and state sharing among different components of an application1. This pattern centralizes data and functionality, reducing code repetition and easing maintenance of the application.

Repository Pattern

The Repository pattern is a software design pattern that acts as an intermediary layer between an application’s business logic and data storage. Its primary purpose is to provide a structured and standardized way to access, manage, and manipulate data while abstracting the underlying details of data storage technologies. This pattern promotes a clear separation of concerns, making software more maintainable, testable, and adaptable to changes in data sources, without entangling the core application logic with data access intricacies.

Singleton Pattern

The Singleton pattern ensures that there is only one instance of a class and provides a global point of access to it. This pattern is useful when we want a single instance of an object in the application.

Observer Pattern

The Observer Pattern defines a one-to-many dependency relationship between objects so that when one object changes its state, all its dependents are notified and updated automatically. This pattern allows decoupling between the subject object and its observers, ensuring that observers are notified of changes and enabling maintainability and extensibility.

Builder Pattern

The Builder pattern is used to construct complex objects step by step. It allows us to create different variations of an object using the same construction process. The Builder pattern separates the construction logic from the main class, providing a flexible way to create and modify complex objects.