Generated reference › API — ICoreEssentials/UI/Backends/Web/EmscriptenOnAndroid
kind: generated#api#icoreessentials-ui-backends-web-emscriptenonandroid

API — ICoreEssentials/UI/Backends/Web/EmscriptenOnAndroid

The public contract of 5 header(s) under ICoreEssentials/UI/Backends/Web/EmscriptenOnAndroid — 0 class/struct definition(s), 0 declaration(s). Each section shows the header's banner and its public (and protected-virtual) surface exactly as the file writes it.

HeaderDefinesDeclarationsBases
em_js.h—0—
emscripten.h—0—
eventloop.h—0—
fetch.h—0—
html5.h—0—

em_js.h#

ICoreEssentials/UI/Backends/Web/EmscriptenOnAndroid/emscripten/em_js.h

⚠ NOT EMSCRIPTEN'S em_js.h. The Android build's stand-in for it (Android port, TB3.3), on the include path of an android configure only; the web build never sees this directory and uses the real one.

The Android backend compiles the web backend's files where they stand. Their platform half is EM_JS: a JavaScript body behind a C function name. Here EM_JS keeps the NAME and drops the body -- it becomes an ordinary extern "C" declaration -- and UI/Backends/Android/ defines each such function over JNI. So a web file compiles for Android without a line of it changing, and its JavaScript is replaced function by function rather than file by file.

It lives in the web zone because it names Emscripten, and naming Emscripten is that zone's business (tools/toolkit_boundary_backends.txt). Nothing here is compiled into the web build: these are headers, and the web zone's source

Declares no class of its own — see the file.

emscripten.h#

ICoreEssentials/UI/Backends/Web/EmscriptenOnAndroid/emscripten/emscripten.h

⚠ NOT EMSCRIPTEN'S emscripten.h -- the Android stand-in; em_js.h beside this file says why. Only what the web files compiled into an Android build use.

Declares no class of its own — see the file.

eventloop.h#

ICoreEssentials/UI/Backends/Web/EmscriptenOnAndroid/emscripten/eventloop.h

⚠ NOT EMSCRIPTEN'S eventloop.h -- the Android stand-in; em_js.h beside this file says why. A browser timeout, on the program's own loop: the callback runs on icore-main at the next tick after msecs, through ICoreWebLoop's timers.

Declares no class of its own — see the file.

fetch.h#

ICoreEssentials/UI/Backends/Web/EmscriptenOnAndroid/emscripten/fetch.h

⚠ NOT EMSCRIPTEN'S fetch.h -- the Android stand-in; em_js.h beside this file says why. Android port, TB0.10: the web HTTP seat (Network/Backends/Native/Web/ICoreHttpClient.cpp) compiles for Android where it stands, and this is the fetch API it is written against, answered by UI/Backends/Android/Network/ICoreAndroidFetch.cpp over HttpURLConnection.

It keeps Emscripten's shapes and names, and its CONTRACT as the seat uses it: every callback runs on the thread that started the fetch (the program's own), never inside emscripten_fetch() itself; a STREAM_DATA fetch hands the body to onprogress chunk by chunk and never to onsuccess; a non-2xx answer ends in onerror with its status, a network failure in onerror with status 0; and emscripten_fetch_close() on a fetch still in flight calls onerror synchronously (status 65535) and then frees it.

Declares no class of its own — see the file.

html5.h#

ICoreEssentials/UI/Backends/Web/EmscriptenOnAndroid/emscripten/html5.h

⚠ NOT EMSCRIPTEN'S html5.h -- the Android stand-in; em_js.h beside this file says why.

Declares no class of its own — see the file.