On Monday, 6 January 2020 at 17:18:46 UTC, visitor wrote:
hum ... indeed most of the native samples in android are using java helper classes
Yeah, the NativeActivity is I think the only one that doesn't (and that's just because Google provides a pre-built helper java class).
But I'm personally OK with that; reusing the platform as much as we can is a strength of D, it doesn't have to be all one thing. A little bit of Java gives you hooks into the IDE and stuff and isn't that much work; you can still reuse the majority of a D core.
do you still plan to add the ability to create java classes in D for non-android projects ?
yes. I might not get around to it for a little while and it will very possibly be opt-in with a -version thing (right now I call it WithClassLoadSupport - creating a class would use the same code to work with the binary format). But I do want to do it.
Another challenge would be syntax. D does lambdas and anonymous inner classes... but they probably won't get the magic on them.
It may end up being a helper template, so you'd be like JavaLambda!InterfaceName( a => whatever ); or something like that. I still need to think more about it.
also in this project i made "GlobalRef"s to reuse java objects / classes - thanks for warmly warning about the possible
I plan to address this later too. Probably all return values will conservatively get the global ref unless you declare it as like `Manual!T` instead, which then wraps it for you and uses the type system to determine what needs to be it.
(if you look at the comments of jni.d you can see a lot of my notes to self about problems and possible future directions. Not all of them actually work out, but it gives you some view into what's in my brain.)
(btw, though good to know the trick, in fact i don't need the sourceSets instruction for the jniLibs, i forgot to put the library in the right subfolder ... "x86" or "armeabi-v7a", etc...)
excellent.
