Architecture

The Android PoqSDK uses clean architecture with MVVM (Model-View-ViewModel) as presentation pattern. In clean architecture, your app is divided into 3 main layers: presentation, domain, and data layer. In the Android PoqSDK, the communication between layers happens with RxJava.

Domain layer

The domain layer is responsible for the business logic. It has 3 main actors: entities, interactors, and the repository interface.

Entities

Entities, or domain models, are the main model of your app and represent the feature you are creating. In the Android PoqSDK most of the entities are associated with a specific feature, as Cart or ProductDetail, but there are 2 entities that will be used across the whole app:

• CountryConfig: represents the current country selected. This entity holds information such as current country iso code, currency, and also the app identifier which represents your catalogue; most data layers will need it.
• User: represents the current user of your app; there is always a User (guest or logged in).

If you need both of them at the same time, you can get them via the Authentication model.

Interactors

Interactors, or use cases, are responsible for gather entities from other use cases and exposing repository methods as actions.

In the PoqSDK you can find interactors such as GetProductDetail, which will return ProductDetail entity. You also can find interactors such as ObserveCartItemsCount that returns an observable and allows you to be notified every time the cart count is changed.

Repository interface

The repository is the entry point to the data layer; its interface is in the domain layer.

Data layer

The data layer is responsible for the data: from getting it from the BE to storing it into a Database. Its main actors are API service, local storage, repository, and mappers.

API service

The API service is responsible for the interaction with the API (Retrofit interface). It will also convert the Retrofit response to PoqResult for better error handling. The API service exposes network models, whose names are created from the domain model name with the prefix Network-, for example, NetworkCart.

Local storage

The Local storage is responsible for storing the data, usually, via a Room DAO. The Local storage exposes storage models and their names are created from the domain model name with the prefix Storage-, for example, StorageUser.

Repository

The repository is responsible for encapsulating the logic to access the data sources. The repository communicates with the API service and/or the local storage to access the data and it will use the mappers to convert the models exposed from the data sources to the domain models.

Mappers

Mappers are responsible for mapping the different models. Mappers are usually implementations of Mapper<out, in> interface and its names are created with this pattern {InputModelLayer}To{OutputModelLayer}{DomainModelName}Mapper, for example, Mapper<Cart, NetworkCart> will be named NetworkToDomainCartMapper.

Presentation layer

As presentation pattern, the Android PoqSDK uses MVVM.

Each feature has at least one Activity which acts as entry point but it can have multiple Activities if the feature has multiple entry points. The Activities expose "Kotlin static" methods named getStartIntent with the parameters required to open the Activity.

Each feature will also have one Fragment and one main View per screen. It is this main View the one that communicates with the ViewModel and the one that you should replace when you need to customise a screen. The Android PoqSDK uses DataBinding and LiveData for the communication between the View and the ViewModel.

Names are created in this way:

• Activity: {FeatureName}Activity, for example, CartActivity.
• Fragment: {FeatureName}Fragment for the abstract class and Poq{FeatureName}Fragment for its implementation, for example, CartFragment and PoqCartFragment.
• Main Views: {FeatureName}View for the abstract class and Poq{FeatureName}View for its implementation, for example, CartView and PoqCartView.
• ViewModels: {FeatureName}ViewModel for the interface and Poq{FeatureName}ViewModel for its implementation, for example, CartViewModel and PoqCartViewModel.