Vivat NativeActivity, no need for native_app_glue

[W. Boeke]

In textbooks about the NDK always they refer to native_app_glue as the standard way to communicate between Java and C. But actually, native_app_glue is very restrictive. Only a small subset of all functionality provided by the Android framework is made available to the native part.

Another interface between Java and C is NativeActivity, where the native and the Java environment are in the same thread. Thus, if a native procedure takes a long time you get an ANR. However, the same happens if a Java procedure takes a long time. I can't see no difference here.

In most computer programs there has to be a queueing mechanism to synchronize between separate threads and the main thread. Why not use this together with NativeActivity? I tried it and it works perfectly. The events in my inter-thread queue are C++ lambda's, which is convenient because now you need only one event type for this queue. All statements in the callbacks from NativeActivity, as well as all other JNI calls are added to this queue. The input events (touch etc.) are already in a queue provided by NativeActivity, they don't have to be queued by me.

Using NativeActivity this way, there is actually no problem how functionality is devided between the Java and the native program parts. Calling Java from C will of course always stay a horrible hack, but there exist several ways to avoid that.

Wouter Boeke

[jje...@istation.com]

Sound interesting.  Would you be so kind as to post a sample of what you are talking about?

[W. Boeke]

Hi.

I made a small demo program to illustrate my points. It can be downloaded here:

http://members.chello.nl/w.boeke/ct-gui/CT-demo.tar.gz

There is also a README file.

W.Boeke