1. Introduction

Week 4 focused on moving HireRosterly Mobile from basic role-based implementation toward closer functional parity with the Web application. The main effort was to compare the mobile application with the latest backend-supported Web workflows, integrate newly discovered business modules, strengthen authentication and route protection, and improve the experience on real mobile screen sizes.

The week also included Android APK/device testing and detailed debugging. Testing exposed an important difference between the live Vercel deployment and the local backend: several newer routes used by the mobile application were available locally but were not available from the live deployment being used by the APK. Switching the development environment to the working local API allowed the newer HR workspace to load and made the next frontend issues visible.

2. Mobile–Web Feature Parity Expansion

A feature-parity review identified several capabilities that had been added to the Web/backend but were not yet represented in the mobile application. These areas were implemented without removing the existing Login, Admin, HR, Employee, attendance, leave, holiday and profile flows.

• Employee salary history and HR salary create/update/delete workflows.
• Employee loan creation, editing and cancellation, with HR approval/rejection.
• EOSB settlement preparation and employee settlement visibility.
• Organization and department administration for Admin users.
• HR profile submission and Admin approval/rejection/deletion workflows.
• Location-aware employee check-in and check-out.
• Monthly attendance reports with HR approval and employee visibility.
• Expanded leave contracts, salary details, balances and payment-method handling.

3. New Screens and Service Integration

New role-specific screens and typed service modules were added so that the mobile structure mirrors the available business areas more closely. The implementation continued to separate UI concerns from API access, which made it easier to test individual contracts and isolate backend problems.

• Admin: Organization Directory and HR Profiles.
• HR: Salary, Loans, EOSB, Attendance Reports and My HR Profile.
• Employee: Salary, Loans, EOSB and Clock In/Out.
• Shared finance, organization, HR-profile and attendance-report service layers.
• Navigation updates for Admin, HR and Employee role groups.

4. Authentication and Protected Routing

A browser test showed that removing the stored token and refreshing a protected page did not always return the user to Login. The root cause was that nested role layouts could render without a centralized guard, while some authentication decisions depended on stale in-memory state.

The mobile routing structure was therefore strengthened with centralized protected-route and guest-route behavior. Protected workspaces now wait for session restoration, require both the persisted user and token, enforce role boundaries, and react to logout or authenticated HTTP 401 responses.

• Logged-out users are redirected away from Admin, HR and Employee workspaces.
• Wrong-role sessions are redirected to their own workspace.
• Authenticated users cannot remain on Login/Signup routes.
• Protected content stays hidden while stored authentication is restored.
• Logout and 401 responses invalidate the active session.

5. Responsive UI, Scrolling and Mobile Usability

The application was also audited for small-screen usability. Several long forms and drawers could not reliably reach their final controls, especially on narrow mobile screens. Shared screen infrastructure was improved to support full-height scrolling, safe-area spacing, bottom reachability and responsive padding.

• Scrollable Admin, HR and Employee navigation drawers with reachable Logout actions.
• Responsive layouts for narrow phone widths and wrapping action groups.
• Long profile and finance forms organized into clearer sections.
• Keyboard-aware layout work planned around KeyboardAvoidingView + ScrollView behavior.
• Touch-friendly inputs/buttons and improved loading, error and empty states.

6. APK and Runtime Verification

An Android APK was built and tested on a physical mobile device. The first device test displayed a network request failure even though the APK had been configured for the live Vercel API. Investigation showed that the problem was not simply the device network: the live deployment did not expose all of the newer routes expected by the updated mobile application.

For local verification, the API base was changed to the working local backend. HR authentication then succeeded and the HR workspace opened. This confirmed that the newer mobile code could communicate with the backend when the expected routes were available.

7. HR Runtime Error Investigation

After local connectivity was restored, navigation inside the HR panel exposed a React runtime problem. Opening Employee Requests and other HR pages could trigger a “Maximum update depth exceeded” error while successful API responses were repeatedly logged. This indicates a frontend state/effect feedback loop rather than an API connectivity failure.

The next debugging pass is focused on effect dependencies, unstable callbacks, route guards, refresh handlers, context updates and navigation effects. The goal is to remove the real render loop while preserving authentication, API contracts and the working role-based navigation.

8. API and Backend Findings

Swagger was useful for validating the established authentication, employee, holiday, attendance, leave and profile endpoints. However, the project review also showed that the live OpenAPI document does not fully represent every newer route used by the latest Web/backend implementation. This means Swagger alone cannot be treated as the complete source of parity for the current project.

• Local backend routes were used to verify newer functionality where available.
• The mobile application kept typed API/service boundaries for easier contract maintenance.
• A public signup endpoint for approved HR and organization selector data is still not available.
• Some backend-only defects remain outside the mobile code and require backend follow-up.

9. Lead Collection

Lead collection continued as a parallel weekly delivery activity. The existing lead sheet format was retained so business research remains consistent across weeks. Records are organized by business, niche, location, website quality, mobile/UI observations, CTA and speed issues, and available contact information.

Keeping this process separate from application development allows outreach preparation to continue even when a technical integration issue temporarily blocks the mobile project.

10. Weekly Blog Preparation

This Week 4 blog was prepared as part of the weekly reporting cycle. It documents the feature-parity work, authentication improvements, mobile usability changes, APK/device testing, API findings and the remaining HR runtime issue. Writing the blog also provides a concise technical record that can be used alongside the presentation during weekly review.

11. Issues / Failures Faced & Learnings

• The APK initially showed a network request failure against the live deployment.
• Newer API routes available in the working local project were not consistently available from the live deployment.
• A missing HR profile route caused a 404 until the environment/backend path was aligned for local testing.
• HR navigation later exposed a React maximum-update-depth loop that requires a focused frontend fix.
• Real device and browser testing revealed problems that static compilation alone could not identify.

The main learning from this week is that parity requires more than adding screens. Deployment state, route availability, authentication restoration, role protection, keyboard behavior, scrolling and repeated navigation all need to be tested as one system.

12. Punctuality & Team Participation

Work continued across implementation, verification and debugging rather than stopping at the first successful build. Feature gaps were documented, mobile changes were kept separate from Web/backend code, and failures found during browser and physical-device testing were converted into specific follow-up tasks.

• Compared mobile behavior against current Web/backend functionality.
• Expanded role-specific features while preserving existing flows.
• Tested the Android application on a physical device.
• Investigated API/deployment differences instead of masking errors with mock data.
• Prepared the weekly blog and presentation for progress reporting.

13. Next Development Plan

• Fix the HR Maximum Update Depth error across all HR routes.
• Complete app-wide KeyboardAvoidingView and scrolling verification for forms and modals.
• Regression-test Admin, HR and Employee protected routes.
• Verify newer APIs against the intended deployment environment.
• Complete authenticated end-to-end testing of salary, loans, EOSB, reports and profile approval flows.
• Build the next APK only after the current runtime regression pass is clean.
• Continue weekly lead collection and reporting.

14. Improvement Plan & Support Required

The next improvement priority is a stable regression cycle: verify backend availability first, test protected routing, test every role screen, then validate keyboard/scroll behavior before producing another APK. This sequence should reduce repeated builds caused by issues that can be caught earlier in browser or Metro testing.

• Backend/deployment support to keep live routes aligned with the current project.
• Clear API documentation for newer salary, loan, EOSB, organization and HR-profile routes.
• Continued Codex support for focused debugging and regression verification.
• Physical Android testing after the HR render-loop and keyboard issues are resolved.

15. Conclusion

Week 4 significantly advanced HireRosterly Mobile toward Web feature parity. The application gained finance, organization, HR-profile, attendance-report and location-based workflows, while authentication and route protection were strengthened for real session behavior. Physical APK testing and local backend verification also exposed deployment and frontend runtime issues that would not have been visible from compilation alone.

The project is now in a focused stabilization stage. The immediate priority is to remove the HR render loop, complete keyboard-aware scrolling across the application, run role-based regression tests and then produce the next Android build from a verified configuration.

Author: Hassan Shafique