I'm building an audio / music app. in Android. And because of this I'm using the new Oboe C++ library.
I'm wondering how people do graphics and UI in Android with NDK applications.
I don't think I need OpenGL or a low level, fast graphics library. This isn't a game. I really just need to pick up different touches in different locations / from some custom UI widgets. (But I do need multitouch).
Is there a convenient highish-level API for doing the drawing and picking up touches from C++? If so, what is it? Or would I be better doing all the UI in Java and just calling down to the NDK for the audio?
This is the first time I'm trying to work with Android NDK and the Oboe examples I've looked at don't really draw anything in C++. The one "hello world" example, uses Java widgets. And the others don't really draw anything on the screen at all.
To be clear, Multitouch events are handled and made available by the Java/Kotlin side of the Android Framework so you would need to pass those down through the JNI level. A reason to draw at the NDK layer is to reduce the latency of passing a result back up through the JNI layer to the Java/Kotlin layer which would have to update any widget/view.
Related
i'm new to use ARCore (and to android programming, as i mostly did desktop asm/C/Linux/Windows/RPi stuff), and i dont really like JAVA or anything that is forcefully object oriented (as in built-in OOP features, not the general OOP concept... i.e. its fine to use COM from C for example), so that said...
its possible to use ARCore to make a complete augmented reality for android using mostly C and NDK? like using next to nothing from the java side, to the point that once you do the initial skeleton to handle the UI events, everything else, capturing/rendering/management/etc... can be done from the C side?
two years ago i developed an Augmented Reality framework on android-7 (Eclair). Since AR application are computationally intensive task, I developed a JNI c++ library used by a Java activity to render and register the virtual environment. The sensor readings acquired in Java are passed to the underline c++ library to compute the registration of the virtual environment. Tridimensional objects are rendered by a native draw function called from a GLSurfaceView. This results in a lot of JNI call.
Now I would like to port the application to android-15(Ice Cream Sandwich). Starting from android-9(Gingerbread) Android allows to use NativeActivity.
I would like to understand which is the better way to develop an AR application. Since every JNI calls introduce an overhead it would be much better to avoid them. Is it possible using NativeActivity? I didn't find an exaustive guide that explains how NativeActivity works but reading this document it seems that it results in a lot of JNI calls anyway. Is there any architectural document that explains how NativeActivity works? Is NativeActivity just a "JNI wrapper" to avoid java code? Concerning performances,are there any advantages using NativeActivity instead of a JNI library as I done before?
Thanks a lot.
NativeActivity will not give a performance boost to your framework. It still uses JNI to communicate with the System, only under the cover.
Moreover, there are good reasons not to use it. If I understand your purpose correctly, you want other applications to take advantage of your code. By forcing them to use NativeActivity you seriously reduce their freedom, and require that they struggle with a less familiar environment. There is a number of limitations with NativeActivity, e.g. it cannot load more than one JNI library.
Finally, I would suggest a completely different direction if you look for optimization of your AR framework: you can use the new setPreviewTexture() API.
As far as I understand it you still are bound to JNI also when using NativeActivity. This class can be used as starting point and encapsulates some functionalities for your convenience but the underlying technology to access native code has not changed and ist still JNI. So in my opinion you only can do some benchmarks to check if NativeActivity is more efficient for some reason (may be the guys at Google do know some hacks that make it faster than your solution).
I'm using the libraries LIBGDX to make an application and be able to run on both Android as a computer. I'd like to introduce a new library to create graphs in android, but do not know if I can add libraries that are for use with Android and libgdx and also running on the computer.
Nor if you can work in a similar way to how you normally program in android, and I want to do the designs from the GUI of android that I'm used to and I find it more comfortable. Also when the xml type strings.xml for example, I wonder if I can use them or not. Thank you.
There are two ways to build libraries (really, any code at all) that runs with libGDX:
Use only the libGDX-provided APIs. For example, if you render your graphs with the OpenGL wrapper provided by libGDX, it will work everywhere. Or if you use the "scene2d" UI APIs, it will work everywhere.
Implement a generic front-end library that uses libGDX APIs, and then calls out to backend-specific libraries that implement platform-specific bits. For your example, that would entail building an Android-based backend that perhaps used Android-specific UI rendering, and then building a separate desktop-based backend that perhaps used Swing or some other Java-desktop-specific APIs.
If all of your code is using the second approach, you're not really getting much benefit from libGDX.
I need to port an existing application from iOS to Android,
The Application have core component implemented in C++
UI is specific to iOS implemented in Cocoa Framework,
I am good in C++ , objective C , average in Java
I wanted to know, the feasibility of developing android application, which has UI Part written in Java(UI) and Core Protocol implemented in C++, through googling, it seems Android NDK will come into Picture, but wanted to know, how complex to have such kind of Architecture,
Its possible with NDK, but you will need to make several JNI calls, and it gets messy sometimes, especially when you are new to Android.
The alternative method is to create all UI in C/C++ itself, with your own UI library.
This method is painful but it reap rewards in the long run if you are making a lot of apps which can cross port to ios/android, cutting down on UI rewrite costs.
The Android NDK has just been significantly expanded to include support for writing android applications entirely in native C/C++ code. One can now capture input events on the keyboard and touch screen using native code, and also implement the application lifecycle in C/C++ using the new NativeActivity class.
Given all the expanded native capabilities, would it be worthwhile to completely bypass Java and write Android application in native code?
The NDK is not native per-se. It is to a large extent a JNI wrapper around the Android SDK. Using NativeActivity gives you a convenient way of dealing with certain app-life cycle events, and add your own native code on top. ALooper, AInputQueue etc. are all JNI wrappers of the Java SDK counterparts, some with additional code that is private and unaccessible for real apps.
When it comes to Android development, there's no such thing as writing an application entirely in native C++ - you will (in every real App case that I can think of) always need to use the Android API:s, which are to a huge extent pure Java. Wether you use these through wrappers provided by the NDK or wrappers that you create yourself doesn't really change this.
So, to answer your question: No, it wouldn't be worthwhile, because you would end up writing JNI wrappers for SDK calls instead of writing JNI wrappers to your own Java methods that do the same thing, with less code, simpler code and faster code. For example, showing a dialog using "pure c++", involves quite many JNI calls. Just calling a Java method through JNI that does the same thing will give you faster code (one JNI call), and, arguably, code that is easier to maintain.
To fully understand what you can do, you really must examine the Android source code. Start with native_app_glue.c, which is available in the NDK, then continue with the OS implementation of AActivity, ALooper, AInputQueue etc. Google Code Search is a great help in this. :-)
If it is easy to do in Java, and includes many calls, call a method through JNI that does it all, rather than writing all the extra code to do it with multiple JNI calls. Preserve as much of your existing C++ code as is reasonable.
Not if you are just making a standard application. The Java SDK is more complete than its Native counterpart right now so you would still be making things more difficult for yourself.
If you are not doing something that requires the NDK (read: real time performance sensitive) then stick with Java.
Just some food for thought but if you have an app on iOS and Android, some C/C++ code might be shareable. Obviously the iOS Obj-C and platform specific code wouldn't work elsewhere. (Ditto for the Android specific stuff). But you might be able have some shared code that's platform neutral.
If you can, stick with the java style apps until versions of Android supporting native activities constitute a significant fraction of the installed base.
For things that were hard to do before - particularly ports of existing code - this will probably be a big help.
It's not entirely clear yet what has changed vs. just writing your own thin java wrapper. For example, is there still a copy of the dalvik VM hanging around?