Android-to-iOS Importer: Requests for Expanded Document Intent, Background GPS, WorkManager, Room/SQLite, and Native Touch Compatibility

[fckdsko-apps]

Hi Codename One team,

I've been continuing work on bringing my existing Android geological research and navigation app, to iOS using your Android importer.

First, I wanted to thank you for the recent compatibility improvements. I noticed several updates following my earlier questions, and they've made a real difference. I've now gotten the full application compiling and launching on iOS, with MapLibre Native rendering geological maps, mineral heatmaps, and other map layers.

I'm getting considerably further than I initially expected without having to rewrite the application.

I'm now running into a few remaining Android compatibility limitations, and I'd like to request some additional support for these where feasible. I've been investigating the framework's existing capabilities to avoid requesting things that are already implemented.

The main areas are:

1. Android document intents: The app uses ACTION_OPEN_DOCUMENT and ACTION_CREATE_DOCUMENT for importing and exporting tracks, locations, and other files. These currently produce an ActivityNotFoundException. I found that Codename One already has native file-dialog capabilities. Would it be possible to add Android intent compatibility that connects these existing APIs to the Android activity-result system? This seems like something that could benefit quite a few imported Android apps.

2. Foreground services and continuous GPS: The app uses Android location services and foreground services for recording GPS tracks, navigation, and field activity. I'd like to request more complete compatibility for these operations through iOS Core Location, including background recording where permitted. Retaining the original Android location APIs would make a substantial difference.

3. Native map touch interoperability: MapLibre Native is rendering successfully, but some interactions involving Android touch overlays, native UIKit gestures, and map coordinate conversion aren't functioning correctly. It would be helpful to have a more consistent compatibility mechanism for native peer touch handling, particularly where Android views overlap native components.

4. WorkManager and background execution: The app relies on WorkManager for offline dataset downloads and updates. I'd appreciate expanded support for the relevant Android background-work lifecycle, potentially using native iOS scheduling where appropriate, so existing Java workflows can be retained.

5. Room and SQLite: I discovered the Room implementation generator already included in Codename One, which is encouraging. I'm still verifying generated DAO behavior for trips, saved locations, and other persistent data. I'd appreciate continued compatibility work here, especially around database initialization, transactions, and asynchronous callbacks.

I'm trying to approach this as a compatibility project rather than replacing the Android functionality with separate iOS implementations wherever something doesn't work.

Would you be willing to consider expanding the importer in these areas, particularly document intents, location services, and native touch interoperability? Those appear to offer the greatest immediate benefit, and I suspect they'd be useful for other fairly complex Android applications as well.

I realize some of these are considerably larger undertakings than others, and some might already be partially supported. I'd be interested in knowing which you think could reasonably be incorporated into the importer and which would be better handled through application-specific bridges.

I'm happy to provide reproducible examples, affected API calls, and test results from the app to help narrow down what needs implementing.

The importer has already made this migration much more practical than I expected, and I'd really like to keep building on that progress.

Thanks again!

[shai-almog]

Great to hear it's useful to you!

1. Document intents: no problem. We can add those as we already have the APIs.

2. Background GPS: is already supported. If your manifest declares ACCESS_BACKGROUND_LOCATION or FOREGROUND_SERVICE_LOCATION, the build enables the iOS location background mode and the permission texts. Your LocationManager updates then keep running in the background. Foreground services are the real difference. iOS has no equivalent: a location stream is the only thing that keeps an app running in the background, and other foreground-service work gets about 30 seconds. For track recording, save each fix to the database from the location listener itself, not from a separate service thread on a timer, and it keeps working with the screen off.

3. Native map touch: we need a test case here. Your Android views are drawn by Codename One, while MapLibre is a native UIKit view, so the answer depends on how they overlap. A small project with an overlay on the map and the gesture that fails would let us fix it properly.

4. WorkManager: supported. One-time, periodic, chained and unique work all run in-process while the app is open, and unfinished work resumes on the next launch. Requests with charging, idle, battery or storage constraints are handed to iOS's BGTaskScheduler, which decides when they run. For large dataset downloads, download in resumable chunks while the app is open; WorkManager keeps the request across suspension.

5. Room: callbacks (onCreate/onOpen), runInTransaction, migrations and LiveData queries are supported. Kotlin suspend DAOs, Flow and RxJava aren't. If your DAOs use those, LiveData or a plain executor is the way to port them. If you hit something outside those cases, please send us the DAO.

We'll add a "Background execution on iOS" section to the Android interop chapter of the developer guide. It maps each of these Android mechanisms to what happens on iOS.

I don't know if this will make it for tomorrows release as we have a big update. But I'll try and push them through.

[fckdsko-apps]

Thanks for the detailed response! This clarifies a lot and helps us avoid duplicating functionality that's already supported.

I've since completed another compatibility audit and successfully compiled the full application into an ARM64 iOS Simulator build.

A few notes based on your answers:

1. Document intents: Great, thank you. We'll hold off on implementing our own workaround and test the importer support when it's available.

2. Background GPS: Our manifest already declares FOREGROUND_SERVICE_LOCATION, and our track recorder writes GPS fixes directly to SQLite from LocationListener.onLocationChanged(). So it sounds like we're already following the recommended approach. The listener currently lives inside an Android Service. Is that supported for continuous background updates on iOS, or should we move its registration outside the service lifecycle?

3. Native map touch: We've prepared a small reproduction using MapLibre with a transparent Android FrameLayout overlay, testing taps, forwarded pan gestures, and overlay hit-testing. I'll share it once we've reproduced the issue in isolation and have meaningful diagnostic results.

4. WorkManager: Understood. We'll handle resumable dataset downloads at the application level and work within the iOS execution constraints you described.

5. Room: Our DAOs use standard Java methods and executors, without suspend, Flow, or RxJava. The generated implementation checks are passing. We'll report back with the relevant DAO and logs if runtime testing reveals a compatibility issue.

We're now concentrating on runtime testing of the remaining application features, rather than requesting broader framework changes.

Thanks again for the support and for adding the background execution documentation. It's been very helpful for getting an existing Android application running on iOS.