From the migration doc I see : https://www.wikitude.com/external/doc/documentation/7.0/androidnative/migration-androidnative.html#migrate
Plugin update() method has changed and that's all.
But when I use plugins... Plugin class is completely deprecated, pluginManager cannot longer register Java plugin !
And, according to the doc, PluginManager is still the the way of doing this so... I'm a bit lost !
Can you help me please ?
At the moment we're not sure how to proceed with non C++ plugins. Our Android SDKs are the only one that offers non C++ plugin. The Java plugin was developed as a side project and never fully finished. I know that the usage of C++ plugins within Java is not that easy, so we will either improve the overall plugin handling or fully support Java plugins.
It's good to know that developer look for a way to get easy camera access through plugins. This helps to make the right decisions for next releases, so if you want to share more thoughts, you're more than welcome ;)
Maybe I'm the only one doing an implementation with my own rendering engine, but I got some issues with Wikitude integration. Most of the AR engine just offer minimalist access to low level datas from library and it's something very frustrating : For my part, I need to have camera's FOV for exemple, but since Wikitude manage the camera, I cannot get the parameters so my 3D engine cannot have the same FOV of the camera, so, the only solution was to start the camera first, get parameters, close camera, and then let Wikitude start it again... This is not pretty at all but it's an example of the workaround needed when the library is not very designed for other integration on custom 3D engines.
To get the camera frame buffer, the plugin is a good solution, I would expect the Wikitude api to provide it without plugin but Java plugin works well and do the job. But if 7.x release remove java plugin, I'm not sure I'll use C++ plugin for this kind of basic datas other AR library provides. C++ usage in a already complex Java project, just to get some very "classic" AR datas as camera picture buffer is very painful.
Maybe providing the plugins features into the core api could avoid having to maintain them if not required, simple callbacks could make the same and are simple to manage.
I see the Java api changing, but I'm afraid of some changes that will make it less handy.
Another example : getting camera resolution : no way. I can set the startup configuration with an enum, but if I just need pixel X and Y size I need to make it by myself. I can seems to be irrelevant when you are deciding what to allow or not, but when you can set something, getting this same thing sounds logical to my mind.
If I can add some more advices, the documentation is very minimalist and not always understandable. I mean, creating an AR application is nor hard but as soon as you need advanced things, you'll need to come to the forum and ask for more explanations. (for example, it tooks me hours of searching and test to understand that camera'as YUV buffer is NV12 encoding since it never appears on the documentations, and about scene scale I'm still not sure how to manage it)
Theses little things make the api a little bit frustrating some times.
Since you asked me to share my thoughts, here they are, hoping my bad english is understandable. Thanks for your interest.
BTW, I'll continue using plugins since it's still working.
Did you had a look at our example application? It registers a couple of C++ plugins as documented here.
You should only use C++ plugins and not Java plugins.
Javascrip API shows C++ plugin, but since last version, we were able to set Java plugin to get each camera Frame for example.
In version 7 this is still working but deprecated, does it mean next revision upper to 7.0 will remove all Java plugin feature ?
I'll need to use C++ even fro very basic and simple plugin ?!
Thank you very much for the detailed reply! It's nice to get such detailed and honest response from our customers.
We started our JS API SDK as 'closed system', so that it's easy to use and hard to misuse. Requirements changed over time and that's why we developed the Native API SDK. It offers more customisation then the JS API SDK but is at some points still not open enough as it seems.
Right now we started development on something new and I will take your feedback into account while designing the new bits ;)
To answer some of your questions: Most things you asked for (camera resolution, colour space, ... ) are available in the `Frame` C++ class. A `Frame` object is passed to the `Plugin::cameraFrameAvailable` method every time a new frame is available.
Because the Android API doesn't guarantee a certain camera resolution, we also added the static `resolveCameraResolution` method to the `WikitudeSDK` Java class. This method helps to convert the StartupConfiguration resolution setting to the actual camera resolution for a specific device.
The scale topic for instant tracking is something we're working on. Right now you only have the 'Device height above ground setting' that user can use to adjust the global scale of the scene.
Thanks again for your feedback and keep asking questions for everything that is unclear to you so that we can help!