To reduce the amount of spam from vendors, we decided to create cells in the feed. We called these cells booths. Each user has their own booth that contains multiple photos, each featuring a separate look. Those photos can be swiped through instead of appearing one by one in a user’s feed. This makes the feed look neat, saving users from spammers who post looks hourly.
To implement purchasing functionality, we chose the CCAvenue Payment system that enables payment management and safe purchasing. We also added a second payment method via the their delivery system which enabled COD. Just like for the delivery system, we created a mechanism for payment data processing that helps to define the optimal payment method.
We divided the app into logical flows. This way we could construct a big application from smaller flows with the ability to freely reuse, include, exclude, and change the order of flows in the application. We called these logical flows modules.
A module is responsible for routing and can handle a flow’s common logic. Each module contains a list of screens (or a single screen). A module creates, removes, configures, and orders screens. A module can also create, remove, and present other modules. This means that the architecture has a tree- based structure, which simplifies understanding and orientation throughout the application.
For screens and views in modules, we used the Model–View–ViewModel (MVVM) architectural pattern, which helped us reuse the same views and screens with different content and logic.
Here you can see a diagram of Screen architecture (MVVM):