The Android port handles the NativeActivity interface internally and wraps everything up nicely so that you can only have a main() in your code.
All the NativeActivity stuff is stored internally, but in some cases users might want access to those to make JNI calls. Maybe to use Google Play or Google Play Games services. Or even just some custom libraries that exist on the Java side of things.
You can get access to all those things through one simple interface, but there are a few problems with that.
The biggest problem is that it is not part of the "public" API of SFML. Does SFML expose platform specific calls at all?
Second issue is that generally when those pointers are accessed, they main NativeActivity thread should be locked. So you can't just expose the pointers, because they are "owned" by the NativeActivity thread.
A general guide is to have a locking interface like this:
sf::ActivityStates* states = NativeActivityAttachToThread(); // Locks the mutex.
// ...make your JNI calls...
NativeActivityDetachFromThread();
Would there be an nice enough way to add this to SFML?
Don't think returning the whole states object would be a good idea.
What would you need to be returned? A pointer to the JNI environment?
Would probably suggest something like this:
namespace sf {
class Environment {
// This could take other generic environment things such as accessing environment strings like PATH
static sf::String getString(const sf::String& name, const sf::String& default);
...
#ifdef ANDROID
static void* lockJNI(const char major = 1, const char minor = 6);
static void unlockJNI();
#endif
};
}
Why using #ifdef rather than dummy implementations? Because I think this is a very special case. The actual function call won't do anything by itself and you'd want to use it in conjunction with other JNI/Android only calls anyway. As such the surrounding/calling code should be excluded on other platforms anyway.