fix: keep ComposeView attached while info window is shown for compose-ui 1.10+ compat - #931
Merged
Merged
Conversation
Contributor
Code Coverage
|
…-ui 1.10+ compat Addresses issue #913: MarkerInfoWindowContent renders empty with compose-bom 2026.04.01+ (compose-ui 1.10.0+). compose-ui 1.10.0 added an isShown guard to AbstractComposeView.draw(), which makes detached views draw nothing. The previous implementation immediately detached the ComposeView via renderComposeViewOnce, so by the time the Maps SDK called draw() the view was detached and isShown == false. Fix: use startRenderingComposeView (keeps view attached) instead of renderComposeViewOnce, storing the RenderHandle per marker. The view stays attached to the MapView's NoDrawContainerView while the info window is visible, so isShown == true when the Maps SDK renders it. The RenderHandle is disposed when the info window closes via a new disposeForMarker() call wired into the existing onInfoWindowClose listener in MapApplier.
kikoso
force-pushed
the
fix/info-window-content-newer-compose-bom
branch
from
July 1, 2026 14:34
7a3797d to
738204d
Compare
kikoso
marked this pull request as ready for review
July 1, 2026 14:34
dkhawk
approved these changes
Jul 9, 2026
4 tasks
kikoso
added a commit
that referenced
this pull request
Aug 6, 2026
…indowComposable Fixes #950 PR #931 fixed #913 (empty info window content on compose-ui 1.10+) by keeping the ComposeView permanently attached to the library's own container while the info window is shown. That works around compose-ui's attachment requirement for drawing, but it means the view handed back from getInfoContents()/getInfoWindow() already has a parent. The Maps SDK internally re-parents that view into its own default info window frame, so calling addView() on an already-parented view throws: java.lang.IllegalStateException: The specified child already has a parent. You must call removeView() on the child's parent first. This change renders the Compose content into a plain Bitmap up front (attach, measure, layout, draw, detach, the same technique already used for MarkerComposable icon bitmaps) and hands the Maps SDK a fresh, unattached ImageView wrapping that bitmap instead of the live ComposeView. This keeps the compose-ui 1.10+ fix from #931 (content is fully rendered before we let go of it) while avoiding the double parent crash, since the returned view was never attached anywhere. Verified on a physical device: reproduced the #950 crash on the previous build, confirmed it is gone after this change, and confirmed MarkerInfoWindowContent and MarkerInfoWindowComposable content still render correctly under compose-bom 2026.06.01 (compose-ui 1.10+), covering the original #913 scenario as well.
kikoso
added a commit
that referenced
this pull request
Aug 6, 2026
…indowComposable (#953) Fixes #950 PR #931 fixed #913 (empty info window content on compose-ui 1.10+) by keeping the ComposeView permanently attached to the library's own container while the info window is shown. That works around compose-ui's attachment requirement for drawing, but it means the view handed back from getInfoContents()/getInfoWindow() already has a parent. The Maps SDK internally re-parents that view into its own default info window frame, so calling addView() on an already-parented view throws: java.lang.IllegalStateException: The specified child already has a parent. You must call removeView() on the child's parent first. This change renders the Compose content into a plain Bitmap up front (attach, measure, layout, draw, detach, the same technique already used for MarkerComposable icon bitmaps) and hands the Maps SDK a fresh, unattached ImageView wrapping that bitmap instead of the live ComposeView. This keeps the compose-ui 1.10+ fix from #931 (content is fully rendered before we let go of it) while avoiding the double parent crash, since the returned view was never attached anywhere. Verified on a physical device: reproduced the #950 crash on the previous build, confirmed it is gone after this change, and confirmed MarkerInfoWindowContent and MarkerInfoWindowComposable content still render correctly under compose-bom 2026.06.01 (compose-ui 1.10+), covering the original #913 scenario as well.
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
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.
Fixes #913
Summary
isShownguard toAbstractComposeView.draw(), causing detached views to draw nothing.renderComposeViewOnce, which attaches theComposeViewand then immediately detaches it. By the time the Maps SDK internally callsdraw()to render the info window bitmap, the view is detached andisShown == false, so the content is never drawn.Changes
ComposeInfoWindowAdapter: ReplacerenderComposeViewOncewithstartRenderingComposeViewso the view stays attached to theMapView'sNoDrawContainerViewwhile the info window is visible. ARenderHandleis stored per marker so we can clean up later.MapApplier: Store a reference toComposeInfoWindowAdapterand calldisposeForMarker(marker)from the existingonInfoWindowCloselistener, so the view is removed from the container as soon as the info window is dismissed.Test plan
MarkerInfoWindowContentwith custom Compose content