GSoC 2023 with OpenMRS | Coding Week 01
After an exciting community bonding period, the coding phase has commenced and one week is already over. In this blog post, I will share the progress I made with the Android client of OpenMRS during the first week of coding period.
For clear explanation, I have divided the blog into following parts:
- Adding Encounter APIs to the SDK
- Fix the Login crash due to session Id
- Offline Patient identifier fix
- GitHub CI integration
1. Adding Encounter APIs to the SDK
I am currently engaged in enhancing the Android SDK with the APIs that will prove highly advantageous for developers who are working on building Android applications on the top of OpenMRS.
In the first week, I specifically focused on the Encounter endpoint and commenced the process of creating wrapper functions within the Android SDK to facilitate abstraction.
One of the key challenges I encountered was the need to create wrapper functions in the repository to handle both online and offline operations. For that I had to understand and create the Model classes which were already created (for online operations) and Entities (for offline operations) and then understand how the JSON representation parsed in the model classes is converted to an Entity type for the local database operations.
The Solution:
1.) First, we use Retrofit to retrieve all the Encounter Resources associated with the patient UUID from the remote server. These Encounter Resources are received in JSON format.
2.) Once the Encounter Resources are fetched, the SDK stores them locally.
3.) Next, we retrieve the individual Encounter objects using their respective UUIDs. Upon obtaining the Encounter objects, map them to their corresponding Model class.
3.) Finally, the mapped Encounter objects are converted to a specific Entity class type. This conversion prepares the data to be stored in the local database, ensuring compatibility with the database schema and allowing for efficient storage and retrieval.
For illustrative purpose, One of the functions I added:
To see all the functions I added, take a look at this PR:
This was my half week work. The other half includes:
2. Fix the Crashing App due to session Id
Previously, the session ID used to be included in the response body of the REST request in the OpenMRS Android SDK. However, a change was made to enhance this functionality by moving the session ID from the response body to the headers.
To address this update, the Application now retrieves the session ID from the headers of the REST response instead of extracting it from the response body. This change ensures a more standardized and secure approach, as session-related information is typically stored in the headers of HTTP requests.
Here’s the PR:
3. Offline Patient identifier fix
When viewing the Patient dashboard for an offline patient, the patient identifier title appeared as “null” on the action bar of the app.
Fixed by the PR here:
4. GitHub CI integration
Previously, the verification of incoming PRs to the repository was handled by AppVeyor. However, it appears that there is an issue causing AppVeyor to no longer verify the new PRs.
To enhance the development process and ensure the quality of incoming pull requests, commits, and pushes to the repository, a new workflow file named “android.yml” has been added.
This workflow file, specific to the Android project, defines a set of actions to be executed automatically upon receiving new changes. It serves as a verification mechanism to validate the integrity, functionality, and adherence to coding standards of the incoming code.
Additional task 📝
In addition to the mentioned tasks, I researched and explored about the keystore functionality in Android, particularly regarding its role in signing release builds.
During my research, I uncovered a critical issue within the current version of the repository’s codebase, which hinders the successful signing of release builds.
Notably, this concern was initially brought to light during the GSoC ’21 program by Saurabh during his work on Android client, and unfortunately, it continues to persist.
Recognizing the significance of this challenge, I took the initiative to document my extensive findings and insights in a seperate dedicated blog post which I will share soon!
Thank you for reading! :)
Connect with me on LinkedIn: www.linkedin.com/amshubham