feat: Introduce a robust Google Maps initializer #758
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This commit refactors the map initialization logic to be more robust and test-friendly. Previously, the map initialization was coupled with the attribution ID logic, which made it difficult to handle initialization failures, especially in test environments where the Maps SDK might be mocked. This change introduces a new `GoogleMapsInitializer` object that manages the initialization process with a state machine. This provides more control over the initialization process and allows for better error handling. The key changes are: - A new `GoogleMapsInitializer` object that manages the initialization of the Google Maps SDK. - An `InitializationState` enum that represents the different states of the initialization process. - An `initialize` function that starts the initialization process on a background thread. - A `reset` function that allows for re-initialization in test environments. - The `GoogleMap` composable now uses the `GoogleMapsInitializer` to ensure that the map is only displayed after the SDK has been successfully initialized.
![github-advanced-security[bot]](https://avatars.githubusercontent.com/in/57789?s=60&v=4){kind=small}
This change refactors the `GoogleMapsInitializer` to use suspend functions for initialization and reset operations, improving its testability and adherence to structured concurrency. Key changes: - Converted `GoogleMapsInitializer.initialize()` and `GoogleMapsInitializer.reset()` to `suspend` functions. - Removed the internal `CoroutineScope` and job management from `GoogleMapsInitializer`. - Updated unit and instrumentation tests to use `runTest` from `kotlinx-coroutines-test`, removing the need for `Thread.sleep()`. - Added the `kotlinx-coroutines-test` dependency to the `maps-app` module.
The `initialize` function has been refactored to be a fully suspending operation. Key changes: - Replaced `launch(Dispatchers.IO)` with `withContext(Dispatchers.IO)`. This ensures the `initialize` function suspends until the blocking initialization call is complete, rather than returning immediately. - Added explicit handling for non-SUCCESS results from `MapsInitializer.initialize()` to set the state to `FAILURE`. - Restructured the `try-catch` block to correctly handle exceptions from the `withContext` block.
kikoso
reviewed
Sep 9, 2025
| @OptIn(ExperimentalCoroutinesApi::class) | ||
| @RunWith(AndroidJUnit4::class) | ||
| class GoogleMapsInitializerTest { | ||
|
|
There was a problem hiding this comment.
Just a random idea: since one of the motivations to do some work on the Maps Initializer was the positive we got on the StrictMode, wondering if it could make sense to test this with the StrictMode activated:
@Before
fun setUp() {
StrictMode.setThreadPolicy(
StrictMode.ThreadPolicy.Builder()
.detectDiskReads()
.detectAll()
.penaltyLog()
.build()
)
StrictMode.setVmPolicy(
StrictMode.VmPolicy.Builder()
.detectAll()
.penaltyLog()
.build()
)
}There was a problem hiding this comment.
This is a good idea. Thanks for the suggestion!
kikoso
approved these changes
Sep 9, 2025
Wraps the `GoogleMapsInitializer.initialize()` call with strict StrictMode policies. This ensures the initialization process does not perform any violations, such as disk reads, which would cause the test to fail.
Key changes: - Introduced a custom `LatLngSubject` for the Truth assertion library to allow for `LatLng` comparisons with a tolerance. - Migrated assertions in `GoogleMapViewTests` from JUnit to Truth for improved readability and more expressive tests. - Added explicit Google Maps SDK initialization within the test setup.
Code Coverage
|
googlemaps-bot
pushed a commit
that referenced
this pull request
Sep 9, 2025
# [6.10.0](v6.9.0...v6.10.0) (2025-09-09) ### Features * Introduce a robust Google Maps initializer ([#758](#758)) ([87a4b5c](87a4b5c))
|
🎉 This PR is included in version 6.10.0 🎉 The release is available on:
Your semantic-release bot 📦🚀 |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
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.
This commit refactors the map initialization logic to be more robust and
test-friendly.
Previously, the map initialization was coupled with the attribution ID
logic, which made it difficult to handle initialization failures,
especially in test environments where the Maps SDK might be mocked.
This change introduces a new
GoogleMapsInitializerobject that managesthe initialization process with a state machine. This provides more
control over the initialization process and allows for better error
handling.
The key changes are:
GoogleMapsInitializerobject that manages the initializationof the Google Maps SDK.
InitializationStateenum that represents the different states ofthe initialization process.
initializefunction that starts the initialization process on abackground thread.
resetfunction that allows for re-initialization in testenvironments.
GoogleMapcomposable now uses theGoogleMapsInitializertoensure that the map is only displayed after the SDK has been
successfully initialized.
Two new tests have been added to verify the new logic:
GoogleMapsInitializerTest) that runs in a local JVMand asserts that the initialization fails as expected when Google
Play services are not available.
GoogleMapsInitializerTest) that runs on anAndroid device or emulator and asserts that the initialization
succeeds as expected when Google Play services are available.