GSoC 2023 with OpenMRS | Coding Week 06
Welcome back to my blog series documenting my journey through the Google Summer of Code program. This past week, I had the opportunity to contribute to the Android SDK of OpenMRS by introducing a new feature: Orders functionality. This feature empowers developers to efficiently handle and manage orders within their applications. In this blog, I will share the step-by-step process of adding this valuable functionality to the OpenMRS Android SDK.
Creating the Model Classes:
To enable the Orders functionality, I began by creating two essential model classes: OrderCreate and OrderGet. These classes serve as blueprints for the network order objects that will be used throughout the SDK. The OrderCreate class captures the necessary information for creating a new order, while the OrderGet class encapsulates the data received from the server in response to order-related requests.
Creating the Entity Class for Local Database Storage:
To persist order data locally, I designed an Entity class specifically tailored for storing orders in the local database. By leveraging the power of ROOM, a popular local persistence library for Android, I ensured that orders can be seamlessly managed within the local environment.
Adding Functionality for Online and Offline Operations:
To provide robust functionality for both online and offline scenarios, I integrated two crucial components: ROOM DAO functions and Retrofit interface functions.
The ROOM DAO functions allow developers to interact with the local database and perform operations such as inserting, updating, deleting, and querying orders. These functions provide a convenient abstraction layer, simplifying the process of managing orders within the SDK.
On the other hand, the Retrofit interface functions handle the communication between the Android SDK and the OpenMRS server. These functions enable developers to send requests related to orders, such as creating a new order, updating an existing order, or retrieving a list of orders from the server.
By combining these two components, developers gain the flexibility to work with orders seamlessly, whether the device is connected to the internet or operating in an offline mode.
Adding a Repository for Combined Functionality:
To provide a unified and abstracted interface for performing operations related to orders, I introduced a repository within the SDK. This repository acts as a central hub, encapsulating the combined functionality of the aforementioned components.
By utilizing the repository, developers can easily interact with the Orders functionality without worrying about the underlying implementation details. The repository exposes intuitive methods to create orders, update orders, retrieve orders, and perform other essential operations. This abstraction enhances the developer experience and promotes code maintainability.
Conclusion:
With the addition of the Orders functionality to the Android SDK of OpenMRS, developers now have a powerful tool to manage orders seamlessly within their applications. By following a systematic approach that involved creating model classes, designing a local database entity, integrating ROOM and Retrofit components, and introducing a repository for abstracted functionality, we have successfully expanded the capabilities of the SDK.
This enhancement opens up new possibilities for developers working on healthcare-related applications powered by OpenMRS. They can now effortlessly handle orders, ensuring efficient data management and streamlined workflows. I am excited to see how this new feature empowers developers and contributes to the advancement of healthcare technology.
Thank you for reading and stay tuned for week 3 progress :)
Connect with me on LinkedIn: www.linkedin.com/amshubham