Refactor: Centralize location service unavailability handling #6602
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Description (required)
This PR refactors the location service handling to resolve a long-standing technical debt "TODO" in
ContributionController.Previously, the
ContributionControllermanually managed its own "Location Off" dialog logic because the sharedLocationPermissionsHelperlacked a way to notify callers when a user declined to turn on system location services. This led to redundant code and inconsistent behavior across different screens.I have:
LocationPermissionCallbackinterface to includeonLocationServiceUnAvailable().LocationPermissionsHelperto trigger this callback when a user dismisses the location settings dialog.ContributionControllerby removing redundant dialog logic and using the new callback to gracefully proceed with camera uploads.ExploreMapFragment,NearbyParentFragment, andLocationPickerActivityto ensure the app remains stable and consistent across all location-aware features.What changes did you make and why?
I moved the UI logic for handling disabled GPS from individual controllers into the shared helper. This ensures that if a user hits "Cancel" on a location prompt, the app responds predictably (showing a toast and allowing manual override) rather than potentially getting stuck or requiring duplicate logic in every fragment.
Tests performed (required)
Tested ProdDebug on
Redmi note 13+with API level35.