How to use your own activity? Can it be combined with traditional activities?

Question

I have two libraries (.so) that I load into java code.

However, there are several specific operations that require Java (Activity) ↔ C ++ (. So files) calls.

Can I use Native Activity to implement some of these functions? Is the native activity something that is complementary to the traditional activity, or do I need to choose which type of activity I will use?

[EDIT]

there is a set of events that can be processed in native code using active activity

Android NDK / sources / Android / native_app_glue / android_native_app_glue.h

enum { /** * Command from main thread: the AInputQueue has changed. Upon processing * this command, android_app->inputQueue will be updated to the new queue * (or NULL). */ APP_CMD_INPUT_CHANGED, /** * Command from main thread: a new ANativeWindow is ready for use. Upon * receiving this command, android_app->window will contain the new window * surface. */ APP_CMD_INIT_WINDOW, /** * Command from main thread: the existing ANativeWindow needs to be * terminated. Upon receiving this command, android_app->window still * contains the existing window; after calling android_app_exec_cmd * it will be set to NULL. */ APP_CMD_TERM_WINDOW, /** * Command from main thread: the current ANativeWindow has been resized. * Please redraw with its new size. */ APP_CMD_WINDOW_RESIZED, /** * Command from main thread: the system needs that the current ANativeWindow * be redrawn. You should redraw the window before handing this to * android_app_exec_cmd() in order to avoid transient drawing glitches. */ APP_CMD_WINDOW_REDRAW_NEEDED, /** * Command from main thread: the content area of the window has changed, * such as from the soft input window being shown or hidden. You can * find the new content rect in android_app::contentRect. */ APP_CMD_CONTENT_RECT_CHANGED, /** * Command from main thread: the app activity window has gained * input focus. */ APP_CMD_GAINED_FOCUS, /** * Command from main thread: the app activity window has lost * input focus. */ APP_CMD_LOST_FOCUS, /** * Command from main thread: the current device configuration has changed. */ APP_CMD_CONFIG_CHANGED, /** * Command from main thread: the system is running low on memory. * Try to reduce your memory use. */ APP_CMD_LOW_MEMORY, /** * Command from main thread: the app activity has been started. */ APP_CMD_START, /** * Command from main thread: the app activity has been resumed. */ APP_CMD_RESUME, /** * Command from main thread: the app should generate a new saved state * for itself, to restore from later if needed. If you have saved state, * allocate it with malloc and place it in android_app.savedState with * the size in android_app.savedStateSize. The will be freed for you * later. */ APP_CMD_SAVE_STATE, /** * Command from main thread: the app activity has been paused. */ APP_CMD_PAUSE, /** * Command from main thread: the app activity has been stopped. */ APP_CMD_STOP, /** * Command from main thread: the app activity is being destroyed, * and waiting for the app thread to clean up and exit before proceeding. */ APP_CMD_DESTROY, }; 

since I know that part of my code (which should be called after a certain event) is written in C ++, I think it would be better to deal with this in C ++ through native Activity. However, I have code that needs to be called after processing events in Java.

the question is ... can I have my own version (my own interface) of my activity that will help me with some events and the traditional java interface for the same activity at the same time?

Answer 1

I would answer that you cannot have two versions of the code of one action.

• How would you indicate this in your manifest?

• In an example provided by Google, the body text comment is pretty explicit:

It works in its own thread, with its own event loop to receive input events and perform other actions.

Native activity will process all events in the while(1) {...} . Mixing Java and native events will be impossible.

IMHO, the main reason for using your own activity is the user interface. If you already have a fully functional user interface in C ++, then it’s even more portable for you to use your own activity. You can configure the Android application to add another java activity (do not forget to put android:hasCode="TRUE" in your manifest!). In another case, the use of java activity allows you to fully use the Google user interface and, if necessary, call your own library.

About your performance question when you say:

I think it's best to handle this in C ++ through native Activity

take a look at this: http://developer.android.com/guide/practices/design/performance.html#native_methods

Hope this helps!