org.apertusvrpackage. For each ApertusVR entity type there's a corresponding Java wrapper class. Also there are a wrapper classes for the manager classes (e.g.
ape::Eventand there are several supporting classes (e.g.
apeVector3). To be able to cast the interfaces, we ha a builder Java interface (
connectEvent(...)function. E.g., to be able to listen
NODEevents, just type:
apeEventManager(which is a static class) puts this
eventCallbackinto a map:
FrameCallbackclass, which implements Android's built in
Choreographer.FrameCallback. Like in the following code block:
processEventDoubleQueue()is a JNI-function, which calls back to Java with
fireEvent()function, which will call the
onEvent(apeEvent)function of our
apeEventCallbackimplementation, if its instance is connected to the event's group (so the implementation object can be found under the
apeEvent.Group.NODEkey in the map).
ape::ISceneManagerto give us a weak pointer. Then we use the
lock()function to access it. After calling
lock(), we can also cast the resulted
shared_ptrto the proper type (
ape::Entity::Type), if we know what the entity's type should be. When using ApertusVR from Java, we just use the interface's constructor to get access to an entity, then we check with the
isValid()function, that we can actually lock it in C++.
apeFileGeometryentity we know about, with the name of
"FooBar", and our goal is to query its
OwnerID. The procedure goes something like on the following code example:
apeEntity. This is where the
apeBuilderinterface come in! The
apeEntityabstract class has a member function called
apeBuilderinterface), we can cast our
apeEntityto any given type extended from it. In the example, we just type:
apeFileGeometryentity with the
apeEntity's name you got from
apeSceneManager(like you saw it in the former sub-subsection).
onCreate(...)function is called) by Android , we have to do three things:
choreographer = Choreographer.getInstance(). Not a big deal. The 2nd needs further explanation, and we will go through the 3rd in the next section.
configFolderPath), which contains necessary informations. On Android it is stored in the assets folder of the given application. Therefore, when calling this method through the JNI-interface and the
apeSystemwrapper class, we type:
getAssets()) for the start function. This will call the JNI-function
startApertusVR(...),which will call the actual
apeCore.json, or runtime with the help of the
apeSceneNetworkwrapper. So basically everything goes like in the C++ case:
ape::IPlugininterface. Developing on Android and Java, they have a different form. Our Java plug-ins are actually Android implementations of the Android
LifecycleObserver. Classes implementing this interface (called lifecycle-aware components) can be attached to the activity's lifecycle as something which constantly observes its lifecycle, and respond to the events occouring during the activity's lifetime. To learn more about lifecycle-aware components, again please read the Android guide on the given topic.
apePlugin, which only presents a
LifecycleObserverinterface as it was a plug-in(ish thing):