One of the most common projects in IT is the optimization of the local storage of an app. The optimization process includes various aspects. You can just substitute the libraries or change the whole architecture of an app. We’ll show how you can increase the performance of an e-commerce app by optimizing its local storage.
The order. The order was to analyze the architecture of his e-commerce app and optimize it. The app helps sales managers of a big store to interact faster and better with users. This e-commerce app allows viewing available goods in the store, add items to the cart, and place orders. The task was to increase the performance of the app and advance the efficient work of employers.
For that purpose, we divided the workflow of the developers into 4 steps.
1) Analyzed the app architecture, key UX design mistakes.
2) Defined ways to organize the database;
3) Analyzed the app functioning;
4) Optimized app.
Architecture analysis
First, it was defined that the information in the app is dynamic (renewable). The interaction with the server of implemented to get the required info. User authorization is processed via the third-party local app of the client.
If a user needs goods listing, it’s possible to use a variable app filter system. Filters update automatically via the server by the parameters of a user’s request. The data comes in reply in JSON format, it’s processed and stored. Per-page data output is done after that providing the opportunity to change goods lists.
If a consultant should register a user in the app to place an order or see the bonuses, the server data exchange is used.
Problems in the development
We found out that there were some problems during the development process. It was difficult to implement certain design elements. This fact leads to bad usability and difficulties in expanding functional features. For example, the app was planned to have its own database to receive data from the server. But later our specialists learned that consultants often closed the app, the cache was cleared and they had to wait for a long time for new big data. In other cases, sellers used the app too long, but the temporary cache was also cleared and the users had to wait anyway.
Despite this, the development process was often delayed because of the design changes that were done right in the process. Usually, this positively affects the product, but not the development process. Changing one feature leads to changing another and that postpones the release date.
One more drawback is the absence of testing. It’s highly recommended to use tests to see whether the app shows expected behavior.
App structure
As we mentioned above, the data was planned to be stored at the server, because they update quite often to store them locally on the device. The MVC architecture perfectly fits those conditions. The data updated automatically, data management and storage weren’t needed. Besides, they didn’t need the interaction of the controllers, as the number of screens was limited and the transition between them was coherent.
But the structure of the app was growing, and new features appeared. New tabs were implemented as well, and that scaled up the volume of transitions and interaction between the components. It was required not only to provide a coherent transition between the controllers but also to offer the ability to return the app to previous conditions and interact with certain tabs. The basic app architecture didn’t cope with that anymore. That’s why we decided to add a local base to increase the performance of the app.
How to organize a local database in a mobile app
Most mobile applications show users the information that is stored remotely at the server. This process is possible due to the API. API existed for our project too, but the data was big and stored at several servers. To receive this data the synchronization mechanism was added, that gathered various inquiries groups. This mechanism was fulfilled by dictionaries.
Dictionaries store links to different servers and the info needed for sending requests. They update with every new launch of the app. Every new request needs the info about one of the servers in the dictionaries. Accordingly, the app stores the dictionaries locally and doesn’t send requests every time.
We implemented several dictionaries, but there was still a problem of the complete absence of the info if the app lost the connection.
We decided to use request caching. Every item request is unique, and there are a variety of possible filters to depict the info about goods. It makes it rather difficult to predict what info should be requested. For that purpose we used NSCache. It’s quite simple in implementation and doesn’t require any additional settings.
Then the app requires more space to store more data. At that very moment, the caching was changed to a local database. These databases can store big data and they are not cleared in the app memory and don’t require many requests. There are 2 the most popular local bases: Core Data and Realm. We decided to choose Realm. It’s easier to implement, has a laconic record, provides encryption support and data synchronization, and possesses high work speed at relatively small data volume.
Choosing architecture
We were looking for architecture that could provide the ability to work with the local base and save the key features. For example, use of Swinject (light framework for dependency injection in Swift; Clean architecture for implementation). To find the best variant among MVC, MVP, MVVM-C, and Viper, we made a paired comparison according to their criteria. It was found out that the best way was to use MVVM-C architecture. It’s simple in supporting and implementing. Additional modification of the coordinator allows solving the routing problem of the user navigation between the screens.
Optimization
The Realm architecture supports the migration system that allows users to update the database in case of change. Because of that, you should signify its version every time when you create a configuration. All changes of the Realm database are processed inside the write transaction, so we created the block that simplifies the record of data in the base conducting all required tests.
To record the data into Realm the object should be a descendant of a basic Object and possess the field primaryKey. A basic class that created this field was created for objects that originally don’t possess it.
The local storage let significantly reduces the time of the program launching. Now it accounts for approximately 5 seconds instead of 12. It also lets get rid of reloading of previously downloaded data during the app work. This all increased the performance of the e-commerce app.
As a result, our team managed to fulfill all the client’s requirements and significantly improve the performance of the e-commerce app. A separate aspect for improvement is ensuring the security of the application. We have written a special guide about this, where we described in detail all the optimization steps. And if you have a project idea, write to us and we will discuss with you all the details of the project!
