V1.6

[naveenr-egov]

No description provided.

[coderabbitai]

Important

Review skipped

Review was skipped as selected files did not have any reviewable changes.

💤 Files selected but had no reviewable changes (1)

• packages/complaints/example/ios/Podfile

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Walkthrough

This pull request introduces significant architectural changes to the Health Campaign Field Worker App, focusing on replacing checklist functionality with survey forms and integrating a new complaints management system. The modifications span multiple files and modules, restructuring routing, localization, showcase configurations, and synchronization mechanisms. Key changes include removing checklist-related components, adding survey form and complaints packages, and updating the application's core functionality to support these new features.

Changes

File/Directory	Change Summary
.gitignore	Added entries to ignore FVM (Flutter Version Management) files
README.md	Updated documentation with Flutter version requirements, Mason configuration, and data synchronization details
android/...	Updated Gradle configurations, build scripts, and Kotlin/Java versions
lib/app.dart	Added imports for survey form and remote client, updated bloc configurations
lib/blocs/...	Refactored bloc logic, added error handling, and integrated new synchronization mechanisms
lib/router/...	Replaced checklist routes with survey form and complaints routes
lib/utils/...	Updated constants, localization, and utility functions to support new features
lib/widgets/...	Modified showcase configurations and UI components

Sequence Diagram

sequenceDiagram
    participant User
    participant App
    participant SurveyFormModule
    participant ComplaintsModule
    participant SyncService

    User->>App: Open Application
    App->>SyncService: Initialize Sync
    SyncService-->>App: Sync Status
    User->>App: Navigate to Survey Forms
    App->>SurveyFormModule: Load Survey Forms
    SurveyFormModule-->>App: Display Survey Forms
    User->>App: Navigate to Complaints
    App->>ComplaintsModule: Load Complaints
    ComplaintsModule-->>App: Display Complaints

Loading

Possibly related PRs

• Develop #427: .gitignore modifications for FVM
• packages stable release #431: .gitignore file updates
• Publishing digit_firbase_services initial release #585: Initial release of digit_firebase_services package

Suggested reviewers

• naveen-egov

Poem

🐰 A Rabbit's Tale of Code Renewal 🌱

Checklists fade, survey forms arise,
Complaints now dance before our eyes,
Sync services sing a brand new song,
Refactored paths where code belongs!

Hop, hop, hurray! The changes bloom! 🌈

---

Thank you for using CodeRabbit. We offer it for free to the OSS community and would appreciate your support in helping us grow. If you find it useful, would you consider giving us a shout-out on your favorite social media?

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

🪧 Tips

Chat

There are 3 ways to chat with CodeRabbit:

• Review comments: Directly reply to a review comment made by CodeRabbit. Example:
  • I pushed a fix in commit <commit_id>, please review it.
  • Generate unit testing code for this file.
  • Open a follow-up GitHub issue for this discussion.
• Files and specific lines of code (under the "Files changed" tab): Tag @coderabbitai in a new review comment at the desired location with your query. Examples:
  • @coderabbitai generate unit testing code for this file.
  • @coderabbitai modularize this function.
• PR comments: Tag @coderabbitai in a new PR comment to ask questions about the PR branch. For the best results, please provide a very specific query, as very limited context is provided in this mode. Examples:
  • @coderabbitai gather interesting stats about this repository and render them as a table. Additionally, render a pie chart showing the language distribution in the codebase.
  • @coderabbitai read src/utils.ts and generate unit testing code.
  • @coderabbitai read the files in the src/scheduler package and generate a class diagram using mermaid and a README in the markdown format.
  • @coderabbitai help me debug CodeRabbit configuration file.

Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments.

CodeRabbit Commands (Invoked using PR comments)

• @coderabbitai pause to pause the reviews on a PR.
• @coderabbitai resume to resume the paused reviews.
• @coderabbitai review to trigger an incremental review. This is useful when automatic reviews are disabled for the repository.
• @coderabbitai full review to do a full review from scratch and review all the files again.
• @coderabbitai summary to regenerate the summary of the PR.
• @coderabbitai resolve resolve all the CodeRabbit review comments.
• @coderabbitai configuration to show the current CodeRabbit configuration for the repository.
• @coderabbitai help to get help.

Other keywords and placeholders

• Add @coderabbitai ignore anywhere in the PR description to prevent this PR from being reviewed.
• Add @coderabbitai summary to generate the high-level summary at a specific location in the PR description.
• Add @coderabbitai anywhere in the PR title to generate the title automatically.

CodeRabbit Configuration File (.coderabbit.yaml)

• You can programmatically configure CodeRabbit by adding a .coderabbit.yaml file to the root of your repository.
• Please see the configuration documentation for more information.
• If your editor has YAML language server enabled, you can add the path at the top of this file to enable auto-completion and validation: # yaml-language-server: $schema=https://coderabbit.ai/integrations/schema.v2.json

Documentation and Community

• Visit our Documentation for detailed information on how to use CodeRabbit.
• Join our Discord Community to get help, request features, and share feedback.
• Follow us on X/Twitter for updates and announcements.

[coderabbitai]

Actionable comments posted: 14

🔭 Outside diff range comments (4)

apps/health_campaign_field_worker_app/lib/widgets/showcase/showcase_button.dart (2)

Line range hint 73-102: Standardize route name handling for consistency

The switch statement mixes string literals with route constants (e.g., "ManageStocksRoute" vs ComplaintTypeRoute.name). Consider using route constants consistently throughout.

-case "ManageStocksRoute":
+case ManageStocksRoute.name:
-case "WarehouseDetailsRoute":
+case WarehouseDetailsRoute.name:
-case "StockReconciliationRoute":
+case StockReconciliationRoute.name:

---

Based on the gathered information, I can now provide the final response:

Survey form routes need showcase configurations

The survey form routes (SurveyformRoute, SurveyFormBoundaryViewRoute, SurveyFormViewRoute, SurveyFormPreviewRoute, SurveyFormAcknowledgementRoute) are defined but missing from the showcase configurations in ShowcaseButton widget's _showcasePathsForRoute method. These routes should have corresponding showcase data similar to other routes.

Key locations that need attention:

• apps/health_campaign_field_worker_app/lib/widgets/showcase/showcase_button.dart: Add cases for survey form routes
• apps/health_campaign_field_worker_app/lib/widgets/showcase/config/showcase_constants.dart: Define showcase data for survey form routes

🔗 Analysis chain

Line range hint 73-102: Verify showcase paths for new survey form routes

The checklist routes have been removed, but there's no corresponding addition of showcase paths for the new survey form routes mentioned in the PR summary.

---

Let me gather more specific information about the survey form routes and their showcase configurations.

---

Let me check the showcase widget implementation and survey form routes more specifically.

🏁 Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Search for survey form related routes and showcase configurations
rg -l "survey.*route|survey.*showcase" --type dart

# Search for any remaining checklist references that might need cleanup
rg -l "checklist" --type dart

Length of output: 2516

---

Script:

#!/bin/bash
# Check the router configuration for survey form routes
rg "survey.*route" -A 5 -B 5 apps/health_campaign_field_worker_app/lib/router/app_router.dart

# Check showcase related configurations in the app
rg "showcase.*data" -A 5 -B 5 apps/health_campaign_field_worker_app/lib/widgets/showcase/

# Look for any survey form related showcase configurations
rg "survey.*showcase" -A 5 -B 5 apps/health_campaign_field_worker_app/

Length of output: 970

---

Script:

#!/bin/bash
# Check the showcase button widget implementation
cat apps/health_campaign_field_worker_app/lib/widgets/showcase/showcase_button.dart

# Check survey form router implementation
cat packages/survey_form/lib/router/survey_form_router.dart

# Look for any showcase related constants or data
rg -g "!*.g.dart" -g "!*.freezed.dart" "showcase" apps/health_campaign_field_worker_app/lib/

Length of output: 14871

apps/health_campaign_field_worker_app/android/app/src/main/kotlin/com/digit/hcm/location_service.kt (1)

Line range hint 147-166: Add error handling for external storage access.

The file writing implementation needs better error handling.

Consider this safer implementation:

 private fun writeToFile(data: String) {
+    if (!isExternalStorageWritable()) {
+        Log.e("LocationService", "External storage is not writable")
+        return
+    }
     try {
         val fileName = "location_data.txt"
         val file: File
 
         // Access Downloads folder
         val downloadsFolder = File(getExternalFilesDir(Environment.DIRECTORY_DOWNLOADS), "")
+        if (!downloadsFolder.exists() && !downloadsFolder.mkdirs()) {
+            Log.e("LocationService", "Failed to create downloads directory")
+            return
+        }
         file = File(downloadsFolder, fileName)
 
+        // Implement file rotation if size exceeds limit
+        if (file.exists() && file.length() > MAX_FILE_SIZE) {
+            rotateLogFile(file)
+        }
 
         val fileOutputStream = FileOutputStream(file, true) // Append mode
-        fileOutputStream.write((data + "\n").toByteArray())
-        fileOutputStream.close()
+        fileOutputStream.use { stream ->
+            stream.write((data + "\n").toByteArray())
+        }
 
         // Print the file path
         println("File saved at: ${file.absolutePath}")
     } catch (e: Exception) {
-        e.printStackTrace()
+        Log.e("LocationService", "Failed to write location data", e)
     }
 }

apps/health_campaign_field_worker_app/lib/blocs/projects_beneficiary_downsync/project_beneficiaries_downsync.dart (1)

Missing error handling in sync operations could lead to silent failures

Based on the verification results:

• The writeToEntityDB operation is not wrapped in a try-catch block
• No error states or error handling patterns were found in the bloc implementation
• The sync service implementation shows nested calls without error handling

Action items:

• Wrap the SyncServiceSingleton().entityMapper?.writeToEntityDB() call in a try-catch block
• Add appropriate error states in the bloc to handle sync failures
• Propagate errors from the sync service to the UI layer

🔗 Analysis chain

Line range hint 204-213: Verify error handling in the new sync implementation.

While the switch to SyncServiceSingleton is good for centralization, we should ensure proper error handling for the batch write operation.

---

Let me gather more information about error handling patterns in the sync implementation.

---

Let me check one more aspect to see how errors are handled in the bloc and entity mapper.

🏁 Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Description: Check for error handling patterns in sync service usage
# Test: Look for try-catch blocks around sync service calls
rg -A 5 "SyncServiceSingleton\(\)\.entityMapper.*writeToEntityDB" 

# Test: Look for error handling in the sync service implementation
ast-grep --pattern 'try {
  $$$
  writeToEntityDB($$$)
  $$$
} catch ($$$) {
  $$$
}'

Length of output: 572

---

Script:

#!/bin/bash
# Check for try-catch blocks in the file containing the sync call
rg -B 5 -A 10 "await SyncServiceSingleton\(\)" apps/health_campaign_field_worker_app/lib/blocs/projects_beneficiary_downsync/project_beneficiaries_downsync.dart

# Look for error handling in the sync service implementation
rg -B 5 -A 10 "writeToEntityDB" packages/sync_service/lib/data/sync_service.dart

# Check bloc implementation for error states
ast-grep --pattern 'class ProjectBeneficiariesDownsyncState {
  $$$
}'

Length of output: 1716

---

Script:

#!/bin/bash
# Check for error handling in the bloc implementation
rg -B 10 -A 10 "emit\(.*Error" apps/health_campaign_field_worker_app/lib/blocs/projects_beneficiary_downsync/project_beneficiaries_downsync.dart

# Check entity mapper implementation for error handling
rg -B 5 -A 10 "class EntityMapper" packages/sync_service/lib/data/sync_service.dart

# Look for try-catch blocks in the bloc file
ast-grep --pattern 'try {
  $$$
} catch ($$$) {
  $$$
  emit($$$Error$$$)
  $$$
}'

Length of output: 317

🧹 Nitpick comments (37)

apps/health_campaign_field_worker_app/lib/widgets/showcase/config/survey_form_data.dart (1)

12-24: Consider adding more essential survey form fields to the showcase.

The current implementation only showcases date and administrative unit fields. Consider adding more essential survey form elements that users might need guidance on, such as:

• Form submission buttons
• Required field indicators
• Validation error messages
• File attachment fields (if applicable)

Example addition:

 List<ShowcaseItemBuilder> get showcaseData => [
   date,
   administrativeUnit,
+  submitButton,
+  requiredFields,
+  validationErrors,
 ];

+final submitButton = ShowcaseItemBuilder(
+  messageLocalizationKey: i18.surveyFormDataShowcase.submitButton,
+);
+
+final requiredFields = ShowcaseItemBuilder(
+  messageLocalizationKey: i18.surveyFormDataShowcase.requiredFields,
+);
+
+final validationErrors = ShowcaseItemBuilder(
+  messageLocalizationKey: i18.surveyFormDataShowcase.validationErrors,
+);

apps/health_campaign_field_worker_app/lib/data/repositories/remote/mdms.dart (1)

Line range hint 403-407: Consider using async transaction for better performance

The synchronous transaction (writeTxnSync) for writing configuration data could potentially block the main thread. Consider using the asynchronous version (writeTxn) instead, especially given the large amount of data being written.

-    isar.writeTxnSync(() {
-      isar.appConfigurations.putSync(appConfiguration);
-      isar.rowVersionLists.putAllSync(rowVersionList);
-    });
+    await isar.writeTxn(() async {
+      await isar.appConfigurations.put(appConfiguration);
+      await isar.rowVersionLists.putAll(rowVersionList);
+    });

apps/health_campaign_field_worker_app/lib/widgets/showcase/showcase_button.dart (1)

Line range hint 73-102: Consider refactoring route-to-showcase mapping for better maintainability

The switch statement could be replaced with a more maintainable mapping structure.

Consider refactoring to use a map:

-  Iterable<GlobalKey>? _showcasePathsForRoute(String routeName) {
-    switch (routeName) {
-      case "ManageStocksRoute":
-        return selectStockShowcaseData.showcaseData.map(
-          (e) => e.showcaseKey,
-        );
-      // ... other cases
-      default:
-        return null;
-    }
-  }
+  static final _routeShowcaseMap = <String, ShowcaseData>{
+    ManageStocksRoute.name: selectStockShowcaseData,
+    WarehouseDetailsRoute.name: warehouseDetailsShowcaseData,
+    StockReconciliationRoute.name: stockReconciliationShowcaseData,
+    ComplaintTypeRoute.name: complaintTypeShowcaseData,
+    // ... other mappings
+  };
+
+  Iterable<GlobalKey>? _showcasePathsForRoute(String routeName) {
+    return _routeShowcaseMap[routeName]?.showcaseData.map((e) => e.showcaseKey);
+  }

This approach would:

• Make it easier to add/remove routes
• Reduce the cognitive complexity
• Make the relationship between routes and showcase data more explicit

apps/health_campaign_field_worker_app/lib/widgets/showcase/config/survey_form_list.dart (1)

3-9: Consider renaming the class to follow Dart naming conventions

The class name _SurveyFormListShowcaseData is private but represents a significant component. Consider removing the underscore prefix and making it public since it's already encapsulated within a part file. This would improve code readability while maintaining the singleton pattern's integrity.

-class _SurveyFormListShowcaseData {
+class SurveyFormListShowcaseData {
   static final _SurveyFormListShowcaseData _instance =
       _SurveyFormListShowcaseData._();

apps/health_campaign_field_worker_app/android/app/build.gradle (1)

63-69: Document the USE_GOOGLE_SERVICES property usage.

Good practice to conditionally disable Google Services tasks, but consider adding documentation about:

1. When to use the USE_GOOGLE_SERVICES property
2. How to configure it in different environments

Consider adding a comment block above this section:

+    // Conditionally disable Google Services tasks when USE_GOOGLE_SERVICES property is not set
+    // To enable Google Services, set -PUSE_GOOGLE_SERVICES in gradle.properties or command line
     if (!project.hasProperty('USE_GOOGLE_SERVICES')) {

apps/health_campaign_field_worker_app/lib/data/sync_registry.dart (4)

14-22: Bulk update error handling
The try-catch approach for bulk updates is straightforward. Ensure that the error-handling logic (currently just printing to debug) sufficiently alerts users or logs in production.

---

23-30: Bulk delete error handling
As with the update method, ensure any failures get surfaced up or logged in a way that can trigger retries or alerts.

---

32-39: Single create usage
The single-create flow is concise. Validate any server-side response or success state before continuing. Consider returning a success flag or additional data for the caller to use.

---

41-120: Conditional creation logic for complaints
• The code handling complaints is well-structured, covering the parse of PgrServiceCreateResponseModel and subsequent local updates.
• Consider verifying partial failures. If multiple complaints are created and some fail, you may want more granular error-handling or rollback logic.
• Ensure the skip in line 64 is correct; if an unknown or malformed response is encountered, you might want to set a non-recoverable error or handle re-sync attempts.

apps/health_campaign_field_worker_app/lib/utils/utils.dart (2)

96-97: Enhanced connectivity check
Using “connectivityResult.firstOrNull” is a thoughtful way to handle potential empty streams. Double-check that your fallback logic or offline handling still covers all edge cases.

---

403-404: Extending mapper initialization
Adding both survey_form_mappers and complaints_mappers to the initialization routine ensures new data models are recognized. If initialization duration grows, consider asynchronous or lazy loading for performance.

apps/health_campaign_field_worker_app/lib/router/app_router.gr.dart (1)

142-143: Ensure newly added routes are adequately covered in integration tests
The newly added SurveyFormRoute and ComplaintsRoute appear essential to the updated architecture. Consider adding integration tests or route-level tests to ensure these routes function correctly without regressions.

apps/health_campaign_field_worker_app/lib/blocs/project/project.dart (2)

299-301: Clarify TODO or INFO comment
There’s an “INFO” marker referencing adding “project load functions”. Elaborate or remove it to avoid confusion among collaborators. Possibly create a ticket or story if further tasks remain.

---

Line range hint 374-386: Limit query for facility data
Using “limit: batchSize” ensures facilities are fetched in manageable chunks. That’s efficient. Confirm that bridging logic for paged data is implemented if total results exceed batchSize.

apps/health_campaign_field_worker_app/lib/pages/home.dart (4)

121-122: Consistency in theme usage
Using surface color for the Scaffold background is in line with the Material theme. Check for related references in other screens to keep your UI consistent.

---

323-330: Add user feedback upon lodging complaints
You introduced the “fileComplaint” item. Consider providing immediate feedback or a success dialog when users file or view a complaint. This improves the user experience.

---

504-505: Showcase consistency
The new “mySurveyForm” showcase key ensures proper highlighting in your UI tour. Validate that the rest of your new complaint and survey items have a related showcase if desired.

---

716-735: SurveyFormSingleton initialization
The new “SurveyFormSingleton” uses multiple context-based fields, like project name and user roles. This is handy for dynamic forms. Ensure you handle role or project changes gracefully if user logs out or re-authenticates mid-session.

apps/health_campaign_field_worker_app/lib/data/sync_service_mapper.dart (2)

16-86: Centralize “writeToEntityDB” logic
This method iterates over each key in the response and bulk creates the mapped objects. Looks straightforward. Consider dividing the large switch statement by entity type into smaller, well-tested helper methods for easier maintainability.

---

88-132: Optimize getSyncCount approach
Filtering opLogs for syncable entities ensures you count only the correct ones. If performance becomes an issue, consider segmenting by sync status or indexing for large volumes of logs.

apps/health_campaign_field_worker_app/lib/data/repositories/remote/bandwidth_check.dart (1)

Line range hint 15-31: Review bandwidth calculation assumptions.

The current implementation:

1. Uses a fixed 800 bytes assumption which may not reflect actual payload size
2. Doesn't account for network conditions variability
3. Lacks documentation for the speed calculation formula

Consider:

1. Using actual response size instead of fixed 800 bytes
2. Implementing multiple ping attempts for better accuracy
3. Adding documentation explaining the calculation methodology

apps/health_campaign_field_worker_app/lib/utils/localization_delegates.dart (1)

40-42: Consider improving code documentation

The comment "Need to add package delegates here" could be more descriptive about the delegate initialization order or any specific requirements.

-    // INFO : Need to add package delegates here
+    // Package delegates are initialized in order of dependency.
+    // Add new delegates below while maintaining initialization order.

apps/health_campaign_field_worker_app/lib/data/repositories/local/localization.dart (1)

86-110: Consider adding pagination for large result sets.

While the error handling is robust, fetching all results at once could be memory-intensive for large datasets.

Consider adding pagination support:

 FutureOr<List<Localization>> fetchLocalization(
     {required LocalSqlDataStore sql,
      required String locale,
-     required String module}) async {
+     required String module,
+     int? limit,
+     int? offset}) async {
   return retryLocalCallOperation(() async {
     final query = sql.select(sql.localization).join([])
       ..where(
         buildOr([
           sql.localization.locale.equals(locale),
           sql.localization.module.contains(module),
         ]),
       );
+    if (limit != null) query.limit(limit, offset: offset);

apps/health_campaign_field_worker_app/lib/utils/extensions/context_utility.dart (2)

231-234: Consider adding error handling for sync refresh

While the implementation is correct, it would be beneficial to add error handling to catch potential exceptions when accessing the SyncBloc.

 void syncRefresh() {
+  try {
     final syncBloc = _get<SyncBloc>();
     syncBloc.add(SyncRefreshEvent(loggedInUserUuid));
+  } catch (e) {
+    debugPrint('Failed to refresh sync: $e');
+  }
 }

---

237-240: Consider adding error handling for sync count stream

Similar to syncRefresh, the syncCount method should handle potential errors when accessing the SyncBloc.

 Stream<SyncState> syncCount() {
+  try {
     final syncBloc = _get<SyncBloc>();
     return syncBloc.stream;
+  } catch (e) {
+    debugPrint('Failed to get sync count stream: $e');
+    return Stream.empty();
+  }
 }

apps/health_campaign_field_worker_app/lib/router/app_router.dart (2)

96-110: Consider adding route documentation

While the survey form routes are well-structured, adding documentation comments would improve maintainability.

+ /// Wrapper route for all survey form related pages
 AutoRoute(
   page: SurveyFormWrapperRoute.page,
   path: 'surveyForm',
   children: [
+    /// Main survey form page
     AutoRoute(
       page: SurveyformRoute.page,
       path: '',
     ),
+    /// View for boundary-specific survey forms
     AutoRoute(
       page: SurveyFormBoundaryViewRoute.page,
       path: 'view-boundary'
     ),
     // Add documentation for remaining routes...
   ]
 ),

---

Line range hint 140-193: Consider grouping related routes

The complaints routes could be organized more efficiently by grouping related functionality.

Consider extracting the complaints routes into a separate router module for better maintainability:

+ /// Create a separate complaints router module
+ @AutoRouterConfig(name: 'ComplaintsRouter')
+ class ComplaintsRouterModule {
+   static List<AutoRoute> get routes => [
+     AutoRoute(
+       page: ComplaintsInboxWrapperRoute.page,
+       // ... existing routes
+     ),
+     AutoRoute(
+       page: ComplaintsRegistrationWrapperRoute.page,
+       // ... existing routes
+     ),
+     AutoRoute(
+       page: ComplaintsAcknowledgementRoute.page,
+       // ... existing routes
+     ),
+   ];
+ }

- // Replace existing routes with module import
+ ...ComplaintsRouterModule.routes,

apps/health_campaign_field_worker_app/lib/pages/language_selection.dart (1)

158-165: Simplify the module string construction

The current implementation spans multiple lines and could be more readable.

- module: 'hcm-boundary-${envConfig.variables.hierarchyType.toLowerCase()},${localizationModulesList
-     .map((e)
-   =>
-     e.name.toString()
-   )
-     .join(',')
-     .toString()
- }',
+ module: [
+   'hcm-boundary-${envConfig.variables.hierarchyType.toLowerCase()}',
+   ...localizationModulesList.map((e) => e.name.toString()),
+ ].join(','),

apps/health_campaign_field_worker_app/lib/widgets/sidebar/side_bar.dart (2)

131-132: Consider extracting the module string construction to a utility method

The current implementation combines multiple string components inline, which could be better organized for maintainability and reusability.

Consider creating a utility method:

+String getLocalizationModule(String hierarchyType, List<String> moduleNames) {
+  return 'hcm-boundary-${hierarchyType.toLowerCase()},${moduleNames.join(',')}';
+}

// Usage:
-module: "hcm-boundary-${envConfig.variables.hierarchyType.toLowerCase()},${localizationModulesList.interfaces.where((element) => element.type == Modules.localizationModule).map((e) => e.name.toString()).join(',')}",
+module: getLocalizationModule(
+  envConfig.variables.hierarchyType,
+  localizationModulesList.interfaces
+    .where((element) => element.type == Modules.localizationModule)
+    .map((e) => e.name.toString())
+    .toList(),
+),

---

180-182: Consider handling all connectivity types

The current implementation only checks for WiFi and mobile connectivity but might miss other valid connection types like ethernet.

Consider using a more comprehensive check:

-final isOnline = connectivityResult.firstOrNull ==
-        ConnectivityResult.wifi ||
-    connectivityResult.firstOrNull == ConnectivityResult.mobile;
+final isOnline = connectivityResult.firstOrNull != null && 
+    connectivityResult.firstOrNull != ConnectivityResult.none;

apps/health_campaign_field_worker_app/lib/pages/reports/beneficiary/beneficaries_report.dart (3)

36-46: Consider initializing syncSubscription as non-nullable

The sync-related changes look good, moving from direct bloc usage to a subscription pattern. However, since syncSubscription is marked as late and nullable (StreamSubscription?), consider initializing it as non-nullable to prevent potential null-related issues.

-  late StreamSubscription? syncSubscription;
+  late StreamSubscription syncSubscription;

---

94-326: Consider refactoring state handling for better maintainability

The state handling logic is comprehensive but could benefit from refactoring:

1. Extract dialog showing logic into separate methods to reduce code duplication
2. Consider using a map of state handlers to reduce nesting
3. Group related states together for better organization

Example refactor pattern:

final stateHandlers = {
  'loading': (isPop) => _handleLoadingState(isPop),
  'getBatchSize': (params) => _handleBatchSizeState(params),
  // ... other handlers
};

void _handleLoadingState(bool isPop) {
  if (isPop) {
    Navigator.of(context, rootNavigator: true)
        .popUntil((route) => route is! PopupRoute);
  }
  _showProgressDialog('Loading');
}

void _showProgressDialog(String label) {
  DigitSyncDialog.show(
    context,
    type: DigitSyncDialogType.inProgress,
    label: label,
    barrierDismissible: false,
  );
}

---

430-440: Consider adding error handling to sync count listener

While the sync count listener implementation is clean, consider adding error handling:

 void listenToSyncCount() async {
   syncSubscription = context.syncCount().listen(
     (state) {
       state.maybeWhen(
         orElse: () {},
         pendingSync: (count) {
           setState(() {
             pendingSyncCount = count;
           });
         },
+        error: (error) {
+          // Handle error state
+          debugPrint('Sync count error: $error');
+        },
       );
-    });
+    },
+    onError: (error) {
+      debugPrint('Sync count subscription error: $error');
+    },
+  );
 }

apps/health_campaign_field_worker_app/lib/utils/i18_key_constants.dart (1)

Line range hint 357-374: Consider updating showcase class names for clarity

The showcase classes still contain references to "checklist" in their string keys while their class names have been updated to "survey form". Consider updating the string keys for consistency.

 class SurveyFormDataShowcase {
   const SurveyFormDataShowcase();
 
   String get date {
-    return 'CHECKLIST_DATA_SHOWCASE_DATE';
+    return 'SURVEY_FORM_DATA_SHOWCASE_DATE';
   }
 
   String get administrativeUnit {
-    return 'CHECKLIST_DATA_SHOWCASE_ADMINISTRATIVE_UNIT';
+    return 'SURVEY_FORM_DATA_SHOWCASE_ADMINISTRATIVE_UNIT';
   }
 }

apps/health_campaign_field_worker_app/lib/pages/boundary_selection.dart (2)

703-713: Consider handling sync errors

The sync count listener doesn't handle potential errors in the stream.

Consider adding error handling:

void listenToSyncCount() async {
-  syncSubscription = context.syncCount().listen((state) {
+  syncSubscription = context.syncCount().listen(
+    (state) {
      state.maybeWhen(
        orElse: () {},
        pendingSync: (count) {
          setState(() {
            pendingSyncCount = count;
          });
        });
+    },
+    onError: (error) {
+      // Handle error, maybe show a snackbar or log
+    },
+  );
}

---

132-139: Simplify ListView padding logic

Adding an extra item to the ListView just for padding is not the most efficient approach.

Consider using padding on the ListView itself:

-itemCount: labelList.length+1,
+itemCount: labelList.length,
-if (labelIndex == labelList.length) {
-  return const SizedBox(height: kPadding*3);
-}
+padding: const EdgeInsets.only(bottom: kPadding * 3),

packages/attendance_management/CHANGELOG.md (1)

33-35: Fix markdown formatting inconsistencies

The list formatting is inconsistent with the rest of the document.

Update the formatting:

* Features:
-    - Manage Attendance: Mark attendance of the employees and send the data to parent application.
-    - Select Session: Select the session for which the attendance is to be marked.
-    - Mark Attendance: Mark the attendance of the employees.
+  * Manage Attendance: Mark attendance of the employees and send the data to parent application.
+  * Select Session: Select the session for which the attendance is to be marked.
+  * Mark Attendance: Mark the attendance of the employees.

🧰 Tools

🪛 Markdownlint (0.37.0)

33-33: Expected: asterisk; Actual: dash
Unordered list style

(MD004, ul-style)

---

34-34: Expected: asterisk; Actual: dash
Unordered list style

(MD004, ul-style)

---

35-35: Expected: asterisk; Actual: dash
Unordered list style

(MD004, ul-style)

---

33-33: Expected: 2; Actual: 4
Unordered list indentation

(MD007, ul-indent)

---

34-34: Expected: 2; Actual: 4
Unordered list indentation

(MD007, ul-indent)

---

35-35: Expected: 2; Actual: 4
Unordered list indentation

(MD007, ul-indent)

📜 Review details

Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 5595f37 and 87af814.

⛔ Files ignored due to path filters (75)

• .github/workflows/dart.yml is excluded by !**/*.yml
• .github/workflows/flutter-build-apk.yml is excluded by !**/*.yml
• apps/health_campaign_field_worker_app/android/app/src/main/AndroidManifest.xml is excluded by !**/*.xml
• apps/health_campaign_field_worker_app/assets/animated_json/alert.json is excluded by !**/*.json
• apps/health_campaign_field_worker_app/assets/animated_json/error.json is excluded by !**/*.json
• apps/health_campaign_field_worker_app/assets/animated_json/inline_loader.json is excluded by !**/*.json
• apps/health_campaign_field_worker_app/assets/animated_json/overlay_loader.json is excluded by !**/*.json
• apps/health_campaign_field_worker_app/assets/animated_json/page_loader.json is excluded by !**/*.json
• apps/health_campaign_field_worker_app/assets/animated_json/success.json is excluded by !**/*.json
• apps/health_campaign_field_worker_app/pubspec.lock is excluded by !**/*.lock, !**/*.lock
• apps/health_campaign_field_worker_app/pubspec.yaml is excluded by !**/*.yaml
• mason_templates/digit_entity/hooks/pubspec.lock is excluded by !**/*.lock, !**/*.lock
• mason_templates/digit_entity/hooks/pubspec.yaml is excluded by !**/*.yaml
• mason_templates/freezed_bloc/hooks/pubspec.lock is excluded by !**/*.lock, !**/*.lock
• mason_templates/freezed_bloc/hooks/pubspec.yaml is excluded by !**/*.yaml
• melos.yaml is excluded by !**/*.yaml
• packages/attendance_management/pubspec.lock is excluded by !**/*.lock, !**/*.lock
• packages/attendance_management/pubspec.yaml is excluded by !**/*.yaml
• packages/auto_route/pubspec.lock is excluded by !**/*.lock, !**/*.lock
• packages/closed_household/pubspec.lock is excluded by !**/*.lock, !**/*.lock
• packages/closed_household/pubspec.yaml is excluded by !**/*.yaml
• packages/complaints/analysis_options.yaml is excluded by !**/*.yaml
• packages/complaints/assets/animated_json/alert.json is excluded by !**/*.json
• packages/complaints/assets/animated_json/error.json is excluded by !**/*.json
• packages/complaints/assets/animated_json/success.json is excluded by !**/*.json
• packages/complaints/assets/icons/svg/no_result.svg is excluded by !**/*.svg, !**/*.svg
• packages/complaints/example/analysis_options.yaml is excluded by !**/*.yaml
• packages/complaints/example/android/app/src/debug/AndroidManifest.xml is excluded by !**/*.xml
• packages/complaints/example/android/app/src/main/AndroidManifest.xml is excluded by !**/*.xml
• packages/complaints/example/android/app/src/main/res/drawable-v21/launch_background.xml is excluded by !**/*.xml
• packages/complaints/example/android/app/src/main/res/drawable/launch_background.xml is excluded by !**/*.xml
• packages/complaints/example/android/app/src/main/res/mipmap-hdpi/ic_launcher.png is excluded by !**/*.png, !**/*.png
• packages/complaints/example/android/app/src/main/res/mipmap-mdpi/ic_launcher.png is excluded by !**/*.png, !**/*.png
• packages/complaints/example/android/app/src/main/res/mipmap-xhdpi/ic_launcher.png is excluded by !**/*.png, !**/*.png
• packages/complaints/example/android/app/src/main/res/mipmap-xxhdpi/ic_launcher.png is excluded by !**/*.png, !**/*.png
• packages/complaints/example/android/app/src/main/res/mipmap-xxxhdpi/ic_launcher.png is excluded by !**/*.png, !**/*.png
• packages/complaints/example/android/app/src/main/res/values-night/styles.xml is excluded by !**/*.xml
• packages/complaints/example/android/app/src/main/res/values/styles.xml is excluded by !**/*.xml
• packages/complaints/example/android/app/src/profile/AndroidManifest.xml is excluded by !**/*.xml
• packages/complaints/example/ios/Runner/Assets.xcassets/AppIcon.appiconset/Contents.json is excluded by !**/*.json
• packages/complaints/example/ios/Runner/Assets.xcassets/AppIcon.appiconset/[email protected] is excluded by !**/*.png, !**/*.png
• packages/complaints/example/ios/Runner/Assets.xcassets/AppIcon.appiconset/[email protected] is excluded by !**/*.png, !**/*.png
• packages/complaints/example/ios/Runner/Assets.xcassets/AppIcon.appiconset/[email protected] is excluded by !**/*.png, !**/*.png
• packages/complaints/example/ios/Runner/Assets.xcassets/AppIcon.appiconset/[email protected] is excluded by !**/*.png, !**/*.png
• packages/complaints/example/ios/Runner/Assets.xcassets/AppIcon.appiconset/[email protected] is excluded by !**/*.png, !**/*.png
• packages/complaints/example/ios/Runner/Assets.xcassets/AppIcon.appiconset/[email protected] is excluded by !**/*.png, !**/*.png
• packages/complaints/example/ios/Runner/Assets.xcassets/AppIcon.appiconset/[email protected] is excluded by !**/*.png, !**/*.png
• packages/complaints/example/ios/Runner/Assets.xcassets/AppIcon.appiconset/[email protected] is excluded by !**/*.png, !**/*.png
• packages/complaints/example/ios/Runner/Assets.xcassets/AppIcon.appiconset/[email protected] is excluded by !**/*.png, !**/*.png
• packages/complaints/example/ios/Runner/Assets.xcassets/AppIcon.appiconset/[email protected] is excluded by !**/*.png, !**/*.png
• packages/complaints/example/ios/Runner/Assets.xcassets/AppIcon.appiconset/[email protected] is excluded by !**/*.png, !**/*.png
• packages/complaints/example/ios/Runner/Assets.xcassets/AppIcon.appiconset/[email protected] is excluded by !**/*.png, !**/*.png
• packages/complaints/example/ios/Runner/Assets.xcassets/AppIcon.appiconset/[email protected] is excluded by !**/*.png, !**/*.png
• packages/complaints/example/ios/Runner/Assets.xcassets/AppIcon.appiconset/[email protected] is excluded by !**/*.png, !**/*.png
• packages/complaints/example/ios/Runner/Assets.xcassets/AppIcon.appiconset/[email protected] is excluded by !**/*.png, !**/*.png
• packages/complaints/example/ios/Runner/Assets.xcassets/AppIcon.appiconset/[email protected] is excluded by !**/*.png, !**/*.png
• packages/complaints/example/ios/Runner/Assets.xcassets/AppIcon.appiconset/[email protected] is excluded by !**/*.png, !**/*.png
• packages/complaints/example/ios/Runner/Assets.xcassets/AppIcon.appiconset/[email protected] is excluded by !**/*.png, !**/*.png
• packages/complaints/example/ios/Runner/Assets.xcassets/AppIcon.appiconset/[email protected] is excluded by !**/*.png, !**/*.png
• packages/complaints/example/ios/Runner/Assets.xcassets/AppIcon.appiconset/[email protected] is excluded by !**/*.png, !**/*.png
• packages/complaints/example/ios/Runner/Assets.xcassets/AppIcon.appiconset/[email protected] is excluded by !**/*.png, !**/*.png
• packages/complaints/example/ios/Runner/Assets.xcassets/LaunchImage.imageset/Contents.json is excluded by !**/*.json
• packages/complaints/example/ios/Runner/Assets.xcassets/LaunchImage.imageset/LaunchImage.png is excluded by !**/*.png, !**/*.png
• packages/complaints/example/ios/Runner/Assets.xcassets/LaunchImage.imageset/[email protected] is excluded by !**/*.png, !**/*.png
• packages/complaints/example/ios/Runner/Assets.xcassets/LaunchImage.imageset/[email protected] is excluded by !**/*.png, !**/*.png
• packages/complaints/example/lib/localization_strings.json is excluded by !**/*.json
• packages/complaints/example/pubspec.lock is excluded by !**/*.lock, !**/*.lock
• packages/complaints/example/pubspec.yaml is excluded by !**/*.yaml
• packages/complaints/pubspec.lock is excluded by !**/*.lock, !**/*.lock
• packages/complaints/pubspec.yaml is excluded by !**/*.yaml
• packages/dart_mappable_builder/pubspec.yaml is excluded by !**/*.yaml
• packages/digit_components/example/pubspec.lock is excluded by !**/*.lock, !**/*.lock
• packages/digit_components/example/pubspec.yaml is excluded by !**/*.yaml
• packages/digit_components/pubspec.lock is excluded by !**/*.lock, !**/*.lock
• packages/digit_components/pubspec.yaml is excluded by !**/*.yaml

📒 Files selected for processing (82)

• .gitignore (1 hunks)
• README.md (1 hunks)
• apps/health_campaign_field_worker_app/.gitignore (1 hunks)
• apps/health_campaign_field_worker_app/android/app/build.gradle (4 hunks)
• apps/health_campaign_field_worker_app/android/app/src/main/kotlin/com/digit/hcm/MainActivity.kt (2 hunks)
• apps/health_campaign_field_worker_app/android/app/src/main/kotlin/com/digit/hcm/location_service.kt (2 hunks)
• apps/health_campaign_field_worker_app/android/build.gradle (0 hunks)
• apps/health_campaign_field_worker_app/android/gradle/wrapper/gradle-wrapper.properties (1 hunks)
• apps/health_campaign_field_worker_app/android/settings.gradle (1 hunks)
• apps/health_campaign_field_worker_app/lib/app.dart (3 hunks)
• apps/health_campaign_field_worker_app/lib/blocs/app_initialization/app_initialization.dart (1 hunks)
• apps/health_campaign_field_worker_app/lib/blocs/localization/app_localizations_delegate.dart (0 hunks)
• apps/health_campaign_field_worker_app/lib/blocs/project/project.dart (11 hunks)
• apps/health_campaign_field_worker_app/lib/blocs/projects_beneficiary_downsync/project_beneficiaries_downsync.dart (3 hunks)
• apps/health_campaign_field_worker_app/lib/data/data_manager.dart (0 hunks)
• apps/health_campaign_field_worker_app/lib/data/local_store/no_sql/schema/entity_mapper.dart (1 hunks)
• apps/health_campaign_field_worker_app/lib/data/network_manager.dart (0 hunks)
• apps/health_campaign_field_worker_app/lib/data/repositories/local/localization.dart (1 hunks)
• apps/health_campaign_field_worker_app/lib/data/repositories/remote/bandwidth_check.dart (1 hunks)
• apps/health_campaign_field_worker_app/lib/data/repositories/remote/mdms.dart (1 hunks)
• apps/health_campaign_field_worker_app/lib/data/repositories/sync/remote_type.dart (0 hunks)
• apps/health_campaign_field_worker_app/lib/data/repositories/sync/sync_down.dart (0 hunks)
• apps/health_campaign_field_worker_app/lib/data/repositories/sync/sync_up.dart (0 hunks)
• apps/health_campaign_field_worker_app/lib/data/sync_registry.dart (1 hunks)
• apps/health_campaign_field_worker_app/lib/data/sync_service_mapper.dart (1 hunks)
• apps/health_campaign_field_worker_app/lib/main.dart (0 hunks)
• apps/health_campaign_field_worker_app/lib/models/bandwidth/bandwidth_model.dart (0 hunks)
• apps/health_campaign_field_worker_app/lib/models/downsync/downsync.mapper.dart (4 hunks)
• apps/health_campaign_field_worker_app/lib/models/entities/additional_fields_type.mapper.dart (1 hunks)
• apps/health_campaign_field_worker_app/lib/models/entities/mdms_master_enums.mapper.dart (1 hunks)
• apps/health_campaign_field_worker_app/lib/models/entities/mdms_module_enums.mapper.dart (1 hunks)
• apps/health_campaign_field_worker_app/lib/models/entities/roles.mapper.dart (1 hunks)
• apps/health_campaign_field_worker_app/lib/models/entities/roles_type.mapper.dart (1 hunks)
• apps/health_campaign_field_worker_app/lib/models/entities/scanner_type.mapper.dart (1 hunks)
• apps/health_campaign_field_worker_app/lib/models/entities/status.dart (1 hunks)
• apps/health_campaign_field_worker_app/lib/models/entities/status.mapper.dart (1 hunks)
• apps/health_campaign_field_worker_app/lib/pages/authenticated.dart (5 hunks)
• apps/health_campaign_field_worker_app/lib/pages/boundary_selection.dart (6 hunks)
• apps/health_campaign_field_worker_app/lib/pages/checklist/checklist.dart (0 hunks)
• apps/health_campaign_field_worker_app/lib/pages/checklist/checklist_boundary_view.dart (0 hunks)
• apps/health_campaign_field_worker_app/lib/pages/checklist/checklist_preview.dart (0 hunks)
• apps/health_campaign_field_worker_app/lib/pages/checklist/checklist_view.dart (0 hunks)
• apps/health_campaign_field_worker_app/lib/pages/complaints/inbox/complaints_details_view.dart (0 hunks)
• apps/health_campaign_field_worker_app/lib/pages/complaints/inbox/complaints_inbox.dart (0 hunks)
• apps/health_campaign_field_worker_app/lib/pages/complaints/inbox/complaints_inbox_filter.dart (0 hunks)
• apps/health_campaign_field_worker_app/lib/pages/complaints/inbox/complaints_inbox_search.dart (0 hunks)
• apps/health_campaign_field_worker_app/lib/pages/complaints/inbox/complaints_inbox_sort.dart (0 hunks)
• apps/health_campaign_field_worker_app/lib/pages/complaints/registration/complaint_type.dart (0 hunks)
• apps/health_campaign_field_worker_app/lib/pages/complaints/registration/complaints_details.dart (0 hunks)
• apps/health_campaign_field_worker_app/lib/pages/complaints/registration/complaints_location.dart (0 hunks)
• apps/health_campaign_field_worker_app/lib/pages/complaints/registration/complaints_registration_wrapper.dart (0 hunks)
• apps/health_campaign_field_worker_app/lib/pages/complaints_acknowledgement.dart (0 hunks)
• apps/health_campaign_field_worker_app/lib/pages/home.dart (12 hunks)
• apps/health_campaign_field_worker_app/lib/pages/language_selection.dart (2 hunks)
• apps/health_campaign_field_worker_app/lib/pages/profile.dart (3 hunks)
• apps/health_campaign_field_worker_app/lib/pages/project_facility_selection.dart (2 hunks)
• apps/health_campaign_field_worker_app/lib/pages/reports/beneficiary/beneficaries_report.dart (4 hunks)
• apps/health_campaign_field_worker_app/lib/router/app_router.dart (6 hunks)
• apps/health_campaign_field_worker_app/lib/router/app_router.gr.dart (1 hunks)
• apps/health_campaign_field_worker_app/lib/utils/background_service.dart (2 hunks)
• apps/health_campaign_field_worker_app/lib/utils/constants.dart (12 hunks)
• apps/health_campaign_field_worker_app/lib/utils/extensions/context_utility.dart (2 hunks)
• apps/health_campaign_field_worker_app/lib/utils/extensions/extensions.dart (2 hunks)
• apps/health_campaign_field_worker_app/lib/utils/i18_key_constants.dart (5 hunks)
• apps/health_campaign_field_worker_app/lib/utils/localization_delegates.dart (5 hunks)
• apps/health_campaign_field_worker_app/lib/utils/typedefs.dart (0 hunks)
• apps/health_campaign_field_worker_app/lib/utils/utils.dart (4 hunks)
• apps/health_campaign_field_worker_app/lib/widgets/header/back_navigation_help_header.dart (1 hunks)
• apps/health_campaign_field_worker_app/lib/widgets/network_manager_provider_wrapper.dart (5 hunks)
• apps/health_campaign_field_worker_app/lib/widgets/showcase/config/checklist_data.dart (0 hunks)
• apps/health_campaign_field_worker_app/lib/widgets/showcase/config/checklist_list.dart (0 hunks)
• apps/health_campaign_field_worker_app/lib/widgets/showcase/config/home_showcase.dart (2 hunks)
• apps/health_campaign_field_worker_app/lib/widgets/showcase/config/select_checklist.dart (0 hunks)
• apps/health_campaign_field_worker_app/lib/widgets/showcase/config/select_survey_form.dart (1 hunks)
• apps/health_campaign_field_worker_app/lib/widgets/showcase/config/showcase_constants.dart (2 hunks)
• apps/health_campaign_field_worker_app/lib/widgets/showcase/config/survey_form_data.dart (1 hunks)
• apps/health_campaign_field_worker_app/lib/widgets/showcase/config/survey_form_list.dart (1 hunks)
• apps/health_campaign_field_worker_app/lib/widgets/showcase/showcase_button.dart (1 hunks)
• apps/health_campaign_field_worker_app/lib/widgets/sidebar/side_bar.dart (6 hunks)
• mason_templates/digit_entity/hooks/lib/models.mapper.dart (5 hunks)
• packages/attendance_management/CHANGELOG.md (2 hunks)
• packages/attendance_management/lib/blocs/attendance_bloc.dart (1 hunks)

⛔ Files not processed due to max files limit (20)

• packages/attendance_management/lib/blocs/attendance_individual_bloc.dart
• packages/attendance_management/lib/data/repositories/remote/attendance_logs.dart
• packages/attendance_management/lib/data/repositories/remote/attendance_register.dart
• packages/attendance_management/lib/models/entities/attendance_log.mapper.dart
• packages/attendance_management/lib/models/entities/attendance_register.mapper.dart
• packages/attendance_management/lib/models/entities/attendee.mapper.dart
• packages/attendance_management/lib/models/entities/enum_values.mapper.dart
• packages/attendance_management/lib/models/entities/register_status.mapper.dart
• packages/attendance_management/lib/models/entities/staff.mapper.dart
• packages/attendance_management/lib/pages/manage_attendance.dart
• packages/attendance_management/lib/pages/mark_attendance.dart
• packages/attendance_management/lib/pages/session_select.dart
• packages/attendance_management/lib/router/attendance_router.dart
• packages/attendance_management/lib/router/attendance_router.gm.dart
• packages/attendance_management/lib/utils/date_util_attendance.dart
• packages/attendance_management/lib/widgets/attendance_acknowledgement.dart
• packages/attendance_management/lib/widgets/back_navigation_help_header.dart
• packages/attendance_management/lib/widgets/circular_button.dart
• packages/attendance_management/lib/widgets/no_result_card.dart
• packages/attendance_management/test/unit/search_attendee_by_name_test.dart

💤 Files with no reviewable changes (27)

• apps/health_campaign_field_worker_app/lib/blocs/localization/app_localizations_delegate.dart
• apps/health_campaign_field_worker_app/lib/models/bandwidth/bandwidth_model.dart
• apps/health_campaign_field_worker_app/lib/widgets/showcase/config/checklist_list.dart
• apps/health_campaign_field_worker_app/lib/main.dart
• apps/health_campaign_field_worker_app/lib/data/repositories/sync/remote_type.dart
• apps/health_campaign_field_worker_app/lib/widgets/showcase/config/select_checklist.dart
• apps/health_campaign_field_worker_app/lib/widgets/showcase/config/checklist_data.dart
• apps/health_campaign_field_worker_app/lib/utils/typedefs.dart
• apps/health_campaign_field_worker_app/android/build.gradle
• apps/health_campaign_field_worker_app/lib/pages/complaints/registration/complaints_registration_wrapper.dart
• apps/health_campaign_field_worker_app/lib/pages/complaints_acknowledgement.dart
• apps/health_campaign_field_worker_app/lib/pages/checklist/checklist_boundary_view.dart
• apps/health_campaign_field_worker_app/lib/pages/complaints/inbox/complaints_details_view.dart
• apps/health_campaign_field_worker_app/lib/data/data_manager.dart
• apps/health_campaign_field_worker_app/lib/pages/complaints/inbox/complaints_inbox_sort.dart
• apps/health_campaign_field_worker_app/lib/data/repositories/sync/sync_up.dart
• apps/health_campaign_field_worker_app/lib/pages/checklist/checklist_view.dart
• apps/health_campaign_field_worker_app/lib/data/network_manager.dart
• apps/health_campaign_field_worker_app/lib/pages/complaints/registration/complaints_details.dart
• apps/health_campaign_field_worker_app/lib/pages/complaints/inbox/complaints_inbox.dart
• apps/health_campaign_field_worker_app/lib/pages/checklist/checklist_preview.dart
• apps/health_campaign_field_worker_app/lib/pages/complaints/registration/complaint_type.dart
• apps/health_campaign_field_worker_app/lib/pages/complaints/registration/complaints_location.dart
• apps/health_campaign_field_worker_app/lib/data/repositories/sync/sync_down.dart
• apps/health_campaign_field_worker_app/lib/pages/checklist/checklist.dart
• apps/health_campaign_field_worker_app/lib/pages/complaints/inbox/complaints_inbox_filter.dart
• apps/health_campaign_field_worker_app/lib/pages/complaints/inbox/complaints_inbox_search.dart

✅ Files skipped from review due to trivial changes (13)

• .gitignore
• apps/health_campaign_field_worker_app/.gitignore
• apps/health_campaign_field_worker_app/lib/models/entities/scanner_type.mapper.dart
• apps/health_campaign_field_worker_app/lib/models/entities/status.dart
• apps/health_campaign_field_worker_app/lib/models/entities/roles_type.mapper.dart
• apps/health_campaign_field_worker_app/lib/models/entities/mdms_module_enums.mapper.dart
• apps/health_campaign_field_worker_app/lib/models/entities/status.mapper.dart
• apps/health_campaign_field_worker_app/lib/models/entities/mdms_master_enums.mapper.dart
• apps/health_campaign_field_worker_app/lib/models/entities/roles.mapper.dart
• apps/health_campaign_field_worker_app/lib/models/entities/additional_fields_type.mapper.dart
• apps/health_campaign_field_worker_app/lib/data/local_store/no_sql/schema/entity_mapper.dart
• apps/health_campaign_field_worker_app/lib/utils/extensions/extensions.dart
• apps/health_campaign_field_worker_app/android/gradle/wrapper/gradle-wrapper.properties

👮 Files not reviewed due to content moderation or server errors (1)

• apps/health_campaign_field_worker_app/lib/utils/constants.dart

🧰 Additional context used

🪛 Markdownlint (0.37.0)

packages/attendance_management/CHANGELOG.md

33-33: Expected: asterisk; Actual: dash
Unordered list style

(MD004, ul-style)

---

34-34: Expected: asterisk; Actual: dash
Unordered list style

(MD004, ul-style)

---

35-35: Expected: asterisk; Actual: dash
Unordered list style

(MD004, ul-style)

---

33-33: Expected: 2; Actual: 4
Unordered list indentation

(MD007, ul-indent)

---

34-34: Expected: 2; Actual: 4
Unordered list indentation

(MD007, ul-indent)

---

35-35: Expected: 2; Actual: 4
Unordered list indentation

(MD007, ul-indent)

🔇 Additional comments (67)

mason_templates/digit_entity/hooks/lib/models.mapper.dart (3)

4-4: LGTM: Lint rule suppression is appropriate for generated code.

The addition of override_on_non_overriding_member to the ignore directives is acceptable as this is a generated file.

---

138-139: LGTM: Improved equality implementation across all model classes.

The changes consistently replace custom equality checks with the mapper's equalsValue method across all mixins. This is a better approach because it:

• Reduces code duplication
• Centralizes equality logic in the mapper
• Makes the code more maintainable

Also applies to: 357-358, 527-528, 716-717

---

Line range hint 1-785: LGTM: Well-structured generated code with consistent patterns.

The generated code maintains:

• Consistent patterns across all model classes
• Type-safe implementations
• Proper null handling
• Clean serialization/deserialization logic

apps/health_campaign_field_worker_app/lib/widgets/showcase/config/survey_form_data.dart (2)

4-11: LGTM! Clean singleton implementation.

The singleton pattern is correctly implemented with a private constructor and factory method.

---

1-2: Verify integration with showcase_constants.dart

As this is a part file, we should ensure that all required types (ShowcaseItemBuilder, i18) are properly exported from the main file.

✅ Verification successful

Let me gather more information to verify the integration completely.

---

Let me check one final thing to verify the ShowcaseItemBuilder type.

---

Integration with showcase_constants.dart is properly configured

The file is correctly integrated as a part file, with all necessary dependencies available:

• The main file showcase_constants.dart properly includes the part declaration
• Required i18 is imported from i18_key_constants.dart
• ShowcaseItemBuilder is available through the imported showcase_wrappers.dart

🏁 Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Description: Verify the main file exports required types and the part declaration

# Check if showcase_constants.dart includes this part file
rg -l "part.*survey_form_data.dart" --type dart

# Check for required type definitions
ast-grep --pattern 'class ShowcaseItemBuilder {
  $$$
}'

Length of output: 198

---

Script:

#!/bin/bash
# Check the content of showcase_constants.dart to verify imports and part declarations
cat apps/health_campaign_field_worker_app/lib/widgets/showcase/config/showcase_constants.dart

# Check for i18 usage/imports in the main file
rg "import.*i18" --type dart apps/health_campaign_field_worker_app/lib/widgets/showcase/config/showcase_constants.dart

Length of output: 1541

---

Script:

#!/bin/bash
# Check for ShowcaseItemBuilder in showcase_wrappers.dart
cat apps/health_campaign_field_worker_app/lib/widgets/showcase/showcase_wrappers.dart

Length of output: 1802

apps/health_campaign_field_worker_app/lib/pages/project_facility_selection.dart (3)

17-19: LGTM! Modern constructor syntax.

The update to use super.key syntax follows Flutter's best practices and makes the code more concise.

---

Line range hint 33-47: Consider integration with new survey form architecture.

Given the PR's objective of replacing checklist functionality with survey forms, consider:

1. How facility selection integrates with the new survey form flow
2. Whether additional fields or validations are needed for the complaints management system
3. If the current filtering logic needs to handle any new facility attributes

---

3-3: Verify the impact of using the barrel import.

While using data_model.dart barrel file improves organization, it might impact tree-shaking and compile times. Consider measuring the impact on bundle size.

apps/health_campaign_field_worker_app/lib/data/repositories/remote/mdms.dart (1)

260-264: 🛠️ Refactor suggestion

Verify consistency of checklist to survey form migration

While the variable renaming from checklist to surveyForm aligns with the architectural changes, the surrounding type names still reference the old terminology (e.g., ChecklistTypes).

Let's verify the consistency of this migration:

Consider updating the type name to maintain consistency:

- final List<ChecklistTypes>? checklistTypes =
+ final List<SurveyFormTypes>? surveyFormTypes =
        element?.checklistTypes.map((e) {
-      final surveyForm = ChecklistTypes()
+      final surveyForm = SurveyFormTypes()
        ..name = e.name
        ..code = e.code;

      return surveyForm;
    }).toList();

apps/health_campaign_field_worker_app/lib/widgets/showcase/config/survey_form_list.dart (2)

1-1: Verify showcase system integration

As this file is part of showcase_constants.dart, let's verify that the showcase system properly integrates this new survey form configuration and that old checklist-related showcase configurations have been removed.

✅ Verification successful

Based on the results, I can now provide a final response. The search results show that:

1. The file survey_form_list.dart is properly integrated as a part of showcase_constants.dart along with other showcase configurations
2. The showcase system has been properly structured with survey form related showcases (_SurveyFormListShowcaseData, _SurveyFormDataShowcaseData, _SelectSurveyFormShowcaseData)
3. There are no references to checklist-related showcase configurations in the codebase
4. The showcase integration follows the same pattern as other features (complaints, stock, etc.)

Integration verified successfully

The showcase system properly integrates the new survey form configuration. The file is correctly set up as a part of showcase_constants.dart and follows the established showcase architecture pattern. No legacy checklist showcase configurations were found.

🏁 Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Check for any remaining checklist showcase references
rg -g '*.dart' "checklist.*showcase" 

# Verify the showcase_constants.dart integration
ast-grep --pattern 'part $_ of "showcase_constants.dart";'

Length of output: 99

---

Script:

#!/bin/bash
# Let's try a broader search to understand the showcase system structure
# First, find the showcase_constants.dart file
fd "showcase_constants.dart"

# Check the content of showcase_constants.dart to understand the part integration
rg -g '*.dart' "^part " --context 2 apps/health_campaign_field_worker_app/lib/widgets/showcase/config/

# Look for any survey form related showcase configurations
rg -g '*.dart' "survey.*showcase" -A 2

# Check for any showcase related classes or configurations
rg -g '*.dart' "class.*Showcase" --context 2

Length of output: 39825

---

11-15: Verify the localization key existence

The showcase message uses the localization key i18.surveyFormListShowcase.open. Let's ensure this key is properly defined in the localization files.

✅ Verification successful

Let me gather more information to verify the localization key properly.

---

Let me search for the i18 constants file and the specific showcase key.

---

Let me check for the SurveyFormListShowcase class definition to verify the 'open' key.

---

Localization key is properly defined and used

The localization key i18.surveyFormListShowcase.open is correctly defined in both the app and package level i18 constants files, returning the string 'CHECKLIST_LIST_SHOWCASE_OPEN'. The implementation is consistent with the codebase's localization pattern.

🏁 Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Search for the localization key definition
rg -g '*.dart' -g '*.json' "surveyFormListShowcase.open"

# Check if the i18 prefix is consistently used across the codebase
ast-grep --pattern 'i18.surveyFormListShowcase.$_'

Length of output: 258

---

Script:

#!/bin/bash
# Search for the i18 class/file definition and surveyFormListShowcase
rg -g '*.dart' "class.*surveyFormListShowcase" -A 5

# Look for i18 instance/import usage
rg -g '*.dart' "^import.*i18" 
rg -g '*.dart' "final.*i18\s*=|const.*i18\s*=" 

Length of output: 13200

---

Script:

#!/bin/bash
# Look for i18 constants file in the app
fd i18_key_constants.dart

# Once found, check its content for surveyFormListShowcase
rg -g 'i18_key_constants.dart' -A 3 "surveyFormListShowcase"

Length of output: 1704

---

Script:

#!/bin/bash
# Search for SurveyFormListShowcase class definition
rg -g '*.dart' "class SurveyFormListShowcase" -A 10

Length of output: 1809

apps/health_campaign_field_worker_app/android/settings.gradle (2)

27-27: LGTM!

The app module inclusion is correctly placed.

---

1-17: LGTM! Verify Flutter SDK path handling across environments.

The plugin management configuration is well-structured with proper null checks for the Flutter SDK path.

Let's verify the Flutter SDK path handling:

✅ Verification successful

Let me verify if there are any other configuration files or documentation that might provide guidance about the Flutter SDK path setup.

---

Flutter SDK path configuration is consistent with project standards

The verification shows this is a standard Flutter project setup where:

• The local.properties file is intentionally not tracked (common practice for Flutter/Android projects)
• The same Flutter SDK path configuration pattern is consistently used across all example apps and the main app
• The assertion in place will properly catch missing SDK configurations during build time

🏁 Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Description: Check if local.properties exists and contains flutter.sdk

# Check if local.properties exists and contains flutter.sdk
if [ -f "local.properties" ]; then
  echo "local.properties exists"
  grep "flutter.sdk" local.properties || echo "flutter.sdk not found in local.properties"
else
  echo "local.properties does not exist"
fi

Length of output: 102

---

Script:

#!/bin/bash
# Check for Flutter SDK path setup in related files and documentation
echo "Checking for relevant files..."
fd -e md -e gradle -e properties -e yaml -e txt

# Look for Flutter SDK related documentation or setup instructions
echo -e "\nSearching for Flutter SDK setup mentions..."
rg -i "flutter.sdk|flutter_sdk|FLUTTER_SDK" --type-add 'config:*.{gradle,properties,yaml,md}'

Length of output: 7713

apps/health_campaign_field_worker_app/android/app/build.gradle (3)

1-6: LGTM! Plugin declarations are consistent.

The plugin declarations match the configuration in settings.gradle and follow a logical order.

---

49-50: LGTM! Proper use of Flutter SDK versions.

Using Flutter's SDK versions for minSdk and targetSdk ensures compatibility with the Flutter framework and its plugins.

---

28-33: Verify Java 17 compatibility with existing codebase.

The upgrade from Java 1.8 to 17 is significant. While this is a good modernization step, we should ensure compatibility with:

1. Existing Java/Kotlin code
2. All dependencies
3. Flutter plugins

Let's check for potential Java version compatibility issues:

Also applies to: 37-37

✅ Verification successful

Let me gather more information about the location service implementation to understand the API level requirements.

---

Java 17 upgrade is safe to proceed

The upgrade from Java 1.8 to 17 is safe because:

1. The only Kotlin code in the app (location_service.kt) uses @TargetApi(Build.VERSION_CODES.ECLAIR) which targets a very old Android API level (API 5) and is fully compatible with Java 17
2. The app uses modern Kotlin version (1.8.22) which supports Java 17
3. No direct Java code is present in the codebase that could be affected
4. All used Android APIs and permissions are compatible with Java 17

🏁 Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Description: Check for Java version dependencies and potential conflicts

# Search for Java version references in Kotlin/Java files
rg -t java -t kotlin "targetCompatibility|sourceCompatibility|jvmTarget" 

# Look for @RequiresApi annotations that might indicate version conflicts
rg -t java -t kotlin "@RequiresApi|@TargetApi"

Length of output: 266

---

Script:

#!/bin/bash
# Check the content of location_service.kt to understand the context of @TargetApi
cat "apps/health_campaign_field_worker_app/android/app/src/main/kotlin/com/digit/hcm/location_service.kt"

# Search for any build.gradle files that might have Java/Android version configurations
fd "build.gradle" --exec cat {}

# Look for any Android manifest files to check minimum SDK version
fd "AndroidManifest.xml" --exec cat {}

Length of output: 33053

apps/health_campaign_field_worker_app/lib/data/sync_registry.dart (2)

1-8: Imports and naming clarity
The imports are consistent and relevant for complaint handling and synchronization. Consider consistently naming your complaint-related imports (e.g., pgr or pgr_service) to avoid confusion.

---

127-140: Skipping local sync for complaints
The logic cleanly prevents marking complaints as synced in localMarkSyncUp, which aligns with the dedicated complaint workflow. Confirm that skipping them here won’t cause confusion for any downstream sync status checks.

apps/health_campaign_field_worker_app/lib/utils/background_service.dart (2)

19-20: New synchronization imports
Introducing the sync_service and bandwidth_model imports clarifies that background tasks now integrate bandwidth checks and a dedicated sync mechanism. No issues found.

---

206-207: Switching to SyncService
Transitioning from direct NetworkManager usage to SyncService is more modular. Verify that all references and error states (e.g., partial failures in multi-entity sync) are handled consistently.

apps/health_campaign_field_worker_app/lib/blocs/app_initialization/app_initialization.dart (1)

316-316: Initializing MdmsConfig
Defining a dedicated constructor for the MdmsConfig class is clear. Ensure that further expansions (e.g., new fields) follow a similar pattern to reduce confusion.

apps/health_campaign_field_worker_app/lib/utils/utils.dart (3)

8-8: Complaints mappers import
Adding “complaints.init.dart” extends your utility layer. Ensure all complaint-related data models are consistently initialized before use.

---

28-28: Survey form mappers import
Similar to the complaints import, importing “survey_form.init.dart” ensures the new survey forms are recognized throughout the app.

---

103-103: Context mounted check
Safely verifying the context is mounted avoids potential runtime errors. This is a good defensive pattern.

apps/health_campaign_field_worker_app/lib/blocs/project/project.dart (5)

6-6: Validate newly introduced imports
You’ve added imports for “survey_form.dart”, “bandwidth_check.dart”, and “background_service.dart”. Ensure they’re all used effectively. If anything is unused, you could remove it to keep the file clean and maintain faster compile times.

Also applies to: 23-23, 28-28

---

41-42: Enforce dependency inversion
Declaring the BandwidthCheckRepository as a high-level dependency is good for testability. Make sure you’re injecting a mock or fakerepo during testing, and that there’s no direct instantiation of the repository anywhere else.

---

112-112: Confirm bandwidthCheckRepository usage
The constructor now requires bandwidthCheckRepository. Verify that all code paths using ProjectBloc provide this parameter, and no null references occur.

---

164-165: Double-check connectivity logic
Using “firstOrNull” implies you’re expecting a list of connectivity results. Ensure that the connectivity package usage aligns with your app’s minimum version and that the list always contains at least one result before reading “.firstOrNull”.

---

179-179: Batch size calculation
Storing the batch size in a local variable (“final batchSize = await _getBatchSize();”) helps performance by avoiding repeated calls. Good practice. Make sure the returned batch size is consistent with your maximum facility data to prevent large memory usage.

apps/health_campaign_field_worker_app/lib/pages/home.dart (4)

7-8: Check if newly introduced imports are necessary
Complaints and Survey Form packages are imported. Confirm they’re all referenced; unused imports might slow the build and clutter the file.

Also applies to: 27-27, 32-33

---

394-400: Replace “myCheckList” with survey forms
This rename further aligns with your shift from checklists to surveys. Confirm that all references such as help pages, tooltips, and docs are also updated to avoid mismatches.

---

550-553: Apply project-based conditions carefully
Filtering out the dashboard for non-IRS projects looks correct. Consider logging or a small explanation if the user’s project changes to clarify why certain features are hidden.

---

655-664: Verify complaint type initialization
Ensuring complaint types are loaded from “appConfiguration.complaintTypes” is appropriate. Confirm the array is not empty, or gracefully handle the scenario where no complaint types are configured.

apps/health_campaign_field_worker_app/lib/widgets/showcase/config/select_survey_form.dart (2)

3-9: LGTM! Well-implemented singleton pattern.

The singleton implementation follows best practices with private constructor and factory method.

---

11-18: Consider future extensibility of showcase data.

The showcase data list currently contains a single item. If more showcase items are planned for the survey form flow, consider documenting this in a TODO or creating placeholder entries.

Let's check if other survey form related showcase items exist:

apps/health_campaign_field_worker_app/lib/widgets/showcase/config/showcase_constants.dart (2)

22-24: LGTM! Clean transition to survey form showcase data.

The showcase data variables have been properly updated to reflect the architectural change from checklists to survey forms.

---

4-7: Verify removal of checklist-related imports.

The transition from checklist to survey forms looks good. However, let's verify that all checklist-related imports have been properly removed from the codebase to prevent dead code.

✅ Verification successful

Checklist-related showcase files have been properly removed

The verification shows that:

• No checklist-related files exist in the showcase directory
• No references to "checklist" remain in any showcase-related files
• The showcase directory structure has been properly updated with the new survey form files

The transition from checklist to survey forms in the showcase configuration appears to be complete and clean.

🏁 Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Search for any remaining checklist-related imports or usages
rg -l "checklist" --type dart

# Search specifically for old showcase imports
rg -l "checklist.*showcase" --type dart

Length of output: 2124

---

Script:

#!/bin/bash
# Let's check the content of showcase-related files to verify if there are any remaining checklist references
rg -A 5 -B 5 "checklist" apps/health_campaign_field_worker_app/lib/widgets/showcase/

# Also check for any showcase-related files that might have been missed in the restructuring
fd . apps/health_campaign_field_worker_app/lib/widgets/showcase/ -t f -e dart

# Check for any old checklist showcase files that might still exist
fd checklist apps/health_campaign_field_worker_app/lib/widgets/showcase/ -t f -e dart

Length of output: 1573

apps/health_campaign_field_worker_app/lib/widgets/showcase/config/home_showcase.dart (1)

71-72: LGTM: ShowcaseItemBuilder update

The localization key update from checklist to survey form is consistent with the architectural changes.

apps/health_campaign_field_worker_app/lib/utils/localization_delegates.dart (2)

7-10: LGTM: New package imports

The addition of complaints and survey form localization imports aligns with the architectural changes.

Also applies to: 23-24

---

55-58: Verify localization data availability

The new survey form and complaints localization delegates are properly integrated. However, ensure that corresponding localization data is available in the SQL store.

Also applies to: 76-79

✅ Verification successful

Based on the analysis of the codebase, I can now generate the final response:

Localization data is properly managed through SQL store

The codebase shows a robust localization system where:

• Localization data is loaded and stored in SQL through LocalizationLocalRepository
• The app has proper initialization logic in onLoadLocalization events
• The localization delegates are correctly integrated with the SQL data store
• Multiple modules (survey, complaints, etc.) share the same localization infrastructure

🏁 Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Search for localization data definitions
rg -A 5 'survey_form.*localization|complaints.*localization' --type json

Length of output: 74

---

Script:

#!/bin/bash
# Search for SQL files or database schema definitions that might contain localization data
fd -e sql -x cat {}

# Also check for any localization-related configuration or setup files
rg -i "localization.*sql|sql.*localization" --type dart -A 5

Length of output: 26773

---

Script:

#!/bin/bash
# Let's check for the SQL schema definition to understand the localization table structure
ast-grep --pattern 'class $LocalizationTable' -A 20

# Also check for any initialization or data loading logic
rg -i "initializeLocalization|loadLocalization" --type dart -A 5

Length of output: 61318

apps/health_campaign_field_worker_app/lib/widgets/header/back_navigation_help_header.dart (2)

44-44: LGTM: Color scheme update

Using theme.colorScheme.onSurface improves consistency with Material Design color system.

---

48-50: LGTM: Safer navigation handling

The change to maybePop() is a good improvement as it safely handles cases where navigation pop might not be possible.

apps/health_campaign_field_worker_app/lib/data/repositories/local/localization.dart (2)

13-79: LGTM! Well-structured query building with proper error handling.

The implementation shows good practices:

• Robust error handling with retry mechanism
• Clear separation of query building logic
• Proper null checks to prevent runtime crashes
• Well-structured module and code filtering conditions

---

115-119: LGTM! Good defensive programming.

The empty check before batch operation is a good optimization.

apps/health_campaign_field_worker_app/android/app/src/main/kotlin/com/digit/hcm/MainActivity.kt (1)

73-79: LGTM! Proper Android 13+ compatibility handling.

Good use of version-specific broadcast receiver registration.

apps/health_campaign_field_worker_app/android/app/src/main/kotlin/com/digit/hcm/location_service.kt (1)

95-99: LGTM! Good addition of accuracy tracking.

The accuracy information is properly propagated through the broadcast intent.

apps/health_campaign_field_worker_app/lib/utils/extensions/context_utility.dart (1)

107-108: LGTM: Boundary setters for new modules

The boundary setters for SurveyForm and Complaints modules are correctly integrated alongside existing singletons.

apps/health_campaign_field_worker_app/lib/router/app_router.dart (2)

6-7: LGTM: New package imports

The imports for complaints and survey form routers are correctly added.

---

51-52: LGTM: Router module registration

SurveyForm and Complaints routes are properly registered in the AutoRouterConfig.

apps/health_campaign_field_worker_app/lib/widgets/sidebar/side_bar.dart (1)

37-38: LGTM! Good improvement for content overflow handling

Wrapping the Column with SingleChildScrollView prevents layout overflow issues when the sidebar content exceeds the screen height.

apps/health_campaign_field_worker_app/lib/pages/authenticated.dart (2)

119-120: LGTM! Good architectural improvement

The switch to SyncService aligns with the architectural changes mentioned in the PR summary, providing better separation of concerns.

---

12-13: LGTM! Required imports for new features

The addition of survey_form and sync_service_lib imports aligns with the PR objectives of adding survey form functionality and improving sync services.

apps/health_campaign_field_worker_app/lib/widgets/network_manager_provider_wrapper.dart (3)

4-4: LGTM: Package imports align with architectural changes.

The addition of complaints and survey_form packages aligns with the PR's objective of replacing checklist functionality with survey forms and integrating complaints management.

Also applies to: 21-22

---

273-280: LGTM: PGR service local repository integration.

The PGR service local repository is properly integrated following the existing repository pattern, with appropriate OpLog management for offline-first functionality.

---

501-509: LGTM: PGR service remote repository integration.

The remote repository for PGR service is correctly configured with proper action mapping and Dio client integration.

apps/health_campaign_field_worker_app/lib/app.dart (3)

29-30: LGTM: Network-related imports.

The addition of remote client and bandwidth check imports enhances the application's network handling capabilities.

---

187-188: LGTM: Enhanced localization configuration.

The localization module string now includes hierarchy type, improving boundary-specific localization support.

---

202-206: Verify bandwidth check configuration.

The bandwidth check repository is properly integrated, but ensure the bandwidth check API path is correctly configured in the environment.

✅ Verification successful

Let me gather more information about the bandwidth check API path configuration.

---

Bandwidth check API path is properly configured

The bandwidth check API path is correctly configured in the environment with a default value of '/health-project/check/bandwidth' and can be overridden through the 'CHECK_BANDWIDTH_API' environment variable. The implementation properly handles both fallback and environment-provided values.

🏁 Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Description: Verify bandwidth check API path configuration
# Test: Search for bandwidth check API path configuration
rg -A 2 "checkBandwidthApiPath"

Length of output: 1127

---

Script:

#!/bin/bash
# Search for the bandwidth API path value and configuration
rg -A 5 "_checkBandwidthApi"

Length of output: 1367

README.md (1)

569-569: LGTM: Documentation for survey form showcase.

The addition of survey form showcase documentation maintains consistency with existing documentation patterns.

apps/health_campaign_field_worker_app/lib/pages/reports/beneficiary/beneficaries_report.dart (2)

57-61: LGTM! Proper resource cleanup

Good practice to cancel the subscription in dispose method to prevent memory leaks.

---

327-420: LGTM! Well-structured UI implementation

The UI components are well-organized with proper:

• Empty state handling
• Consistent styling
• Accessibility through proper text overflow handling

apps/health_campaign_field_worker_app/lib/models/downsync/downsync.mapper.dart (1)

4-4: LGTM! Generated code changes

The changes to the mapper code are auto-generated and improve equality comparison implementation by using the mapper's equalsValue method.

Also applies to: 133-134, 358-359, 568-569

apps/health_campaign_field_worker_app/lib/utils/i18_key_constants.dart (1)

26-26: LGTM! Added survey form showcase constants

The new constants align with the architectural change from checklist to survey forms.

Also applies to: 30-31

packages/attendance_management/CHANGELOG.md (1)

1-6: LGTM! Version bump and changes are well documented.

The changelog entry for version 1.0.3 clearly documents the significant changes.

apps/health_campaign_field_worker_app/lib/blocs/projects_beneficiary_downsync/project_beneficiaries_downsync.dart (1)

5-5: LGTM: Import changes align with the new sync service architecture.

The addition of sync_service_lib import and removal of network-related imports reflect the architectural shift towards using a centralized sync service.

Also applies to: 9-9

apps/health_campaign_field_worker_app/lib/pages/profile.dart (2)

62-64: LGTM: Standardized mobile number validation.

The use of Constants.mobileNumberRegExp centralizes the validation pattern and ensures consistency across the application.

---

152-154: LGTM: Improved connectivity check logic.

The connectivity check is now more explicit and easier to understand with the use of firstOrNull and direct comparison with ConnectivityResult types.