Interface IntentBridge
The platform seam of the app intents framework, implemented by ports and
returned from CodenameOneImplementation.getIntentBridge() -- null on
unsupported ports, which makes the whole public API an inert no-op.
Everything crosses this boundary as data: JSON strings produced by the core serializer plus named PNG blobs, never live model objects. The reason is the same one the surfaces framework gives: the peer on the other side is Swift or Kotlin, and an invocation can arrive while the app process has no UI and was started only to answer it. Keeping the wire format to strings is also what leaves the door open to hosting intents in a separate process later without changing a line of Java.
Invocations travel the other way: the port decodes its platform payload and
calls com.codename1.intents.Intents.dispatchInvocation, which owns thread
marshalling, the cold-start queue and the deadline.
-
Method Summary
Modifier and TypeMethodDescriptionbooleanTrue when this port can expose intents to the platform at all.voidclearIndex(String entityType) Removes every entry of one type, or the whole index.voidcompleteInvocation(String token, String resultJson, Map<String, byte[]> images) Hands the platform the outcome of an invocation it started.voidTells the platform the user just ran this intent, so it can suggest it later.voidPublishes app content to the system search index, replacing any entry with the same id.booleanTrue when this port can run an intent without bringing the app to the foreground.booleanTrue when this port can publish app content to a system-wide search index.booleanTrue when a voice assistant can invoke intents on this port.voidregisterIntents(String declarationsJson) Hands the port the application's full intent catalogue during startup, so it can validate against what was compiled into the native app and prepare whatever the platform needs.voidremoveFromIndex(String idsJson) Removes specific entries from the system search index.booleanAsks the platform to bring the application to the foreground, and reports whether it could.
-
Method Details
-
areIntentsSupported
boolean areIntentsSupported()True when this port can expose intents to the platform at all. -
isHeadlessExecutionSupported
boolean isHeadlessExecutionSupported()True when this port can run an intent without bringing the app to the foreground. -
isVoiceInvocationSupported
boolean isVoiceInvocationSupported()True when a voice assistant can invoke intents on this port. False on Android, where no assistant contract of that shape exists. -
isIndexingSupported
boolean isIndexingSupported()True when this port can publish app content to a system-wide search index. -
registerIntents
Hands the port the application's full intent catalogue during startup, so it can validate against what was compiled into the native app and prepare whatever the platform needs.
Parameters
declarationsJson: the serialized declarations
-
donate
-
index
-
removeFromIndex
Removes specific entries from the system search index.
Parameters
idsJson: the serialized{type, id}pairs to remove
-
clearIndex
Removes every entry of one type, or the whole index.
Parameters
entityType: the type to clear, or null for everything this app indexed
-
completeInvocation
Hands the platform the outcome of an invocation it started.
Called at most once per token; the framework enforces that, because the iOS side of this boundary crashes when a continuation is resumed twice.
Parameters
token: the invocation token the port suppliedresultJson: the serialized resultimages: PNG blobs referenced by a snippet; may be empty, never null
-
requestForeground
boolean requestForeground()Asks the platform to bring the application to the foreground, and reports whether it could.
Called when a handler that ran without a window returns a route. The route is navigated either way -- the
Formis built in whatever runtime is up -- but on a headless invocation that runtime has nothing on screen, so without this the destination is created and never seen.True means the application is forward, not that a launch was requested. The framework navigates as soon as this returns, so a port that posts an asynchronous launch and answers true immediately has the route built against a runtime that is about to be torn down -- on Android, by the
stopContextthat follows a headless handler. A port whose launch is asynchronous must wait, and must bound that wait so a launch that never completes degrades rather than hangs.False is a legitimate answer, not a failure. iOS does not let an application bring itself forward; there, foregrounding is decided before the handler runs, by the
openAppWhenRunthe build derives fromopensRoute. A port that answers false is telling the framework to say so rather than leaving the developer to discover it on a device.Never called on the event dispatch thread by a platform-dispatched invocation. An in-process
Intents#invokemay reach it from any thread, including the EDT, which is why a port must answer immediately when the application is already forward.
-