Skip to content

Clear overlays in the order remove, empty the manager, then post-process - #27

Merged
wf9a5m75 merged 3 commits into
developfrom
fix/overlay-clear-order
Nov 8, 2026
Merged

wf9a5m75 merged 3 commits into
developfrom
fix/overlay-clear-order

Conversation

@wf9a5m75

@wf9a5m75 wf9a5m75 commented Nov 8, 2026 •

Copy link
Copy Markdown
Contributor

なぜ

clearOverlays() を呼んでも、MapLibre 系(MapLibre / Mapbox / Mappls / MapTiler / TomTom / Longdo / OpenMobileMaps)の地図ではオーバーレイが消えずに残っていました。

これらのプロバイダの描画担当は、onRemove では地図に触らず、onPostProcess で manager が持っている全部を描き直します。ところが core の各コントローラの clear() は、

  • Polyline / GroundImage / RasterLayer: manager を空にする前に onPostProcess を呼ぶ(=消す前の全部を描き直す)
  • Polygon(と iOS・web の Circle): onPostProcess を呼ばない(=前に描いたものが残る)
  • Marker: onPostProcess を呼ばない

となっていて、どちらでも地図に残ります。Google Maps のように onRemove でネイティブのオブジェクトを消すプロバイダでは起きません。

何を変えたか

  • Polygon / Polyline / Circle / GroundImage / RasterLayer / Marker の 6 種類の clear() を、すべて「renderer.onRemove(全部) → manager.clear() → renderer.onPostProcess()」の順にそろえました(Android の Circle は元からこの順でした)。既存の前後処理(tiler、iOS の isDestroyed ガード、Android raster の withContext など)はそのままです。
  • OverlayClearOrderTest を足しました。GL 系と同じ作りの偽レンダラ(onPostProcess で manager の全部を描く)で、clear の後に描かれているものが空になることを 6 種類それぞれで固定しています。修正前のコードでは失敗することを確かめてあります。

関連 PR(同じ修正の一式)

fix/overlay-clear-order は次の 21 リポジトリにまたがります。

1. core(3 本は互いに独立。先にマージ・公開してください)

2. Android プロバイダ(core が無くても単独で効く修正。ただしポリライン・ポリゴン・GroundImage・ラスターの消え残りは core 側で直るので、core と合わせて初めて clearOverlays() が全部消えます)

3. iOS プロバイダ(ios-sdk-core のマージ・公開の後。clearOverlays() からコントローラの clear() を呼ぶ変更は、core の呼び順の修正が無いと GL 系で描き直しが起きて消えません)

4. web プロバイダ(js-sdk-core の新しい版を npm に公開し、依存(今は ^0.3.1)を引き上げてから。理由は各 PR の本文に)

マージの順番: core 3 本 → core の公開 → Android / iOS プロバイダ → js-sdk-core の npm 公開と依存の引き上げ → web プロバイダ。

検証

  • ./gradlew testDebugUnitTest(302 本すべて通過)
  • 公開 API の変更はありません(シグネチャは触っていません)。この単体リポジトリには apiCheck タスクが無いため、集約ビルド(android-sdk)の :android-sdk-core:apiCheck で確認しました(通過)。
  • ktlint: 変更したファイルに違反はありません(既存のファイルには develop 時点からの違反があり、ktlintCheck 自体は develop でも落ちます)。

実機・ブラウザでの確認(共通の手順)

同じ手順で、ポリゴン・ポリライン・サークル・GroundImage・ラスター・マーカーを出し、追加 → 更新(色・半径・不透明度)→ 一部削除(ポリゴン・サークル・ラスター)→ 戻す → clearOverlays() → clear 後に同じ state を in-place で書き換え → 同じ id・同じ内容の state を作り直して送り直す、の 7 段階をスクリーンショットで比べました。検証用のページはコミットしていません。

clearOverlays() の後 clear 後の in-place 更新 作り直して送り直す
Android(タブレット)MapLibre / Mapbox / Mappls / Google / OMM 何も残らない 戻らない 全部戻る
iOS(iPad 実機)MapLibre / Mapbox / MapTiler / Mappls / Google 何も残らない 戻らない 全部戻る
web(Playwright)MapLibre / Mapbox / Mappls / MapTiler / TomTom 何も残らない 戻らない 全部戻る

追加・更新・削除・戻すの 4 段階の見た目は修正前と同じでした。clear 後の振る舞い(in-place の更新では戻らず、顔ぶれが変わるか作り直された state が来たら全部描き直す)は、3 プラットフォームの core の collector と同じです。

確認できていないもの

  • web の Longdo はこの環境で API キーが通らず、ブラウザでは確認できていません(単体テストのみ)。
  • iOS の Longdo / HERE / MapKit / TomTom は実機で clearOverlays() を確かめていません(MapLibre / Mapbox / MapTiler / Mappls / Google は確認済み)。
  • Android の StrategyMarkerController(iOS も同名)の clear() は manager を空にするだけで、onRemove も onPostProcess も呼びません。今回の 6 種類とは別の経路なので触っていません。

GL-style renderers (MapLibre, Mapbox, Mappls, OpenMobileMaps) ignore
onRemove and redraw everything the manager holds in onPostProcess. Polyline,
GroundImage and RasterLayer called onPostProcess before emptying the
manager, so clear() redrew every overlay it was meant to remove; Polygon did
not call it at all. All five now run onRemove, manager.clear(),
onPostProcess, as CircleController already did.

OverlayClearOrderTest pins this with a GL-style fake renderer for each kind.
AbstractMarkerController.clear() emptied the manager without calling
onPostProcess. GL-style marker renderers only drop icon references in
onRemove and redraw their source from the manager in onPostProcess, so
the markers stayed on the map. Clear now ends the same way as the other
five overlay kinds: onRemove, manager.clear(), onPostProcess.

OverlayClearOrderTest gains the marker case.
This was referenced Nov 8, 2026
Provider CI builds this branch of core with compose's default branch,
which already uses MapViewState.detachController(controller) from
develop (#26).
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant