RCF-1354: Implemented the Maximum number of days without running the sync and added GPS location validation

[SachinPremkumar]

RCF-1354

Summary by CodeRabbit

• New Features

  • Registration can accept optional GPS coordinates and run pre-checks (sync-status) including device distance validation before starting.

• Behavior Changes

  • Automatic location fetch on process init removed; quick location capture (10s) now occurs when explicitly triggered (e.g., language selector).
  • New user-facing error for out-of-center location.

• Localization

  • Added localized error variants for time-sync exceedance and outside-location (AR, EN, FR, HI, KN, TA).

• Strings

  • Added new error string resource (err_003).

• Tests

  • Extensive unit tests covering GPS and sync-status validation scenarios.

_{✏️ Tip: You can customize this high-level summary in your review settings.}

[coderabbitai]

Walkthrough

Adds optional latitude/longitude to registration start APIs and flows, introduces a PreCheckValidatorService (interface + implementation) to validate sync-job frequencies and center-to-machine distance (throws ClientCheckedException), wires the service into DI and registration flow, updates UI to capture/pass GPS, and extends localization and tests.

Changes

Cohort / File(s)	Summary
Pre-check validator (new SPI + impl) android/clientmanager/src/main/java/io/mosip/registration/clientmanager/spi/PreCheckValidatorService.java, android/clientmanager/src/main/java/io/mosip/registration/clientmanager/service/PreCheckValidatorServiceImpl.java	New interface and implementation providing validateSyncStatus() and validateCenterToMachineDistance(Double, Double); validates sync-job frequencies and center-to-machine distance, throws ClientCheckedException on failures.
Registration service integration & DI android/clientmanager/src/main/java/io/mosip/registration/clientmanager/config/AppModule.java, android/clientmanager/src/main/java/io/mosip/registration/clientmanager/service/RegistrationServiceImpl.java	DI updated to provide PreCheckValidatorService; RegistrationServiceImpl constructor and startRegistration signature extended to accept latitude, longitude; GPS validation call added and validateSyncStatus() invoked during pre-checks; removed validateLocation().
Public service API changes (SPI / Pigeon / Dart / Android API) android/clientmanager/src/main/java/io/mosip/registration/clientmanager/spi/RegistrationService.java, pigeon/registration_data.dart, lib/platform_spi/registration_service.dart, android/app/src/main/java/io/mosip/registration_client/api_services/RegistrationApi.java, lib/platform_android/registration_service_impl.dart	startRegistration(...) signatures extended to accept optional latitude, longitude across SPI, pigeon, Android API, and Dart; Android RegistrationApi now handles ClientCheckedException to map error codes into responses.
Dart providers & UI changes lib/provider/registration_task_provider.dart, lib/ui/process_ui/widgets/language_selector.dart, lib/provider/global_provider.dart, lib/ui/process_ui/generic_process.dart	UI attempts to capture GPS with a 10s timeout and passes optional coords to startRegistration; removed automatic location fetch on GenericProcess init; fetchLocation times out gracefully.
Constants, resources & localization android/clientmanager/src/main/java/io/mosip/registration/clientmanager/constant/RegistrationConstants.java, android/clientmanager/src/main/res/values/strings.xml, assets/l10n/*.arb	Added geo/sync-related constants and opt-in flags; added err_003 string resource; added localized error tokens OPT_TO_REG_TIME_SYNC_EXCEED and OPT_TO_REG_OUTSIDE_LOCATION across ARB files.
Android start API change android/app/src/main/java/io/mosip/registration_client/api_services/RegistrationApi.java	startRegistration signature updated to accept latitude, longitude; service call updated to pass them; ClientCheckedException handled to populate response error code.
Tests android/clientmanager/src/test/java/io/mosip/registration/clientmanager/service/PreCheckValidatorServiceImplTest.java, android/clientmanager/src/test/java/io/mosip/registration/clientmanager/service/RegistrationServiceImplTest.java	New comprehensive unit tests for PreCheckValidatorServiceImpl and updated/added tests for RegistrationServiceImpl covering GPS and sync validation flows.

Sequence Diagram(s)

sequenceDiagram
    participant UI as Client/UI
    participant DartSvc as Dart RegistrationService
    participant Pigeon as RegistrationDataApi (Pigeon)
    participant AndroidApi as RegistrationApi (Android)
    participant RegSvc as RegistrationServiceImpl
    participant PreVal as PreCheckValidatorService
    participant SyncRepo as SyncJob/JobTransactionService
    participant Master as MasterDataService
    participant LocSvc as LocationValidationService

    UI->>DartSvc: startRegistration(langs, flow, process, latitude?, longitude?)
    DartSvc->>Pigeon: startRegistration(..., latitude?, longitude?)
    Pigeon->>AndroidApi: startRegistration(..., latitude?, longitude?)
    AndroidApi->>RegSvc: startRegistration(..., latitude, longitude)

    activate RegSvc
    RegSvc->>RegSvc: build RegistrationDto (set geo if present)

    alt Latitude & Longitude provided
        RegSvc->>PreVal: validateCenterToMachineDistance(longitude, latitude)
        activate PreVal
        PreVal->>Master: fetch registration center(s)
        PreVal->>LocSvc: calculate distance(center, machine)
        PreVal->>PreVal: compare with configured max distance
        PreVal-->>RegSvc: pass / throw ClientCheckedException
        deactivate PreVal
    end

    RegSvc->>PreVal: validateSyncStatus()
    activate PreVal
    PreVal->>SyncRepo: fetch active sync jobs & last transactions
    PreVal->>PreVal: compute days since last sync vs configured frequency
    PreVal-->>RegSvc: pass / throw ClientCheckedException
    deactivate PreVal

    RegSvc-->>AndroidApi: return RegistrationDto or error (mapped code)
    deactivate RegSvc

Loading

Estimated code review effort

🎯 3 (Moderate) | ⏱️ ~30 minutes

Possibly related PRs

• [RCF-1273] Added Unit Test Cases #618 — overlaps in registration start flow and related tests (GPS/pre-check areas).
• RCF-1301 - Implemented config properties  #659 — overlaps with constructor/DI changes to RegistrationServiceImpl and AppModule.
• RCF-1301 Added config properties #661 — touches pre-check/startRegistration flow and related validations.

Suggested reviewers

• MadhuMosip
• ase-101
• mohanachandran-s

Poem

🐰 I hop with coords both near and far,
I check the syncs and where you are.
If center’s close and jobs are fine,
I thump my foot and mark the sign —
Registration hops along, a happy little star.

🚥 Pre-merge checks | ✅ 2 | ❌ 1

❌ Failed checks (1 warning)

Check name	Status	Explanation	Resolution
Docstring Coverage	⚠️ Warning	Docstring coverage is 22.34% which is insufficient. The required threshold is 80.00%.	Write docstrings for the functions missing them to satisfy the coverage threshold.

✅ Passed checks (2 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title accurately reflects the main changes: implementing maximum sync days validation and GPS location validation for registration.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[coderabbitai]

Actionable comments posted: 3

🤖 Fix all issues with AI agents

In
@android/clientmanager/src/main/java/io/mosip/registration/clientmanager/service/SyncStatusValidatorServiceImpl.java:
- Around line 305-308: Replace the hardcoded English message in the
ClientCheckedException throw inside SyncStatusValidatorServiceImpl with a string
resource: add a new entry named err_outside_registration_center in strings.xml
containing the provided message, then call the existing throw new
ClientCheckedException(RegistrationConstants.OPT_TO_REG_OUTSIDE_LOCATION,
context.getString(R.string.err_outside_registration_center)) (or equivalent
using the available Context/Resources) so the exception uses
R.string.err_outside_registration_center instead of the literal string.
- Around line 223-231: getActualDays has an off-by-one: it adds +1 so a job
synced today yields 1, which with the existing comparison configuredFrequency <=
actualDays (used elsewhere) can mark non-overdue jobs as overdue; remove the +1
from getActualDays so it returns the true elapsed days ((int) daysDifference),
then run/adjust any tests or logic that rely on the old behavior (or
alternatively change the comparison to configuredFrequency < actualDays if you
prefer keeping the +1, but the simplest fix is to remove the +1 in
getActualDays).

In
@android/clientmanager/src/main/java/io/mosip/registration/clientmanager/spi/SyncStatusValidatorService.java:
- Around line 17-24: Update the Javadoc for
SyncStatusValidatorService.validateCenterToMachineDistance to document null
parameter behavior: state that machineLongitude and machineLatitude will skip
validation if null (e.g., "@param machineLongitude Machine longitude (validation
skipped if null)" and "@param machineLatitude Machine latitude (validation
skipped if null)"), ensuring the comment reflects the intended behavior of
skipping validation rather than throwing an exception.

🧹 Nitpick comments (7)

assets/l10n/app_en.arb (1)

305-305: Minor spelling inconsistency in error message.

The new error tokens OPT_TO_REG_TIME_SYNC_EXCEED and OPT_TO_REG_OUTSIDE_LOCATION are clear and actionable. However, there's a minor spelling inconsistency in the second message: it uses both "center" and "centre" (British spelling). Consider using consistent spelling throughout.

✏️ Suggested consistency fix

-"errors": "{messages, select, REG_TRY_AGAIN{Login Failed. Try Again!} REG_INVALID_REQUEST{Password incorrect!} REG_MACHINE_NOT_FOUND{This device has not been onboarded yet. Please reach out to your administrator for assistance!} REG_NETWORK_ERROR{Login failed. Check network connection!} REG_CRED_EXPIRED{Credentials not found or are expired. Please try online login!} REG_MACHINE_INACTIVE{Machine is not active!} REG_CENTER_INACTIVE{Center is not active!} REG_LOGIN_LOCKED{Maximum login attempt limit reached. Try again later!} KER_SYN_AUTH_001{Unable to get Authentication Token!} PAK_APPRVL_MAX_TIME{Action required: Pending registered packets have exceeded the allowed approval time. Please clear the backlog to continue.} PAK_UPLOAD_MAX_TIME{Action required: Upload or export the packets to the server before proceeding with registration.} PAK_UPLOAD_MAX_COUNT{Action required: Packet limit reached. Please export or upload existing packets before creating new registrations.} OPT_TO_REG_TIME_SYNC_EXCEED{Time since last sync exceeded maximum limit. Please sync from server before proceeding with this registration.} OPT_TO_REG_OUTSIDE_LOCATION{Your client machine location is outside the registration center. Please note that registration can be done only from within the registration centre} other{'Some error occurred!'}}",
+"errors": "{messages, select, REG_TRY_AGAIN{Login Failed. Try Again!} REG_INVALID_REQUEST{Password incorrect!} REG_MACHINE_NOT_FOUND{This device has not been onboarded yet. Please reach out to your administrator for assistance!} REG_NETWORK_ERROR{Login failed. Check network connection!} REG_CRED_EXPIRED{Credentials not found or are expired. Please try online login!} REG_MACHINE_INACTIVE{Machine is not active!} REG_CENTER_INACTIVE{Center is not active!} REG_LOGIN_LOCKED{Maximum login attempt limit reached. Try again later!} KER_SYN_AUTH_001{Unable to get Authentication Token!} PAK_APPRVL_MAX_TIME{Action required: Pending registered packets have exceeded the allowed approval time. Please clear the backlog to continue.} PAK_UPLOAD_MAX_TIME{Action required: Upload or export the packets to the server before proceeding with registration.} PAK_UPLOAD_MAX_COUNT{Action required: Packet limit reached. Please export or upload existing packets before creating new registrations.} OPT_TO_REG_TIME_SYNC_EXCEED{Time since last sync exceeded maximum limit. Please sync from server before proceeding with this registration.} OPT_TO_REG_OUTSIDE_LOCATION{Your client machine location is outside the registration center. Please note that registration can be done only from within the registration center} other{'Some error occurred!'}}",

android/clientmanager/src/main/java/io/mosip/registration/clientmanager/spi/SyncStatusValidatorService.java (1)

8-15: Consider narrowing exception types for better error handling.

Both methods declare throws Exception, which is overly broad and makes it difficult for callers to handle specific validation failures distinctly. Consider introducing specific exception types (e.g., SyncStatusException, LocationValidationException) or using existing domain-specific exceptions from the codebase.

💡 Refactoring suggestion

 public interface SyncStatusValidatorService {
 
     /**
      * Validates sync job frequencies.
      * 
-     * @throws Exception if validation fails
+     * @throws ClientCheckedException if validation fails
      */
-    void validateSyncStatus() throws Exception;
+    void validateSyncStatus() throws ClientCheckedException;

android/clientmanager/src/main/java/io/mosip/registration/clientmanager/constant/RegistrationConstants.java (1)

3-7: Duplicate import detected.

java.util.ArrayList is imported twice on lines 4 and 5. Also, java.sql.Array on line 3 appears unused in this file.

🧹 Proposed fix

 package io.mosip.registration.clientmanager.constant;
 
-import java.sql.Array;
-import java.util.ArrayList;
-import java.util.ArrayList;
 import java.util.Arrays;
 import java.util.List;

android/clientmanager/src/test/java/io/mosip/registration/clientmanager/service/SyncStatusValidatorServiceImplTest.java (3)

86-93: Redundant mock initialization.

When using @RunWith(MockitoJUnitRunner.class), mocks annotated with @Mock and @InjectMocks are automatically initialized. The explicit MockitoAnnotations.openMocks(this) call on line 88 is redundant and can be removed.

🧹 Proposed fix

     @Before
     public void setUp() {
-        MockitoAnnotations.openMocks(this);
         when(mockContext.getString(R.string.app_name)).thenReturn("RegistrationClient");
         when(mockContext.getSharedPreferences(anyString(), anyInt())).thenReturn(mockSharedPreferences);
         when(mockSharedPreferences.edit()).thenReturn(mockEditor);
         when(mockEditor.putLong(anyString(), anyLong())).thenReturn(mockEditor);
     }

---

404-430: Inconsistent test pattern.

This test uses try-catch-fail() pattern while other similar tests use @Test(expected = ClientCheckedException.class). For consistency, consider using the same pattern across all exception tests.

🧹 Proposed fix

-    @Test
-    public void testValidateCenterToMachineDistance_InvalidCoordinateFormat_ThrowsException() throws Exception {
+    @Test(expected = ClientCheckedException.class)
+    public void testValidateCenterToMachineDistance_InvalidCoordinateFormat_ThrowsException() throws Exception {
         // Setup: GPS enabled
         when(mockGlobalParamRepository.getCachedStringGpsDeviceEnableFlag()).thenReturn("N");

         // Setup: Center details
         CenterMachineDto centerMachineDto = new CenterMachineDto();
         centerMachineDto.setCenterId(CENTER_ID);
         when(mockMasterDataService.getRegistrationCenterMachineDetails()).thenReturn(centerMachineDto);

         RegistrationCenter center = new RegistrationCenter();
         center.setId(CENTER_ID);
         center.setLangCode("eng");
         center.setLatitude("invalid"); // Invalid format
         center.setLongitude("77.5946");
         List<RegistrationCenter> centers = new ArrayList<>();
         centers.add(center);
         when(mockRegistrationCenterRepository.getRegistrationCenter(CENTER_ID)).thenReturn(centers);

         // Execute - should throw exception
-        try {
-            syncStatusValidatorService.validateCenterToMachineDistance(78.5946, 13.9716);
-            fail("Expected ClientCheckedException for invalid coordinate format");
-        } catch (ClientCheckedException e) {
-            // Expected
-        }
+        syncStatusValidatorService.validateCenterToMachineDistance(78.5946, 13.9716);
     }

---

244-255: Test name and comment are misleading about the GPS_DEVICE_ENABLE_FLAG semantics.

The test correctly validates that validation is skipped when the flag is "Y", but the test name GPSDisabled_Skipped and comment "GPS validation disabled" create confusion. When GPS_DEVICE_ENABLE_FLAG is "Y", it means the GPS device is enabled/present, not that GPS is disabled. The implementation intentionally skips distance validation when a GPS device is available, allowing users to manually verify location.

Rename or clarify the test to reflect the actual flag semantics:

• Test should indicate that GPS device is enabled when the flag is "Y"
• Comment should explain that validation is skipped because GPS device is available for manual verification

android/clientmanager/src/main/java/io/mosip/registration/clientmanager/service/SyncStatusValidatorServiceImpl.java (1)

159-163: Consider logging at appropriate level for swallowed exceptions.

The exception handling here silently continues to the next job, which is appropriate for resilience. However, for NumberFormatException (line 160), Log.e (error level) may be too severe for what is essentially a configuration issue. Consider using Log.w (warning) instead.

🧹 Proposed fix

             } catch (NumberFormatException e) {
-                Log.e(TAG, "Invalid frequency value for job: " + jobId + " (" + apiName + "): " + configuredFrequencyStr, e);
+                Log.w(TAG, "Invalid frequency value for job: " + jobId + " (" + apiName + "): " + configuredFrequencyStr + " - skipping validation");
             } catch (Exception e) {
                 Log.e(TAG, "Error validating job: " + jobId + " (" + apiName + ")", e);
             }

📜 Review details

Configuration used: Repository UI

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 096ac7c and b041cc2.

📒 Files selected for processing (13)

• android/app/src/main/java/io/mosip/registration_client/api_services/RegistrationApi.java
• android/clientmanager/src/main/java/io/mosip/registration/clientmanager/config/AppModule.java
• android/clientmanager/src/main/java/io/mosip/registration/clientmanager/constant/RegistrationConstants.java
• android/clientmanager/src/main/java/io/mosip/registration/clientmanager/service/RegistrationServiceImpl.java
• android/clientmanager/src/main/java/io/mosip/registration/clientmanager/service/SyncStatusValidatorServiceImpl.java
• android/clientmanager/src/main/java/io/mosip/registration/clientmanager/spi/SyncStatusValidatorService.java
• android/clientmanager/src/test/java/io/mosip/registration/clientmanager/service/SyncStatusValidatorServiceImplTest.java
• assets/l10n/app_ar.arb
• assets/l10n/app_en.arb
• assets/l10n/app_fr.arb
• assets/l10n/app_hi.arb
• assets/l10n/app_kn.arb
• assets/l10n/app_ta.arb

🧰 Additional context used

🧬 Code graph analysis (3)

android/clientmanager/src/main/java/io/mosip/registration/clientmanager/service/SyncStatusValidatorServiceImpl.java (3)

android/clientmanager/src/main/java/io/mosip/registration/clientmanager/repository/GlobalParamRepository.java (1)

• GlobalParamRepository (21-254)

android/clientmanager/src/main/java/io/mosip/registration/clientmanager/repository/RegistrationCenterRepository.java (1)

• RegistrationCenterRepository (11-39)

android/clientmanager/src/main/java/io/mosip/registration/clientmanager/repository/SyncJobDefRepository.java (1)

• SyncJobDefRepository (18-39)

android/clientmanager/src/main/java/io/mosip/registration/clientmanager/config/AppModule.java (2)

android/clientmanager/src/main/java/io/mosip/registration/clientmanager/service/RegistrationServiceImpl.java (1)

• Singleton (96-771)

android/clientmanager/src/main/java/io/mosip/registration/clientmanager/service/SyncStatusValidatorServiceImpl.java (1)

• Singleton (35-318)

android/clientmanager/src/test/java/io/mosip/registration/clientmanager/service/SyncStatusValidatorServiceImplTest.java (4)

android/clientmanager/src/main/java/io/mosip/registration/clientmanager/constant/RegistrationConstants.java (1)

• RegistrationConstants (9-148)

android/clientmanager/src/main/java/io/mosip/registration/clientmanager/repository/GlobalParamRepository.java (1)

• GlobalParamRepository (21-254)

android/clientmanager/src/main/java/io/mosip/registration/clientmanager/repository/RegistrationCenterRepository.java (1)

• RegistrationCenterRepository (11-39)

android/clientmanager/src/main/java/io/mosip/registration/clientmanager/repository/SyncJobDefRepository.java (1)

• SyncJobDefRepository (18-39)

🔇 Additional comments (19)

android/app/src/main/java/io/mosip/registration_client/api_services/RegistrationApi.java (1)

27-27: LGTM! Clean error handling for validation exceptions.

The addition of ClientCheckedException handling enables structured validation error propagation. The catch block is correctly positioned before the generic Exception handler, and returning e.getErrorCode() allows the Flutter layer to receive specific error codes (like OPT_TO_REG_TIME_SYNC_EXCEED and OPT_TO_REG_OUTSIDE_LOCATION) for localized display.

Also applies to: 56-57

android/clientmanager/src/main/java/io/mosip/registration/clientmanager/config/AppModule.java (3)

51-51: LGTM! Proper service imports added.

The imports for SyncStatusValidatorServiceImpl (concrete implementation) and SyncStatusValidatorService (interface) are correctly added to support the new validation service.

Also applies to: 65-65

---

211-212: LGTM! Dependency injection correctly updated.

The provideRegistrationService method signature now includes SyncStatusValidatorService as a parameter, and the service is properly passed to the RegistrationServiceImpl constructor. This follows the existing DI patterns in the module.

Also applies to: 215-215

---

316-328: LGTM! Well-structured provider method.

The provideSyncStatusValidatorService provider method correctly:

• Returns the interface type (SyncStatusValidatorService) rather than the implementation
• Provides all 8 required dependencies for SyncStatusValidatorServiceImpl
• Is annotated as @Singleton for proper lifecycle management
• Follows Dagger conventions used throughout this module

assets/l10n/app_kn.arb (1)

305-305: LGTM! Localization tokens added for Kannada.

The two new error tokens (OPT_TO_REG_TIME_SYNC_EXCEED and OPT_TO_REG_OUTSIDE_LOCATION) have been added to the Kannada localization file, maintaining consistency with the English version.

assets/l10n/app_hi.arb (1)

305-305: LGTM! Localization tokens added for Hindi.

The two new error tokens (OPT_TO_REG_TIME_SYNC_EXCEED and OPT_TO_REG_OUTSIDE_LOCATION) have been added to the Hindi localization file, maintaining consistency with the English version.

assets/l10n/app_ar.arb (1)

305-305: LGTM: Localization keys added for new validation features.

The Arabic translations for the two new error messages (OPT_TO_REG_TIME_SYNC_EXCEED and OPT_TO_REG_OUTSIDE_LOCATION) have been added consistently with the existing error message pattern.

assets/l10n/app_fr.arb (1)

305-305: LGTM: Localization keys added for new validation features.

The French translations for the two new error messages (OPT_TO_REG_TIME_SYNC_EXCEED and OPT_TO_REG_OUTSIDE_LOCATION) have been added consistently with the existing error message pattern.

assets/l10n/app_ta.arb (1)

314-314: LGTM: Localization keys added for new validation features.

The Tamil translations for the two new error messages (OPT_TO_REG_TIME_SYNC_EXCEED and OPT_TO_REG_OUTSIDE_LOCATION) have been added consistently with the existing error message pattern.

android/clientmanager/src/main/java/io/mosip/registration/clientmanager/service/RegistrationServiceImpl.java (3)

71-71: LGTM: Dependency injection properly implemented.

The SyncStatusValidatorService dependency has been correctly wired through constructor injection, following the existing pattern used for other services in this class. The field is properly declared, assigned, and ready for use.

Also applies to: 118-118, 136-137, 153-153

---

575-578: LGTM: Sync status validation properly placed in pre-checks.

The sync status validation is correctly positioned in the pre-registration checks sequence, ensuring validation occurs before any registration processing begins. The null-safe invocation pattern is consistent with other optional validations in this method.

---

200-210: Parameter order is correct and consistent with the method signature.

The call at lines 203-205 passes longitude then latitude, which matches the validateCenterToMachineDistance(Double machineLongitude, Double machineLatitude) method signature. Lines 500-503 only access the fields separately, not as method parameters, so they don't establish a different ordering convention. The code is internally consistent; parameter order is not an issue.

Regarding timing: Validation immediately follows DTO initialization, which is appropriate since the geolocation data must be available to validate it. The DTO is a lightweight data container (initialized with the constructor parameters), not a resource-heavy object, so early vs. late validation has minimal practical impact.

android/clientmanager/src/main/java/io/mosip/registration/clientmanager/constant/RegistrationConstants.java (1)

121-148: LGTM!

The new constants are appropriately named and follow existing conventions. They correctly support the new sync status and GPS location validation features.

android/clientmanager/src/test/java/io/mosip/registration/clientmanager/service/SyncStatusValidatorServiceImplTest.java (2)

269-300: LGTM!

The test correctly validates the success scenario when the machine is within the allowed distance from the registration center. Mock setup is clean and assertions verify the expected behavior.

---

521-539: LGTM!

The helper method is well-structured and promotes test code reuse across multiple test cases.

android/clientmanager/src/main/java/io/mosip/registration/clientmanager/service/SyncStatusValidatorServiceImpl.java (4)

49-67: LGTM!

Constructor properly injects all required dependencies for the validation service.

---

244-248: GPS flag logic may be inverted.

The condition skips validation when enableFlag is "Y" (GPS device enabled). This is counterintuitive—typically you would validate distance when GPS is available, not skip it.

If GPS_DEVICE_ENABLE_FLAG = "Y" means "GPS validation should be enabled," then the condition should be inverted:

🔧 Potential fix if logic is inverted

         String enableFlag = globalParamRepository.getCachedStringGpsDeviceEnableFlag();
-        if (enableFlag == null || "Y".equalsIgnoreCase(enableFlag)) {
-            Log.d(TAG, "GPS distance validation disabled or not configured, skipping");
+        if (enableFlag == null || "N".equalsIgnoreCase(enableFlag)) {
+            Log.d(TAG, "GPS device disabled or not configured, skipping distance validation");
             return;
         }

Please verify the intended semantics of GPS_DEVICE_ENABLE_FLAG:

• Does "Y" mean GPS device is enabled (and validation should run)?
• Or does "Y" mean GPS validation feature should be bypassed?

---

35-47: LGTM!

The service is correctly annotated as @Singleton and doesn't maintain shared mutable state. Thread safety depends on injected dependencies, which should be thread-safe by design.

---

165-170: LGTM!

The error message construction clearly communicates the validation failure with actionable details about which jobs are overdue.

[coderabbitai]

Actionable comments posted: 2

🤖 Fix all issues with AI agents

In
@android/clientmanager/src/main/java/io/mosip/registration/clientmanager/service/SyncStatusValidatorServiceImpl.java:
- Around line 244-248: The GPS enable-flag check is inverted: currently it
returns (skips validation) when enableFlag is "Y"; change the condition so the
method only skips when the flag is absent or not set to "Y". Locate the
getCachedStringGpsDeviceEnableFlag() call and the surrounding if using the
enableFlag variable in SyncStatusValidatorServiceImpl, and replace the predicate
with one that returns early when enableFlag == null ||
!"Y".equalsIgnoreCase(enableFlag) so that validation runs only when the flag is
"Y".

In @android/clientmanager/src/main/res/values/strings.xml:
- Line 15: The message string named err_outside_registration_center uses both
"center" and "centre"; pick one spelling and make them consistent in the string
value (e.g., change both to "center" or both to "centre") so the displayed
message uses the same variant throughout while keeping the existing identifier
err_outside_registration_center unchanged.

🧹 Nitpick comments (3)

android/clientmanager/src/main/java/io/mosip/registration/clientmanager/spi/SyncStatusValidatorService.java (1)

10-24: Consider declaring ClientCheckedException instead of generic Exception.

Both methods throw Exception, but the implementation only throws ClientCheckedException. Declaring the more specific exception type improves API clarity and enables callers to handle validation failures distinctly.

♻️ Suggested refinement

-    void validateSyncStatus() throws Exception;
+    void validateSyncStatus() throws ClientCheckedException;
...
-    void validateCenterToMachineDistance(Double machineLongitude, Double machineLatitude) throws Exception;
+    void validateCenterToMachineDistance(Double machineLongitude, Double machineLatitude) throws ClientCheckedException;

android/clientmanager/src/main/java/io/mosip/registration/clientmanager/service/SyncStatusValidatorServiceImpl.java (2)

3-5: Remove unused import.

SharedPreferences is imported but never used in this class.

🧹 Suggested fix

 import android.content.Context;
-import android.content.SharedPreferences;
 import android.util.Log;

---

273-277: Inconsistent handling of missing data.

When center details or center list is unavailable (lines 256-267), validation is skipped. However, when center coordinates are missing, an exception is thrown. Consider consistent behavior—either skip validation (if this is expected in some setups) or fail consistently for all missing center data.

📜 Review details

Configuration used: Repository UI

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between b041cc2 and 7bcdaee.

📒 Files selected for processing (3)

• android/clientmanager/src/main/java/io/mosip/registration/clientmanager/service/SyncStatusValidatorServiceImpl.java
• android/clientmanager/src/main/java/io/mosip/registration/clientmanager/spi/SyncStatusValidatorService.java
• android/clientmanager/src/main/res/values/strings.xml

🧰 Additional context used

🧬 Code graph analysis (1)

android/clientmanager/src/main/java/io/mosip/registration/clientmanager/service/SyncStatusValidatorServiceImpl.java (4)

android/clientmanager/src/main/java/io/mosip/registration/clientmanager/constant/RegistrationConstants.java (1)

• RegistrationConstants (9-148)

android/clientmanager/src/main/java/io/mosip/registration/clientmanager/repository/GlobalParamRepository.java (1)

• GlobalParamRepository (21-254)

android/clientmanager/src/main/java/io/mosip/registration/clientmanager/repository/RegistrationCenterRepository.java (1)

• RegistrationCenterRepository (11-39)

android/clientmanager/src/main/java/io/mosip/registration/clientmanager/repository/SyncJobDefRepository.java (1)

• SyncJobDefRepository (18-39)

🔇 Additional comments (3)

android/clientmanager/src/main/java/io/mosip/registration/clientmanager/service/SyncStatusValidatorServiceImpl.java (3)

74-91: LGTM!

The exception handling properly distinguishes between expected validation failures and unexpected errors, with appropriate logging.

---

148-157: Verify the boundary condition for overdue detection.

Using <= means a job with configuredFrequency=7 is marked overdue when actualDays=7 (exactly at the limit). If the intent is "must sync within N days," the job should be overdue only after exceeding the limit (i.e., actualDays > configuredFrequency).

Please confirm whether a sync performed exactly at the configured frequency limit should block registration. If "within N days" is the requirement, consider:

-                if (configuredFrequency <= actualDays) {
+                if (actualDays > configuredFrequency) {

---

223-231: LGTM!

The day calculation logic correctly uses day-level granularity with appropriate null handling.

[coderabbitai]

Actionable comments posted: 1

🤖 Fix all issues with AI agents

In
@android/clientmanager/src/main/java/io/mosip/registration/clientmanager/service/SyncStatusValidatorServiceImpl.java:
- Around line 148-157: The condition treating syncs as overdue uses <= which
flags jobs that ran exactly at the configured interval; change the comparison in
the sync validation block that references configuredFrequency and actualDays to
use a strict greater-than (actualDays > configuredFrequency) so only jobs that
exceeded the configuredFrequency increment syncFailureCount, append to
errorDetails, and log the overdue message for jobId/apiName; update the
conditional around the existing syncFailureCount++, errorDetails.append(...),
and Log.w(...) accordingly.

🧹 Nitpick comments (1)

android/clientmanager/src/main/java/io/mosip/registration/clientmanager/service/SyncStatusValidatorServiceImpl.java (1)

75-75: Consider more specific exception declaration.

The method signature declares throws Exception, which is very broad. Consider declaring throws ClientCheckedException or a more specific exception type to improve type safety and make the contract clearer to callers.

♻️ Suggested improvement

-    public void validateSyncStatus() throws Exception {
+    public void validateSyncStatus() throws ClientCheckedException {

📜 Review details

Configuration used: Repository UI

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 7bcdaee and 2e6383d.

📒 Files selected for processing (2)

• android/clientmanager/src/main/java/io/mosip/registration/clientmanager/service/SyncStatusValidatorServiceImpl.java
• android/clientmanager/src/main/res/values/strings.xml

🚧 Files skipped from review as they are similar to previous changes (1)

• android/clientmanager/src/main/res/values/strings.xml

🔇 Additional comments (5)

android/clientmanager/src/main/java/io/mosip/registration/clientmanager/service/SyncStatusValidatorServiceImpl.java (5)

35-47: LGTM: Clean dependency injection setup.

The singleton service is properly structured with all dependencies declared as private fields and injected via constructor using Dagger.

---

49-67: LGTM: Constructor follows Dagger injection pattern.

All dependencies are properly assigned. Dagger's DI contract ensures non-null values at runtime.

---

181-215: LGTM: Proper configuration retrieval with null safety.

The method correctly builds property names from constants, retrieves configuration values, and filters out invalid entries (null, empty, or literal "null" strings). Good defensive programming.

---

223-231: LGTM: Day calculation is mathematically correct.

The integer division at line 229 truncates partial days (e.g., 5 days 23 hours becomes 5 days), which is the expected behavior for calculating whole days since last sync.

---

241-316: LGTM: Robust GPS distance validation with proper error handling.

The method correctly:

• Checks GPS enable flag and coordinates availability with early returns
• Retrieves center details with null safety
• Calculates and converts distance (km to meters)
• Uses strict > comparison at line 301 (machines at exactly the max distance are allowed)
• Handles parsing exceptions and missing configurations appropriately

[coderabbitai]

Actionable comments posted: 1

Caution

Some comments are outside the diff and can’t be posted inline due to platform limitations.

⚠️ Outside diff range comments (1)

android/clientmanager/src/main/java/io/mosip/registration/clientmanager/constant/RegistrationConstants.java (1)

3-7: Remove duplicate import statement.

Line 5 contains a duplicate import of java.util.ArrayList (also imported on Line 4).

🧹 Proposed fix

 import java.sql.Array;
 import java.util.ArrayList;
-import java.util.ArrayList;
 import java.util.Arrays;
 import java.util.List;

🤖 Fix all issues with AI agents

In
@android/clientmanager/src/main/java/io/mosip/registration/clientmanager/service/RegistrationServiceImpl.java:
- Around line 200-210: The GPS distance validation is never reached because
registrationDto.getGeoLocationDto() is not populated before validation; move the
validateCenterToMachineDistance(...) call out of the constructor/init path and
execute it after the location is set (i.e., after setMachineLocation() in
RegistrationApi.java) or call registrationDto.setGeoLocation(...) prior to this
validation; specifically, ensure
syncStatusValidatorService.validateCenterToMachineDistance(...) is invoked in
the same flow/method that sets the geo location (or add a post-location-capture
hook) so validateCenterToMachineDistance(...) runs with a non-null
registrationDto.getGeoLocationDto().

🧹 Nitpick comments (1)

android/clientmanager/src/main/java/io/mosip/registration/clientmanager/constant/RegistrationConstants.java (1)

148-152: Consider more specific names for generic string builder constants.

The constants DOT and FREQUENCY are very generic and could potentially be reused in unrelated contexts, making the code harder to maintain. If these are specifically for building sync validation configuration keys, consider more descriptive names like SYNC_KEY_DOT and SYNC_KEY_FREQUENCY, or consolidate key construction into a helper method.

Alternative approach

If these constants are only used to build configuration keys like "mosip.registration.{jobId}.frequency", consider a helper method instead:

// Instead of public generic constants, use a helper method
public static String buildSyncFrequencyKey(String jobId) {
    return "mosip.registration." + jobId + ".frequency";
}

This eliminates the need for public DOT and FREQUENCY constants while making the intent clearer.

📜 Review details

Configuration used: Repository UI

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 2e6383d and b6aa552.

📒 Files selected for processing (2)

• android/clientmanager/src/main/java/io/mosip/registration/clientmanager/constant/RegistrationConstants.java
• android/clientmanager/src/main/java/io/mosip/registration/clientmanager/service/RegistrationServiceImpl.java

🔇 Additional comments (3)

android/clientmanager/src/main/java/io/mosip/registration/clientmanager/service/RegistrationServiceImpl.java (2)

71-71: LGTM: Service wiring is correct.

The SyncStatusValidatorService is properly imported, declared as a field, added to the constructor, and assigned. The dependency injection follows the established pattern in this class.

Also applies to: 118-118, 136-137, 153-153

---

576-579: LGTM: Sync status validation is properly integrated.

The validation is correctly placed in the pre-check sequence before registration begins. The null check is defensive and consistent with other service checks in this method (Lines 582, 587, 592). The comment clearly explains the purpose of the validation.

android/clientmanager/src/main/java/io/mosip/registration/clientmanager/constant/RegistrationConstants.java (1)

121-123: LGTM: GPS and registration option constants are well-defined.

The new constants GEO_CAP_FREQ, OPT_TO_REG_OUTSIDE_LOCATION, and OPT_TO_REG_LAST_CAPTURED_TIME follow the existing naming conventions and are appropriately placed near related GPS configuration constants.

[coderabbitai]

Actionable comments posted: 4

🤖 Fix all issues with AI agents

In
@android/clientmanager/src/main/java/io/mosip/registration/clientmanager/service/RegistrationServiceImpl.java:
- Around line 200-210: The distance validation block is dead because
registrationDto.getGeoLocationDto() is null at startRegistration(); move the
check out of startRegistration() and into a point after setMachineLocation() is
called (or into packet submission) so GPS is guaranteed to be present.
Specifically, remove or disable the validateCenterToMachineDistance call in
RegistrationServiceImpl.startRegistration(), and invoke
syncStatusValidatorService.validateCenterToMachineDistance(...) after
setMachineLocation(...) completes (or inside the packet creation/submission
flow), keeping the same exception handling (catch ClientCheckedException,
Log.e(TAG,...), rethrow) and using
registrationDto.getGeoLocationDto().getLongitude()/getLatitude() as before.

In
@android/clientmanager/src/main/java/io/mosip/registration/clientmanager/service/SyncStatusValidatorServiceImpl.java:
- Around line 241-316: In validateCenterToMachineDistance, when
getCachedStringGpsDeviceEnableFlag() is "Y" do not silently skip if
machineLongitude or machineLatitude are null: replace the early return for null
machine coords with a thrown ClientCheckedException (use the same client error
pattern/context as other failures, e.g., new ClientCheckedException(context,
R.string.err_004)) so GPS-enabled mode enforces presence of device location;
also update the NumberFormatException log message in the catch block from
"Invalid center coordinates format" to "Invalid number format in center
coordinates or max distance configuration" and include the exception object in
the log to reflect that Double.parseDouble(maxDistanceStr) can fail.

🧹 Nitpick comments (4)

android/clientmanager/src/main/java/io/mosip/registration/clientmanager/service/RegistrationServiceImpl.java (2)

118-154: Make SyncStatusValidatorService a required injected dependency (avoid silent validation bypass).

Right now syncStatusValidatorService is constructor-injected but all call sites guard it with != null, which can hide DI misconfiguration and silently skip “must-run” validations (sync-status and distance). Prefer enforcing non-null via constructor and dropping the null checks (or failing fast).

Proposed adjustment

@@
-    private SyncStatusValidatorService syncStatusValidatorService;
+    private final SyncStatusValidatorService syncStatusValidatorService;
@@
     public RegistrationServiceImpl(Context context, PacketWriterService packetWriterService,
@@
-                                   PacketService packetService,
-                                   SyncStatusValidatorService syncStatusValidatorService) {
+                                   PacketService packetService,
+                                   SyncStatusValidatorService syncStatusValidatorService) {
@@
         this.packetService = packetService;
-        this.syncStatusValidatorService = syncStatusValidatorService;
+        if (syncStatusValidatorService == null) {
+            throw new IllegalArgumentException("syncStatusValidatorService must not be null");
+        }
+        this.syncStatusValidatorService = syncStatusValidatorService;
     }

---

200-210: Redundant catch/rethrow (log once at the boundary).

Catching ClientCheckedException, logging, and rethrowing doesn’t change behavior. If you want centralized logging, prefer logging at the API boundary (where errors are presented to callers) to avoid double logs; otherwise remove the try/catch.

android/clientmanager/src/main/java/io/mosip/registration/clientmanager/service/SyncStatusValidatorServiceImpl.java (2)

40-67: Prefer final fields for injected dependencies.

These are constructor-injected and never reassigned; marking them final reduces accidental mutation and improves thread-safety/readability.

Proposed adjustment

@@
-    private Context context;
-    private SyncJobDefRepository syncJobDefRepository;
-    private GlobalParamRepository globalParamRepository;
-    private JobManagerService jobManagerService;
-    private JobTransactionService jobTransactionService;
-    private LocationValidationService locationValidationService;
-    private MasterDataService masterDataService;
-    private RegistrationCenterRepository registrationCenterRepository;
+    private final Context context;
+    private final SyncJobDefRepository syncJobDefRepository;
+    private final GlobalParamRepository globalParamRepository;
+    private final JobManagerService jobManagerService;
+    private final JobTransactionService jobTransactionService;
+    private final LocationValidationService locationValidationService;
+    private final MasterDataService masterDataService;
+    private final RegistrationCenterRepository registrationCenterRepository;

---

223-231: Day calculation: consider java.time / TimeUnit to avoid edge cases.

The integer division is OK, but using TimeUnit.MILLISECONDS.toDays(...) or java.time.Instant + ChronoUnit.DAYS is clearer and avoids “magic numbers”.

📜 Review details

Configuration used: Repository UI

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between b6aa552 and d3e9f33.

📒 Files selected for processing (2)

• android/clientmanager/src/main/java/io/mosip/registration/clientmanager/service/RegistrationServiceImpl.java
• android/clientmanager/src/main/java/io/mosip/registration/clientmanager/service/SyncStatusValidatorServiceImpl.java

🔇 Additional comments (2)

android/clientmanager/src/main/java/io/mosip/registration/clientmanager/service/RegistrationServiceImpl.java (1)

576-579: Sync-status pre-check placement looks good; ensure it’s “fail-closed” if required.

Calling validateSyncStatus() inside doPreChecksBeforeRegistration(...) is the right place to block early. As above, consider removing the syncStatusValidatorService != null guard if this validation is mandatory.

android/clientmanager/src/main/java/io/mosip/registration/clientmanager/service/SyncStatusValidatorServiceImpl.java (1)

181-215: No issue: MOSIP_REGISTRATION constant already includes the required dot separator.

The constant MOSIP_REGISTRATION = "mosip.registration." already includes the trailing dot, so the propertyName is correctly formatted as mosip.registration.{apiName}.frequency. The key format is valid and will not cause silent lookup failures due to missing separators.

Likely an incorrect or invalid review comment.

[coderabbitai]

Actionable comments posted: 2

🤖 Fix all issues with AI agents

In `@lib/ui/process_ui/widgets/language_selector.dart`:
- Around line 85-106: The fetchLocation call can hang because
Geolocator.getCurrentPosition lacks a timeLimit; update the fetchLocation
implementation to pass a timeLimit (e.g., Duration(seconds:10)) to
Geolocator.getCurrentPosition and ensure it returns null or throws a controlled
exception on timeout, and additionally defend the UI call in
language_selector.dart by wrapping globalProvider.fetchLocation() with a timeout
(e.g., .timeout(Duration(seconds:10), onTimeout: () => null)) so the await in
the widget (where globalProvider.fetchLocation() is called before
startRegistration) will not block indefinitely; keep existing try/catch/null
checks around the position and preserve passing latitude/longitude into
registrationTaskProvider.startRegistration.

In `@pigeon/registration_data.dart`:
- Around line 14-17: The RegistrationDataApi signature (startRegistration with
nullable double? latitude and longitude) is correct but the generated Pigeon
bindings are missing; run the pigeon generator script (./pigeon.sh) to produce
the Dart and platform artifacts referenced by registration_service_impl.dart:
lib/pigeon/registration_data_pigeon.dart,
android/app/src/main/java/io/mosip/registration_client/model/RegistrationDataPigeon.java,
and ios/Runner/pigeon.h and ios/Runner/pigeon.m; ensure the generated files are
created locally (they remain gitignored) so the
RegistrationDataApi/startRegistration changes compile and the Pigeon API calls
in RegistrationServiceImpl work.

♻️ Duplicate comments (2)

android/clientmanager/src/main/java/io/mosip/registration/clientmanager/service/SyncStatusValidatorServiceImpl.java (2)

115-127: Policy consideration: missing config or sync history allows registration to proceed.

The current implementation skips validation (allows registration) when:

• Configured frequency is missing/blank (lines 116-118)
• No sync history exists (lines 125-127)

If the intent is strict enforcement of sync requirements, these cases should fail-closed instead of skip. If this is intentional for backwards compatibility or gradual rollout, consider documenting this behavior.

---

216-218: Verify intended behavior: missing machine coordinates bypass validation when GPS is enabled.

When enableFlag is "Y" (GPS validation enabled), null machineLongitude or machineLatitude causes the method to return without validating. If GPS validation should be enforced when enabled, this should throw an error rather than silently skip.

If this is intentional fallback behavior (e.g., for devices without GPS hardware), consider documenting this decision.

🧹 Nitpick comments (2)

android/clientmanager/src/main/java/io/mosip/registration/clientmanager/service/SyncStatusValidatorServiceImpl.java (2)

74-85: Acceptable error handling, but consider a dedicated error code for sync validation failures.

The catch-all mapping to err_004 is defensive but may obscure the actual failure mode. If distinct error messaging is needed for debugging or UX, consider adding a specific error code for "sync validation failed unexpectedly."

---

272-274: Improve exception message accuracy.

The NumberFormatException can be thrown by either center coordinate parsing (lines 245-246) or max distance parsing (line 260). The current log message "Invalid center coordinates format" doesn't cover the latter case.

📝 Suggested improvement

         } catch (NumberFormatException e) {
-            Log.e(TAG, "Invalid center coordinates format", e);
+            Log.e(TAG, "Invalid number format in center coordinates or max distance configuration", e);
             throw new ClientCheckedException(context, R.string.err_004);
         }

[coderabbitai]

Actionable comments posted: 0

Caution

Some comments are outside the diff and can’t be posted inline due to platform limitations.

⚠️ Outside diff range comments (1)

lib/provider/global_provider.dart (1)

887-923: Handle TimeoutException from getCurrentPosition to preserve null-on-failure contract.

Geolocator.getCurrentPosition() with timeLimit throws TimeoutException when position acquisition exceeds the specified duration. The current code lacks exception handling, which will cause unhandled exceptions to escape despite the method contract stating it returns null on failure. Wrap the call in a try-catch block and return null on timeout to maintain consistency:

Suggested fix

   // Fetch location if permission is granted
   // Add timeout to prevent indefinite hanging
-  return await Geolocator.getCurrentPosition(
-    desiredAccuracy: LocationAccuracy.high,
-    timeLimit: const Duration(seconds: 10),
-  );
+  try {
+    return await Geolocator.getCurrentPosition(
+      desiredAccuracy: LocationAccuracy.high,
+      timeLimit: const Duration(seconds: 10),
+    );
+  } on TimeoutException {
+    return null;
+  }

🧹 Nitpick comments (4)

lib/ui/process_ui/widgets/language_selector.dart (1)

99-119: Add a mounted guard before using context after awaits.

This async flow now includes more awaited work; guard against setState/navigation on a disposed widget.

♻️ Proposed fix

     await registrationTaskProvider.startRegistration(
         langList,
         widget.newProcess.flow! == "UPDATE"
             ? "Update"
             : widget.newProcess.flow!,
         widget.newProcess.id!,
         latitude: latitude,
         longitude: longitude);
 
+    if (!mounted) return;
+
     registrationTaskProvider.addDemographicField("preferredLang",
         globalProvider.fieldInputValue["preferredLang"].toString());
     String registrationStartError =
         registrationTaskProvider.registrationStartError;

android/clientmanager/src/main/java/io/mosip/registration/clientmanager/service/SyncStatusValidatorServiceImpl.java (3)

4-4: Remove unused import.

SharedPreferences is imported but not used anywhere in this class.

-import android.content.SharedPreferences;

---

40-47: Consider making fields final for immutability.

Since these dependencies are set once in the constructor and never reassigned, marking them final documents the intent and prevents accidental modification.

-    private Context context;
-    private SyncJobDefRepository syncJobDefRepository;
-    private GlobalParamRepository globalParamRepository;
-    private JobManagerService jobManagerService;
-    private JobTransactionService jobTransactionService;
-    private LocationValidationService locationValidationService;
-    private MasterDataService masterDataService;
-    private RegistrationCenterRepository registrationCenterRepository;
+    private final Context context;
+    private final SyncJobDefRepository syncJobDefRepository;
+    private final GlobalParamRepository globalParamRepository;
+    private final JobManagerService jobManagerService;
+    private final JobTransactionService jobTransactionService;
+    private final LocationValidationService locationValidationService;
+    private final MasterDataService masterDataService;
+    private final RegistrationCenterRepository registrationCenterRepository;

---

250-281: Consider broader exception handling for getDistance() call.

The try-catch block only handles NumberFormatException. If locationValidationService.getDistance() throws a different exception (e.g., IllegalArgumentException for invalid coordinates), it will propagate with a raw error message rather than a user-friendly message.

Suggested improvement

         } catch (NumberFormatException e) {
             Log.e(TAG, "Invalid number format in center coordinates or max distance configuration", e);
             throw new ClientCheckedException(context, R.string.err_004);
+        } catch (Exception e) {
+            Log.e(TAG, "Error during distance validation", e);
+            throw new ClientCheckedException(context, R.string.err_004);
         }

[coderabbitai]

Actionable comments posted: 3

🤖 Fix all issues with AI agents

In
`@android/clientmanager/src/main/java/io/mosip/registration/clientmanager/spi/PreCheckValidatorService.java`:
- Around line 18-22: The Javadoc contract for PreCheckValidatorService is
inconsistent with the implementation: update the documentation for the method
that validates machine distance (the one with parameters machineLongitude and
machineLatitude) to state that validation is only skipped when GPS is disabled
and that when GPS is enabled the coordinates are required (non-null) and an
Exception will be thrown if they are missing or the machine is outside the
allowed distance; ensure the method signature and throws clause remain unchanged
and mirror the implementation semantics so tests/docs and
PreCheckValidatorService implementation are aligned.

In
`@android/clientmanager/src/test/java/io/mosip/registration/clientmanager/service/RegistrationServiceImplTest.java`:
- Around line 1873-2043: The test uses verify(preCheckValidatorService,
never()).validateCenterToMachineDistance(anyDouble(), anyDouble()) which can
miss calls with null args; update the assertions to ensure no invocation
actually happened by either using verifyNoInteractions(preCheckValidatorService)
or changing the matcher to null-tolerant matchers (e.g.,
verify(preCheckValidatorService, never()).validateCenterToMachineDistance(any(),
any()) or use isNull() for the specific null-arg cases) for the tests around
validateCenterToMachineDistance so the verification fails if the method was
called with nulls.

In `@lib/provider/global_provider.dart`:
- Around line 944-948: The call to Geolocator.getCurrentPosition with a
timeLimit can throw a TimeoutException which is currently uncaught; inside the
surrounding method (the method that calls Geolocator.getCurrentPosition in
global_provider.dart) wrap the await Geolocator.getCurrentPosition(...) call in
a try/catch that catches TimeoutException (from dart:async) and returns null on
timeout, while preserving existing exception handling for other error paths;
ensure dart:async is imported if not already and only convert the timeout case
to a null return so the method's contract stays consistent.

[coderabbitai]

Actionable comments posted: 1

🤖 Fix all issues with AI agents

In `@assets/l10n/app_kn.arb`:
- Line 305: Fix the formatting in the "errors" select string by inserting a
missing space between the closing brace of PAK_DISK_SPACE_LOW{...} and the next
selector REG_PKT_APPRVL_CNT_EXCEED; locate the "errors" entry in
assets/l10n/app_kn.arb and add a single space before "REG_PKT_APPRVL_CNT_EXCEED"
so the selectors are consistently separated (match the spacing used in the
English locale).

[coderabbitai]

Actionable comments posted: 1

🤖 Fix all issues with AI agents

In `@assets/l10n/app_kn.arb`:
- Line 305: The OPT_TO_REG_OUTSIDE_LOCATION option in the "errors" select
mapping is missing terminal punctuation; update the OPT_TO_REG_OUTSIDE_LOCATION
message inside the "errors" string (symbol OPT_TO_REG_OUTSIDE_LOCATION) to end
with a sentence-ending punctuation mark (e.g., add a full stop "।" or "."
consistent with other Kannada messages) while preserving the surrounding select
syntax and quoting.