<Feature><Segregate Master Data and Pre-Registration Sync>US#02: Integrate Segregated Sync Using Existing Backend APIs

[Varaniya201]

Description

As an Android Client Developer, I want to call existing Master Data Sync and Pre-registration Sync APIs separately when operators click "Synchronise Data" and "Download Pre-Registration Data" buttons, So that I can provide segregated sync functionality without requiring any backend changes - just using existing APIs in a new way based on which button is clicked.

Purpose

To provide operators with granular control over sync operations through clear and descriptive button names that explain the purpose of each sync, along with visibility into sync progress and specific error messages for each sync type. This enhancement also addresses the differing sync frequencies, where master data sync occurs infrequently, while pre-registration data is expected to be synced and updated on a daily basis.

Pre-requisites

• Master Data Sync API endpoint already exists: v1/syncdata/v2/clientsettings
• Pre-registration Sync API endpoint already exists: /preregistration/v1/sync
• Existing SyncService or similar service available
• Network/HTTP client infrastructure available
• Database access for storing timestamps

Basic Flow

Existing APIs Being Used:

1. Master Data Sync (Already Exists)
   Endpoint: /v1/syncdata/v2/clientsettings
   Purpose: Syncs master configuration, templates, devices
   Called by: "Synchronise Data" button
   
2. Pre-registration Sync (Already Exists)
   Endpoint: /preregistration/v1/sync
   Purpose: Syncs pre-registered applicant data
   Called by: "Download Pre-Registration Data" button
   

---

Step 1: When Operator Clicks "Synchronise Data" Button

1. Android UI calls: respective method

2. SyncService makes request to existing API: /v1/syncdata/v2/clientsettings

3. Backend API processes ONLY master data:

   • Downloads document templates
   • Downloads device configuration
   • Downloads machine settings
   • Download all master data required for registration
   • Returns ONLY master data (no pre-registration data)

4. Response received (same as before):

   {
     "success": true,
     "masterData": {
       "documentTypes": [...],
       "devices": [...],
       "configuration": {...}
     },
     "status": "COMPLETED",
     "timestamp": "2024-05-13T14:45:00Z"
   }

5. Android UI:

   • Stores response as master data
   • Updates last sync timestamp for "Synchronise Data"
   • Displays: "✓ Synchronise Data completed successfully"
   • Button becomes enabled again

---

Step 2: When Operator Clicks "Download Pre-Registration Data" Button

1. Android UI calls the respective method
2. SyncService makes request to existing API: /preregistration/v1/sync
3. Backend API processes ONLY pre-registration data:
   • Downloads applicant records
   • Downloads biometric data
   • Returns ONLY pre-registration data (no master data)
4. Response received (same as before):
5. Android UI:
   • Stores response as pre-registration data
   • Updates last sync timestamp for "Download Pre-Registration Data"
   • Displays: "✓ Download Pre-Registration Data completed successfully"
   • Button becomes enabled again

---

Step 3: Error Handling Using Existing API Responses

"Synchronise Data" fails:

1. API returns error (same as existing behavior):

   {
     "success": false,
     "errorCode": "NETWORK_TIMEOUT",
     "errorMessage": "Request timeout after 30s",
     "status": "FAILED"
   }

2. Android UI:

   • Parses the error response
   • Shows specific error: "Synchronise Data failed: Network timeout"
   • Logs with syncType = "SYNCHRONISE_DATA"
   • Offers [RETRY] button

"Download Pre-Registration Data" fails:

1. API returns error (same as existing behavior):

   {
     "success": false,
     "errorCode": "SERVER_ERROR",
     "errorMessage": "Internal server error",
     "status": "FAILED"
   }

2. Android UI:

   • Parses the error response
   • Shows specific error: "Download Pre-Registration Data failed: Server error"
   • Logs with syncType = "DOWNLOAD_PRE_REG"
   • Offers [RETRY] button

---

Step 4: Store Last Sync Timestamps Separately

In local database (GLOBAL_PARAM table):

After "Synchronise Data" completes:
- Key: "last_synchronise_data_timestamp"
- Value: "2024-05-13 14:45:00"

After "Download Pre-Registration Data" completes:
- Key: "last_download_pre_reg_data_timestamp"
- Value: "2024-05-13 14:50:00"

Display on dashboard:

Synchronise Data
Last synced: 2:30 PM

Download Pre-Registration Data
Last synced: 2:45 PM

---

Step 5: Retry Logic Using Same Existing APIs

When user clicks [RETRY] after failure:

1. Android calls same API endpoint again:

   POST /registration/v1/config/mastersync  (for "Synchronise Data")
   OR
   POST /registration/v1/preregistration/sync  (for "Download Pre-Registration Data")
   

2. Backend API handles retry (same logic as original call)

3. No special retry parameter needed

4. Backend returns fresh response

Alternate Flows

Alternate Flow A1: Network Loss During Sync

1. API call is in progress
2. Network connection drops
3. Android detects timeout/network error
4. Shows message: "Network connection lost"
5. User clicks [RETRY]
6. Android calls same API endpoint again
7. Network restored; API succeeds

Alternate Flow A2: No New Data to Sync

1. "Download Pre-Registration Data" API called
2. API returns: {"success": true, "preRegistrations": []}
3. Android UI shows: "Download Pre-Registration Data completed. No new data found."
4. Timestamp still updated
5. Button enabled again

Alternate Flow A3: Authentication Error (401)

1. API returns: {"success": false, "status": 401}
2. Android redirects to login screen
3. After login, user can retry sync
4. Same API called again

Alternate Flow A4: Multiple Retries Fail

1. First retry fails
2. Second retry fails
3. After 3 failures, show: "Multiple attempts failed"
4. Offer [TRY LATER] or [CONTACT SUPPORT]
5. Stop retrying automatically

Alternate Flow A5: App Backgrounded During Sync

1. API call made
2. Operator switches to another app
3. Sync request continues in background
4. When app returns to foreground:
   • If still syncing: Progress restored
   • If completed: Success/error shown

Scenarios

Scenario	Action	API Called	Expected Result
S1	Click "Synchronise Data"	POST /registration/v1/config/mastersync	Only master data synced
S2	Click "Download Pre-Registration Data"	POST /registration/v1/preregistration/sync	Only pre-reg data downloaded
S3	Network timeout	Retry same API	Eventually succeeds
S4	No new pre-reg data	GET /registration/v1/preregistration/sync	Success; "No data" message
S5	Server returns 500	Retry available	User can retry
S6	3 failed retries	-	Stop retrying; show error

Data Fields

No response

Business Rules (With Audit)

No response

Acceptance Criteria

Criteria	Verification Method
"Synchronise Data" API called when button clicked	Check network logs; verify /config/mastersync endpoint hit
"Download Pre-Registration Data" API called when button clicked	Check network logs; verify /preregistration/sync endpoint hit
Master data response processed as master only	Verify only master data stored in database
Pre-reg response processed as pre-reg only	Verify only pre-reg data stored in database
Error messages specific to each sync type	Error shows correct button name in message
Timestamps stored separately	Query database; verify different timestamps

Exceptions

Exception	Handling
Network error during call	Show error; allow retry of same API
API returns error response	Parse error; show specific message
Timeout during API call	Treat as network error; allow retry
User navigates away during sync	Continue request in background
App crashes during sync	User can retry manually

Documentation

No response

Reference UX

No response

Compatibility

No response

Implementation Details

Important Notes

NO BACKEND CHANGES REQUIRED:

✅ Use existing Master Data Sync API as-is
✅ Use existing Pre-registration Sync API as-is
✅ Use existing Combined Sync API for backward compatibility
✅ Just call them separately based on button click
✅ All logic for queue/progress/error handled at Android level

What Changes:

• ❌ NOT the backend APIs (they stay the same)
• ✅ The SyncService methods (separate them)
• ✅ The Android UI (two buttons with correct labels)
• ✅ The state management (track which sync running)
• ✅ The queue logic (local memory, not backend)

Non-Functional Requirements

Requirement	Specification
API Calls	Use existing endpoints (no changes)
Response Parsing	Handle responses same as before
Error Handling	Same error handling as existing code
Performance	No performance impact (same APIs)
Data Integrity	No data mixing (master vs pre-reg)