Name Description Size Coverage
qharmonyappjscontext.cpp ! \class QHarmonyAppJsContext \inmodule QtCore \brief The QHarmonyAppJsContext class gives code on the JS thread of a HarmonyOS application access to the application's state. QHarmonyJsContext describes the JS runtime. QHarmonyAppJsContext holds the state of the application in that runtime, such as its default \c UIAbility instance. Keeping the two apart makes function signatures meaningful. A function that takes a QHarmonyAppJsContext depends on the application's state. A function that takes a QHarmonyJsContext needs only the runtime. A task gets the application context once, with fromJsContext(), and passes it on. The class derives from QHarmonyJsContext, and there is only one object. QHarmonyJsContext::fromEnv() returns it as the base class. All member functions must be called on the JS thread. References to it and its \c napi_value results follow the lifetime rules of QHarmonyJsContext. \sa {Qt for HarmonyOS Platform API} 3221 -
qharmonyappjscontext.h 715 -
qharmonyjscontext.cpp ! \class QHarmonyJsContext \inmodule QtCore \brief The QHarmonyJsContext class gives code on the JS thread of a HarmonyOS application access to the JS runtime. On HarmonyOS, Qt runs the application on its own thread. The ArkTS runtime and the platform UI run on the main thread of the process, called the JS thread. Platform APIs are only available on the JS thread. To run code there, use QNativeInterface::QHarmonyApplication::runOnJsThread(). The code receives a QHarmonyJsContext as the task argument. JS callbacks created with \c napi_create_function() receive only a \c napi_env. They get the context with fromEnv(). QHarmonyAppJsContext provides the state of the application in the runtime, such as its default \c UIAbility instance. To get it, call QHarmonyAppJsContext::fromJsContext(). All member functions must be called on the JS thread. A \c napi_value that they return is valid until the task or callback that obtained it returns. It must not be passed to another thread. To keep a JS object longer, use a QHarmonyJsObjectRef. A QHarmonyJsContext reference is valid as long as the \c napi_env of the context, which is until the task or callback that received or obtained it returns. Get the context again in each task or callback. \sa {Qt for HarmonyOS Platform API} 3395 -
qharmonyjscontext.h 732 -
qharmonyjsobjectref.cpp ! \class QHarmonyJsObjectRef \inmodule QtCore \brief The QHarmonyJsObjectRef class keeps a JS object of a HarmonyOS application alive and lets other threads hold a reference to it. \reentrant A \c napi_value is valid only on the JS thread, and only until the task or callback that obtained it returns. A QHarmonyJsObjectRef holds a strong reference to the object instead. You can copy, store, and compare it on any thread. On the JS thread, value() returns the object again. The reference is released when the last copy is destroyed, on whichever thread that happens. The release itself runs asynchronously on the JS thread, so the JS object may outlive the last copy for a short time. Two references compare equal when they refer to the same JS object, even if they were created independently. \sa {Qt for HarmonyOS Platform API} 5914 -
qharmonyjsobjectref.h 1658 -
qharmonyjsonconversions.cpp ! Returns a new JS object in \a env with the properties of \a jsonObject, for use on the JS thread. Nested objects and arrays become JS objects and arrays; JSON null becomes JS \c null. Returns \nullptr, logging the error and leaving no exception pending, if a JS exception is raised during the mapping. This is how a request object, for example a \c Want, is built for a platform API call from Qt data. 2533 -
qharmonyjsonconversions.h 669 -
qharmonynativeinterface.cpp ! \class QNativeInterface::QHarmonyApplication \brief Native interface to a core application on HarmonyOS. Accessed through QCoreApplication::nativeInterface(). On HarmonyOS, the ArkTS runtime and the platform APIs run on the main thread of the process, called the JS thread. The Qt application runs on a separate thread, called the Qt thread. This is the thread of the QCoreApplication object. This interface runs application code on the JS thread, where the code receives a QHarmonyJsContext. It also brings results back to the Qt thread. Code that runs on the JS thread must follow these rules: \list \li It must not wait for the Qt thread, which may itself be waiting in runOnJsThreadAndWait(). Send results back asynchronously, with runOnQtThread() or through QPromise. \li It must not access Qt-thread objects directly, not even through a QPointer. A QPointer is created, checked, and dereferenced only on the thread of its object. The JS thread only passes copies of it along. The functor posted to the Qt thread checks the QPointer there. \li A JS callback may run after the Qt event loop has finished. Tasks that it queues with runOnQtThread() then never run. \li A \c napi_value that it obtains is valid until the task returns, and must not leave the JS thread. To keep a JS object longer, use a QHarmonyJsObjectRef. \li Resources bound to the JS engine, such as references and listeners, must be released on the JS thread. \li The JS thread also runs the platform UI, so tasks must be short. \endlist Each task runs inside its own Node-API handle scope. A C++ exception that a task throws and a JS exception that it leaves pending are caught and logged on the JS thread. A task that needs to react to a failure must handle it itself. \inmodule QtCore \inheaderfile QCoreApplication \ingroup native-interfaces \ingroup native-interfaces-qcoreapplication \sa {Qt for HarmonyOS Platform API} 5668 -
qohosappcontext.cpp 659 -
qohosappcontext_p.h 885 -
qohoscommon_p.h 17273 -
qohosjsonconversions.cpp 4935 -
qohosjsonconversions_p.h 1057 -
qohosjstools.cpp 7123 -
qohosjstools_p.h 4315 -
qohoslogger.cpp 1542 -
qohoslogger_p.h 3666 -
qohosmemoizingjsthreadfetcher.cpp 2226 -
qohosmemoizingjsthreadfetcher_p.h 3980 -
qohospathutils.cpp 1452 -
qohospathutils_p.h 764 -
qohospermissionshelper_p.h 1641 -
qtharmony.qdoc 416 -