Explain ForegroundWorker's main use case.

This commit is contained in:
Joseph Cloutier
2022-06-03 18:04:32 -04:00
parent c48f1fb44a
commit f70b43a543
2 changed files with 20 additions and 0 deletions

View File

@@ -14,6 +14,8 @@ import neko.vm.Thread;
/** /**
An object whose instance functions always run on the main thread. If called An object whose instance functions always run on the main thread. If called
from any other thread, they'll switch to the main thread before proceeding. from any other thread, they'll switch to the main thread before proceeding.
This is important for Android apps that use JNI, as most times a Java class
calls a Haxe function, it does so on the UI thread.
Usage: Usage:

View File

@@ -3,6 +3,24 @@ package lime.system;
#if (!lime_doc_gen || android) #if (!lime_doc_gen || android)
import lime._internal.backend.native.NativeCFFI; import lime._internal.backend.native.NativeCFFI;
/**
The Java Native Interface (JNI) allows C++ code to call Java functions, and
vice versa. On Android, Haxe code compiles to C++, but only Java code can
access the Android system API, so it's often necessary to use both.
For a working example, run `lime create extension MyExtension`, then look at
MyExtension.hx and MyExtension.java.
You can pass Haxe objects to Java, much like any other data. In Java,
they'll have type `org.haxe.lime.HaxeObject`, meaning the method that
receives them might have signature `(Lorg/haxe/lime/HaxeObject;)V`. Once
sent, the Java class can store the object and call its functions.
Note that most Java code runs on a different thread than Haxe, meaning that
you can get thread-related errors in both directions. Java functions can
use `Extension.callbackHandler.post()` to switch to the UI thread, while
Haxe code can avoid the problem using `lime.system.ForegroundWorker`.
**/
#if !lime_debug #if !lime_debug
@:fileXml('tags="haxe,release"') @:fileXml('tags="haxe,release"')
@:noDebug @:noDebug