In this blog series, I will be sharing my experiences, challenges, and achievements as I embark on this GSOC adventure. Join me as I dive into Week 1, where I kickstart my work and make significant strides toward my project goals.
How the week started 📈
During the initial days of the week, my focus was on immersing myself in comprehending the complexities of the DHIS2 API and its efficient utilization for performing crucial CRUD operations. I dedicated my time to exploring the API's functionalities and features, aiming to gain a deep understanding of its internal mechanisms and identify strategies to maximize its potential for my ongoing tasks.
Once I acquired a reasonable grasp of the DHIS2 API, I proceeded to work on the authentication section of the application. I carefully examined the existing workflow of the authentication bloc and the data stored in the hive storage. By observing this current process, I aimed to gain insights into the functioning and structure of the authentication system.
Things I Coded and the Problems It Solves 🧑💻
During the community bonding phase, I realized that the current implementation of fetching the tracked attributes and tracked entities from the DHIS2 backend relied on the hardcoded UIDs of them in the code base, which would cause a setback to the application if it is used on any other DHIS2 server as it would have different UID of them and may also have different names for them.
To tackle this problem, it is necessary to adopt a more flexible strategy for managing UIDs and URLs that can be tailored to the specific needs of each hospital. Developing a separate application for every hospital is impractical due to the significant time and financial investments it would require. Likewise, expecting hospital staff to manually input UIDs and URLs is not a feasible solution.
A possible resolution for the issue of fixed UIDs in the DHIS2 backend is to exploit the capability to manage the names of attributes and instances created. Although we may not have direct influence over the specific UIDs generated, we can utilize the names of attributes and instances as a method of recognizing and monitoring them.
How to solve this problem ❓❓
One potential resolution for the fixed UIDs issue in the DHIS2 backend involves utilizing the capability to manage the names of attributes and instances. While we may not have direct influence over the specific UIDs generated, we can use the names of attributes and instances as a method of recognizing and monitoring them.
To implement this solution, I propose creating a script that runs when a user logs into the application with their username, password, and server address for their hospital's DHIS2 instance. This script would authenticate the user and retrieve the DHIS2 instance details using the provided credentials. Subsequently, it would search for the desired attributes and instances based on their names within the DHIS2 instance.
If the attributes and instances are not present, the script would leverage the DHIS2 web API to create them. The UIDs of the created or existing attributes and instances would then be stored in the hive storage for future use by the application. This approach ensures that the application always uses the correct UIDs for each hospital, maintaining flexibility and scalability.
Upcoming Week: A Focus on Finalizing Plans, Implementing BLOC Architecture, and Creating Tracked Entities
As I look ahead to the upcoming week, I have set my sights on several key tasks and objectives that will drive my progress in the GSOC'23 program with LibreHealth.
Finalizing the Summer Plan with Mentors:
During the upcoming week, I have set a goal to finalize the entire summer plan in collaboration with my mentors. This step is crucial as it allows us to align our objectives, prioritize tasks, and establish a clear roadmap for the upcoming weeks. By discussing and refining the plan together, we can ensure that our goals are well-defined and achievable. This collaboration will provide valuable insights and guidance, setting the foundation for a productive and successful summer project.
Implementing BLOC Architecture for Proper State Management:
To enhance the application's state management and improve the retrieval of tracked baby data from the DHIS2 backend, I will focus on implementing the BLOC architecture. BLOC (Business Logic Component) is a design pattern that separates the user interface, business logic, and data sources, resulting in a clean and scalable code structure. By adopting the BLOC architecture, I aim to streamline the retrieval process and ensure that the application handles the data efficiently, providing a smooth user experience. This approach will enable better organization and maintainability of the codebase while improving the overall performance of the application.
Creating Tracked Attributes and Entities in the DHIS2 Backend:
Another key task for the upcoming week is to create the necessary tracked attributes and entities within the DHIS2 backend. These attributes and entities play a vital role in capturing and storing relevant information about the tracked babies. By creating them in the DHIS2 backend, we establish the foundation for accurately recording and managing the data. This step will involve working closely with the DHIS2 API, utilizing its functionality to define the required attributes and entities, ensuring that they align with the specific needs of the application. By properly setting up the tracked attributes and entities, we lay the groundwork for efficient data processing and analysis in the application.
