Second call to OFAndroid.init() doesnot hit the native code

Hi @arturo
I have written code to return landmark points from native to android side via JNI.
The flow be like :-

  1. Select image
  2. Pass it to OF via JNI
  3. OF reads image & find points
  4. Return points to android via JNI

It works well for the first image but for the next image, the processing goes into infinite loop.
By debugging I could see that the OFAndroid instance is created. Android program control reaches init() method; but the further native calls (init, main) are not called.

Not able to figure out why is this behaviour observed. Please reply

I’m not arturo, but I can do my best to help with this. Can you please share the piece of relevant code? Perhaps a minimal example that shows the issue?

@tallavi will surely be able to answer this better since he’s designed the new android lifecycle classes. also for something like this you might want to use the nightly builds instead of 0.9.8 since that includes @tallavi’s new functionalities which will allow you to open more than one OF instance if that’s what you really need

Hey @tallavi @arturo
Thanks for your reply.
I was vigorously working to have this fix. Thus, the reply has been late. Sorry for that.

The issue is fixed by a small change. Only the setup variable in OFAndroidWindow is marked false everytime with the destroy call. As this is required for the project.

The OFx control flow was not that clear to me, so it took that much time. Else it was a pretty small issue.

@tallavi @arturo If you could answer : Do we have any source to understand the OFx program control flow for beginners ? Any resource specific to android ? That would be a great help. :slight_smile:

@arturo

I see below nightly builds available
of_v20170106_vs_nightly.zip
of_v20170106_osx_nightly.zip
of_v20170106_msys2_nightly.zip
of_v20170106_linuxarmv7l_nightly.tar.gz
of_v20170106_linuxarmv6l_nightly.tar.gz
of_v20170106_linux64gcc6_nightly.tar.gz
of_v20170106_linux64gcc5_nightly.tar.gz
of_v20170106_linux64_nightly.tar.gz
of_v20170106_ios_nightly.zip

Cannot figure out which one to use for android ?

@Akash, glad you resolved the issue. Would you like to share what was the mistake? Perhaps there’s something to be learned from it to make it clearer for future folk?

Regarding the control flow, that’s a bit of a general question, but generally speaking, openframeworks for android is just like for any other operating system. You write your rendering code inside ofApp. The rest of the classes is boilerplate and bootstrapping.

In ofApp there are 3 methods. setup which is called once, and update/draw that are called every frame.

If your case requires adding java UI to the activity, you can change OFAndroid.java and you will still have the canvas in the background.

If you have any specific questions, do ask.

@tallavi
Actually my attempt was to override the basic functionality of OF. setup is called only once.
I wanted to have setup called everytime with new instance of OFActivity.
And leave update() & draw() untouched because they are called repeatedly.

There’s a very little change :-
in OFAndroidWindow.java
changed

 private static boolean setup;

to

 public static boolean setup;

In OFAndroid.java
added

 OFAndroidWindow.setup=false;

in the destroy() method

Actually, I believe we had quite a similar requirement in our project, but decided on a different solution (that didn’t require changes in OF, other than the ones I already submitted as PR):

We wanted different activities showing different GL content, but setup() is only called once, so we decided to not use it at all. Instead of doing the actual drawing in the ofApp, the ofApp class just takes the current “view” from a singleton pointer, and delegates the drawing to it:

in update:
m_glView = Core::Views::ViewsMediator::getView();
if(m_glView){
m_glView->update();
}

in draw:
ofClear(0, 0, 0);
if(m_glView)
m_glView->draw();

m_glView.reset();

Since setup is only called for the first frame, we are not using it. Instead we keep a flag in our views, and on first update for a view we call its setup method.

This infrastructure, in combination with the new ability to show the OF canvas on multiple activities lets us achieve this.

Hope it’s clear enough.