Implement hardResetDatabase method #2

orca-nazar · 2025-12-16T20:25:53Z

Description

Added hardResetDatabase that includes 2 steps:

deletion database from file system;
offline region manager reinitialization to use new dataPath to database .mapbox_custom. To force Mapbox recreate a new database in a new folder. Otherwise, recreation doesn't work

Copilot

Pull request overview

This PR implements the hardResetDatabase method to provide a comprehensive reset of the Mapbox offline database. The implementation handles platform differences: iOS deletes both .mapbox/map_data and .mapbox_custom directories and reinitializes the OfflineRegionManager with a fresh custom directory, while Android simply deletes the .mapbox/map_data directory and relies on the C++ manager to auto-recreate the database.

Adds hardResetDatabase() method across TypeScript, iOS, and Android implementations
Updates iOS MapView and OfflineRegionManager initialization to support custom data path resolution
Implements platform-specific cleanup strategies (iOS: full reset with reinitialization, Android: directory deletion only)

Reviewed changes

Copilot reviewed 5 out of 5 changed files in this pull request and generated 8 comments.

Show a summary per file

File	Description
`src/modules/offline/offlineManagerLegacy.ts`	Adds `hardResetDatabase()` method with detailed documentation explaining platform differences
`ios/RNMBX/RNMBXMapView.swift`	Adds data path resolution logic to prefer `.mapbox_custom` directories over default `.mapbox/map_data`
`ios/RNMBX/Offline/RNMBXOfflineModuleLegacy.swift`	Implements `hardResetDatabase()` and `reinitOfflineRegionManager()` with custom data path resolution; updates `offlineRegionManager` lazy property to support custom paths
`ios/RNMBX/Offline/RNMBXOfflineModuleLegacy.m`	Exposes `hardResetDatabase` method to React Native bridge
`android/src/main/java/com/rnmapbox/rnmbx/modules/RNMBXOfflineModuleLegacy.kt`	Implements `hardResetDatabase()` to delete `.mapbox/map_data` directory on a background thread

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

Copilot · 2025-12-17T01:18:29Z

ios/RNMBX/RNMBXMapView.swift

+      let fileManager = FileManager.default
+      let appSupport = fileManager.urls(
+        for: .applicationSupportDirectory,
+        in: .userDomainMask
+      ).first!


The force unwrap on fileManager.urls(for:in:).first! could crash if the application support directory is unexpectedly unavailable. While this is extremely unlikely in practice, consider using guard-let or if-let with proper error handling for better safety, similar to standard Swift practices.

Copilot · 2025-12-17T01:18:29Z

ios/RNMBX/Offline/RNMBXOfflineModuleLegacy.swift

  lazy var offlineRegionManager: OfflineRegionManager = {
-    #if RNMBX_11
-    return OfflineRegionManager()
-    #else
-    return OfflineRegionManager(resourceOptions: .init(accessToken: RNMBXModule.accessToken!))
-    #endif
+    // This logic should be aligned with MapView initialization @see ios/RNMBX/RNMBXMapView.swift
+    let fileManager = FileManager.default
+    let appSupport = fileManager.urls(
+      for: .applicationSupportDirectory,
+      in: .userDomainMask
+    ).first!
+
+    // Default: Library/Application Support/.mapbox/map_data
+    let defaultDataPath = appSupport.appendingPathComponent(".mapbox/map_data")
+
+    // Preferred: Library/Application Support/.mapbox_custom/XXXX/map_data/map_data.db
+    var customDataPath: URL? = nil
+    let customRoot = appSupport.appendingPathComponent(".mapbox_custom", isDirectory: true)
+
+    if fileManager.fileExists(atPath: customRoot.path),
+      let entries = try? fileManager.contentsOfDirectory(
+        at: customRoot,
+        includingPropertiesForKeys: [.isDirectoryKey],
+        options: []
+      ) {
+      for entry in entries {
+        // Only consider subdirectories under .mapbox_custom
+        if let isDir = try? entry.resourceValues(forKeys: [.isDirectoryKey]).isDirectory,
+          isDir == true {
+          let candidateMapData = entry.appendingPathComponent("map_data", isDirectory: true)
+          let candidateDb = candidateMapData.appendingPathComponent("map_data.db")
+
+          if fileManager.fileExists(atPath: candidateDb.path) {
+            customDataPath = candidateMapData
+            break
+          }
+        }
+      }
+    }
+
+    let dataPathURL = customDataPath ?? defaultDataPath
+
+  #if RNMBX_11
+    return OfflineRegionManager(
+      resourceOptions: .init(
+        accessToken: RNMBXModule.accessToken!,
+        dataPathURL: dataPathURL
+      )
+    )
+  #else
+    return OfflineRegionManager(
+      resourceOptions: .init(
+        accessToken: RNMBXModule.accessToken!,
+        dataPathURL: dataPathURL
+      )
+    )
+  #endif


The data path resolution logic (lines 8-60) is duplicated in three locations: here in the offlineRegionManager lazy property, in reinitOfflineRegionManager (lines 488-495), and in RNMBXMapView.swift (lines 259-293). This creates a maintainability issue as any changes to this logic need to be applied in three places. Consider extracting this logic into a shared function that all three locations can call.

Copilot · 2025-12-17T01:18:29Z

ios/RNMBX/Offline/RNMBXOfflineModuleLegacy.swift

+  #if RNMBX_11
+    return OfflineRegionManager(
+      resourceOptions: .init(
+        accessToken: RNMBXModule.accessToken!,
+        dataPathURL: dataPathURL
+      )
+    )
+  #else
+    return OfflineRegionManager(
+      resourceOptions: .init(
+        accessToken: RNMBXModule.accessToken!,
+        dataPathURL: dataPathURL
+      )
+    )
+  #endif


The conditional compilation blocks for RNMBX_11 vs. the else branch are identical (lines 46-60). Both branches create an OfflineRegionManager with the same parameters. You can remove the conditional compilation and use a single implementation for both versions.

Copilot · 2025-12-17T01:18:29Z

ios/RNMBX/Offline/RNMBXOfflineModuleLegacy.swift

+      #if RNMBX_11
+      self.offlineRegionManager = OfflineRegionManager(
+        resourceOptions: .init(
+          accessToken: RNMBXModule.accessToken!,
+          dataPathURL: targetDir
+        )
+      )
+      #else
+      self.offlineRegionManager = OfflineRegionManager(
+        resourceOptions: .init(
+          accessToken: RNMBXModule.accessToken!,
+          dataPathURL: targetDir
+        )
+      )
+      #endif


The conditional compilation blocks for RNMBX_11 vs. the else branch are identical (lines 511-525). Both branches create an OfflineRegionManager with the same parameters. You can remove the conditional compilation and use a single implementation for both versions.

Copilot · 2025-12-17T01:18:29Z

ios/RNMBX/Offline/RNMBXOfflineModuleLegacy.swift

+    // Generate random suffix, e.g. "A1B2"
+    let randomSuffix = UUID().uuidString.prefix(4)
+    let folderName = ".mapbox_custom/\(randomSuffix)/map_data"


The random suffix generation uses only the first 4 characters of a UUID, which could potentially lead to collisions. While UUID().uuidString.prefix(4) gives 65,536 possible values (16^4), for a more robust solution, consider using a larger portion of the UUID or a timestamp-based approach to ensure uniqueness, especially if this function might be called multiple times.

agree about ts based approach. but some occasions in future, check uuid v7.

Copilot · 2025-12-17T01:18:30Z

android/src/main/java/com/rnmapbox/rnmbx/modules/RNMBXOfflineModuleLegacy.kt

+    fun hardResetDatabase(promise: Promise) {
+        Thread {
+            try {
+                val mapDataDir = File(mReactContext.filesDir.absolutePath + "/.mapbox/map_data")
+                Log.d(LOG_TAG, "hardResetDatabase: deleting ${mapDataDir.absolutePath}")
+                if (mapDataDir.exists()) {
+                    mapDataDir.deleteRecursively()
+                }
+                Log.d(LOG_TAG, "hardResetDatabase: done")
+                promise.resolve(null)
+            } catch (t: Throwable) {
+                Log.e(LOG_TAG, "hardResetDatabase: failed", t)
+                promise.reject("hardResetDatabase error:", t)
+            }
+        }.start()
+    }


The promise resolution in hardResetDatabase is called directly from a background thread (line 465), which differs from the pattern used in other methods in this class (e.g., resetDatabase at line 388 uses UiThreadUtil.runOnUiThread). While React Native promises can typically be resolved from any thread, for consistency with the rest of the codebase and to avoid potential issues, consider using UiThreadUtil.runOnUiThread to resolve/reject the promise.

Another agent suggested not to use UI thread. However, as deletion operation is fast, will switch to runOnUiThread

Copilot · 2025-12-17T01:18:30Z

ios/RNMBX/Offline/RNMBXOfflineModuleLegacy.swift

+    let fileManager = FileManager.default
+    let appSupport = fileManager.urls(for: .applicationSupportDirectory,
+                                      in: .userDomainMask).first!


The force unwrap on fileManager.urls(for:in:).first! could crash if the application support directory is unexpectedly unavailable. While this is extremely unlikely in practice, consider using guard-let or if-let with proper error handling for better safety, similar to standard Swift practices.

Copilot · 2025-12-17T01:18:30Z

ios/RNMBX/Offline/RNMBXOfflineModuleLegacy.swift

+    let fileManager = FileManager.default
+    let appSupport = fileManager.urls(
+      for: .applicationSupportDirectory,
+      in: .userDomainMask
+    ).first!


The force unwrap on fileManager.urls(for:in:).first! could crash if the application support directory is unexpectedly unavailable. While this is extremely unlikely in practice, consider using guard-let or if-let with proper error handling for better safety, similar to standard Swift practices.

orca-hydromancer · 2025-12-17T01:45:44Z

cleanest setup:

offlineManager api accepts resource path as optional argument, same with mapview
hard reset can be performed with ts
flow: unmount mapview -> unmount offlinemanager -> hard reset in ts -> remount offlinemanager -> remount mapview

i think you might have mentioned that above flow doesn't work.

looking at the code, don't see why this is not possible. i'd use the same approach on both platforms.

orca-nazar · 2025-12-17T08:44:20Z

@orca-hydromancer

cleanest setup:

offlineManager api accepts resource path as optional argument, same with mapview

hard reset can be performed with ts

flow: unmount mapview -> unmount offlinemanager -> hard reset in ts -> remount offlinemanager -> remount mapview

i think you might have mentioned that above flow doesn't work.

looking at the code, don't see why this is not possible. i'd use the same approach on both platforms.

Almost the same approach was tested on iOS, but it doesn’t work. “Almost” because there is no way to unmount the offline manager on the Swift side (unless you’ve found a workaround?).

We also thought this approach would work well on Android. Partially, yes: I ran several test iterations in debug with different offline data sizes (0.1–2.5 GB), and initially tested small sizes in production. No issues were noticed.

However, after testing the deletion of a 2.5 GB dataset in production, the simpler approach failed. It turned out that this approach is not reliable for larger databases.

To summarize, iOS and Android now follow the same hard reset flow, which is robust and validated for databases up to 2.5 GB.

We will run one more iteration with a 4.5 GB database, as one user attempted to update/delete approximately that amount of data.

orca-nazar · 2025-12-17T11:26:18Z

Test result 1. Deleting ~4.6GB on iOS passed
https://drive.google.com/file/d/1gOIgAZq0YJRqhTW7BPDwI0Q0xgtvnAQ6/view?usp=sharing

orca-hydromancer · 2025-12-17T11:41:11Z

“Almost” because there is no way to unmount the offline manager on the Swift side (unless you’ve found a workaround?).

offlineRegionManager = nil doesn't do the trick?

orca-hydromancer · 2025-12-17T11:51:51Z

“Almost” because there is no way to unmount the offline manager on the Swift side (unless you’ve found a workaround?).

offlineRegionManager = nil doesn't do the trick?

alternative

unmount map view -> reinint offline manager -> destroy old db -> mount map view

orca-hydromancer · 2025-12-17T11:53:37Z

To summarize, iOS and Android now follow the same hard reset flow, which is robust and validated for databases up to 2.5 GB.

good work. i'm happy with this. i just felt it could be cleaner.

orca-nazar · 2025-12-19T08:03:59Z

No need anymore. Hard reset could be done fully from JS side by usign this flow

unmount map view -> destroy old db -> mount map view

orca-nazar added 4 commits December 16, 2025 21:34

Implement hardResetDatabase on iOS

c59df18

Provide hardResetDatabase on Android

ce219cc

Update bridge

24765ef

Fixes after review

8004e4b

orca-hydromancer requested a review from Copilot December 17, 2025 01:02

Copilot started reviewing on behalf of orca-hydromancer December 17, 2025 01:03 View session

Copilot AI reviewed Dec 17, 2025

View reviewed changes

Align Android hardResetDatabase with iOS implementation

6229bfd

orca-nazar closed this Dec 19, 2025

Implement hardResetDatabase method #2

Implement hardResetDatabase method #2

Uh oh!

Conversation

orca-nazar commented Dec 16, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Description

Uh oh!

Copilot AI left a comment

Choose a reason for hiding this comment

Pull request overview

Reviewed changes

Uh oh!

Copilot AI Dec 17, 2025

Choose a reason for hiding this comment

Uh oh!

Copilot AI Dec 17, 2025

Choose a reason for hiding this comment

Uh oh!

Copilot AI Dec 17, 2025

Choose a reason for hiding this comment

Uh oh!

Copilot AI Dec 17, 2025

Choose a reason for hiding this comment

Uh oh!

Copilot AI Dec 17, 2025

Choose a reason for hiding this comment

Uh oh!

orca-hydromancer Dec 17, 2025

Choose a reason for hiding this comment

Uh oh!

Copilot AI Dec 17, 2025

Choose a reason for hiding this comment

Uh oh!

orca-nazar Dec 17, 2025

Choose a reason for hiding this comment

Uh oh!

Copilot AI Dec 17, 2025

Choose a reason for hiding this comment

Uh oh!

Copilot AI Dec 17, 2025

Choose a reason for hiding this comment

Uh oh!

orca-hydromancer commented Dec 17, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

orca-nazar commented Dec 17, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

orca-nazar commented Dec 17, 2025

Uh oh!

orca-hydromancer commented Dec 17, 2025

Uh oh!

orca-hydromancer commented Dec 17, 2025

Uh oh!

orca-hydromancer commented Dec 17, 2025

Uh oh!

orca-nazar commented Dec 19, 2025

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

orca-nazar commented Dec 16, 2025 •

edited

Loading

orca-hydromancer commented Dec 17, 2025 •

edited

Loading

orca-nazar commented Dec 17, 2025 •

edited

Loading