org.apertusvr
package. 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::EventManager
, ape::SceneManager
)and ape::Event
and there are several supporting classes (e.g. apeColor
, apeVector3
). To be able to cast the interfaces, we ha a builder Java interface (apeBuilder
) too.apeEventCallback
function:MyEventCallback
class, e.g.apeManager
's connectEvent(...)
function. E.g., to be able to listen NODE
events, just type:apeEventManager
(which is a static class) puts this eventCallback
into a map:FrameCallback
class, 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 apeEventManager
's fireEvent()
function, which will call the onEvent(apeEvent)
function of our apeEventCallback
implementation, if its instance is connected to the event's group (so the implementation object can be found under the apeEvent.Group.NODE
key in the map).ape::ISceneManager
to give us a weak pointer. Then we use the lock()
function to access it. After calling lock()
, we can also cast the resulted shared_ptr
to 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++.apeFileGeometry
entity 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:apeSceneManager
interface:apeSceneManager
interface!:apeFileGeometry
interface, not apeEntity
.
This is where the apeBuilder
interface come in! The apeEntity
abstract class has a member function called cast
:apeBuilder
interface), we can cast our apeEntity
to any given type extended from it. In the example, we just type:apeFileGeometry
entity 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.ape::System
namespace: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 apeSystem
wrapper class, we type:getAssets()
) for the start function. This will call the JNI-function startApertusVR(...),
which will call the actual ape::System::Start(...)
function. startApertusVR(...)
also initializes apeAAssetOpen library.apeCore.json
, or runtime with the help of the apeSceneNetwork
wrapper. So basically everything goes like in the C++ case:ape::IPlugin
interface. Developing on Android and Java, they have a different form. Our Java plug-ins are actually Android implementations of the AndroidLifecycleObserver
interface.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 LifecycleObserver
interface as it was a plug-in(ish thing):LifecycleObserver
interface):Activity
subclass supports lifecycle-aware components. AppCompatActivity
specially supports it.apeCoreCinfig.getConfigFolderPath()
.