how to launch Surfaces correctly in ios?

[DurankGts]

I implemented in my app your new feaure Surfaces, but in my app is freezing when I launched from another thread.

you can check my classes implemented here

SvcEventSurfaceManager.txt
SurfaceData.txt

if you call startEventTracking method you can launch the LiveActivity but my app freezes in IOS 26 iphone 13. this behaivor work perfectly in simulator.

I have checked your poor documentation https://www.codenameone.com/blog/widgets-live-activities-dynamic-island/ and your Sample . my Question is . it's necessary to implements BackgroundFetch in my main class to use LiveActivity?

the LiveActivity is Lanched perfectly in the lockscreen but may app is freezes.

[shai-almog]

The whole class is built on an inverted assumption. Every public method does:

if (!CN.isEdt()) { CN.callSerially(() -> ...); return; }

with comments like "Execute Live Activity creation directly on EDT to prevent thread lock". That's backwards. The documented contract (Surfaces.publish, CodenameOne/src/com/codename1/surfaces/Surfaces.java:121-131) is callable from any thread, including background fetch with no UI running. Nothing in the API wants the EDT it's serialization, file IO into the App Group container, and a native call.

By forcing it onto the EDT you moved all of that onto the one thread that must never block:

• Surfaces.publish / LiveActivity.start write PNG blobs + timeline.json into the shared container (IOSSurfaceBridge.publishWidgetTimeline / startLiveActivity), then call into ActivityKit. Activity.request(...) is a synchronous XPC round trip to the system daemon.
• Image encoding is the expensive part. SurfaceSerializer.encode() only short-circuits for EncodedImage; anything else goes through ImageIO.save, and on iOS that is IOSImplementation.java:10677 -> nativeInstance.createImageFile(...) -> IOSNative.m:8463, which does a Metal buffer flush plus dispatch_sync(dispatch_get_main_queue(), ...). So the EDT blocks on the main thread, holding the display lock, per image.

In the simulator all of this is Java2D plus a local filesystem write microseconds. On an iPhone 13 it's a real GPU readback, a real container write and a real XPC hop. Same code, wildly different cost.

resolveIcon() makes it worse: it returns a live com.codename1.ui.Image and in the fallback path a mutable one from FontImage.createMaterial(...).toImage(). startEventTracking then builds two SurfaceImages from it (compactIcon 24x24 at line 164, avatar 40x40 in buildEventLayout), so that native encode path runs twice per start.

Fix: drop all the CN.isEdt() funnelling and call these off the EDT, and cache an EncodedImage instead of an Image:

cachedDefaultIcon = EncodedImage.create("/ic_stat_notify.png");

SurfaceSerializer.encode() returns getImageData() directly for an EncodedImage and skips ImageIO/Metal entirely.

Real bugs independent of the freeze

1. instances is a plain HashMap (line 37) mutated from arbitrary threads.

2. inr (persisted) and activeLiveActivity (per-process) can't be reconciled. After the app is killed with an activity running, inr is still true but the handle is gone → isTrackingActive() is false → startEventTracking requests a second activity while iOS still shows the first. Nothing ever ends the orphan (a non-immediate dismissal lingers for hours).

3. MyPreferences.set("inr", true) is unconditional at line 202, but LiveActivity.start returns an inert handle when ActivityKit refuses (user disabled Live Activities, request threw). Then isActive() is false, isTrackingActive() is false, and the next call starts yet another one. Check activeLiveActivity.isActive() before recording state.

4. stopEventTracking does instances.remove(descriptorId) (line 261) — so any later getInstance(id) hands back a fresh manager with a null handle. If a stop is missed, that activity can never be ended.

5. getWidgetKind(...) is never called anywhere, so Surfaces.registerWidgetKind presumably never runs, yet publishHomeScreenWidget publishes a timeline for that kind. Also enableWidget defaults to false, so widget publishing silently no-ops until someone calls setEnableWidget(true) — easy to mistake for a bug in the framework.

6. updateEventProgress republishes the entire widget timeline on every update (line 232). If that's driven by a location or timer loop it's a continuous stream of container writes + WidgetCenter reloads. WidgetKit throttles reloads aggressively; you'll burn the budget and stutter. They're already using SurfaceDynamicText, which is exactly the mechanism that makes per-tick updates unnecessary — the timer re-interpolates on the surface without an update.

No, BackgroundFetch is not required for Live Activities. Background fetch exists to refresh widget timelines while the app is dead (Surfaces.publish is explicitly documented as callable from performBackgroundFetch). A Live Activity is started and updated by the running app (or later, by push). Unrelated feature.

[DurankGts]

SvcEventSurfaceManager.txt
thanks you. I implemented you suggestions but my app it continue freezing... any other suggestions?

the LiveActivity is launched perfectly but my app is freezed

[DurankGts]

if I commett this code my app don't freezed

[shai-almog]

There was a similar bug in our sample code so we're revising that and adding a check so the simulator will fail for some of these problem. Not sure if it will make it for this weeks release though.

[DurankGts]

ok I thinks that I will delete this implementation in my app for now, because I need to launch an update of my app urgent. I have lose much time trying to implement in my app to replace may all implementation using local notifications.