Refine Patient List & Details UI with State Handling and Stability Improvements

[s225031317]

This PR enhances the patient list and patient details screens by improving UI structure, state handling, and application stability.

Key Improvements:

• Refined patient list UI by improving card layout, text formatting, and image handling.
• Restructured patient details screen into clear sections (personal, health, and activities).
• Implemented loading, empty, and error state handling for API-driven UI components.
• Improved API response handling using null safety and structured error parsing.
• Fixed UI inconsistencies and improved frontend stability.

[s225031317]

The CI build failure was caused by deprecated Gradle and GitHub Actions configurations in the project pipeline. The application compiles and runs successfully in the local development environment, confirming that the issue is not related to the implemented frontend changes.

[KudratAroraa]

Approved. I reviewed the changes and the PR aligns well with the stated scope. The patient list and patient details screens have been improved both structurally and visually, with a cleaner card layout, better text formatting, improved image handling, and clearer sectioning for personal information, health information, assigned nurses, and patient activities. The introduction of loading, empty, and error states also makes the API-driven UI more stable and improves the overall user experience.

I also noted solid improvements in null safety and API response handling, particularly in PatientDetailsActivity and PatientListActivity, where the data flow is now handled more defensively and error parsing is more robust. It is also good to see the existing delete action flow kept connected within the patient list handling, with the list refreshing after deletion. The changes are focused, meaningful, and strengthen frontend reliability without introducing unnecessary complexity.

Overall, this is a good refinement PR and looks ready to merge. As a small future improvement, lifecycle-aware coroutine scopes, fragment arguments for stronger state preservation, and a proper confirmation dialog for the delete flow could be considered, but these are not blockers for the scope of this PR.