Will the Android NDK article be updated for use with Mercury? I’m assuming the Declare statement will be used as normal for obtaining the function from the library.
I’ll look at getting that updated asap, first thing next week. i assume you mean Creating an Android NDK Extension?
If so, all the code shown there is in the shipping Mercurty template:
Imports rtl
' ToDo: Update the ClassName and function name below, to match your Android app
<JNIExport(ClassName := "org.me.androidapp.MainActivity")>
Public Function HelloFromNDK(env as Ptr(Of JNIEnv), this as jobject) as jstring
Return env.Dereference.Dereference.NewStringUTF(env, "Hello from NDK!")
End Function
but i’ll get the topic updated now.
Note that’s for the NDK side. on the SDK side we have a problem with for now, as VB relied on DllImport to detect native functions, and doesn’t have a keyword like C# or Oxygene, but JNI doesnt use DllImport of course.
I’ll have to log an issue to get that fixed/supported;
Logged as bugs://E25477.
Yes, that was the example I was thinking of.
If I’m not mistaken, the JNI* attributes handles the name mangling. Shouldn’t you be able to access it by using Declare Sub/Function Lib “libname.so” with the JNIImport attribute applied to the definition? I haven’t looked at the IL code in .NET to see exactly what this statement does so it’s just a guess.
Worth a try. I’m not sure, as I don’t do much Android myself, but IIRC there’s no attribute used on the managed (Java) side, for JNI, only the “extern(al)”/“native” keyword. Which VB/Mercury right now doesn’t have, so the compiler has no way to distinguish an empty function from an external one.
But i’ll have that looked at and (if necessary) fixed, Monday.
Update: there’s no JNIImport attribute AFAICT; we only have JNIExport, on the unmanaged/native side.
bugs://E25477 was closed as fixed.
Documentation also updated. vNext will support
<External>
Public Function HelloFromNDK() As String
End Function
Thanks for the addition. Now out of curiosity, will the Declare Lib statement be used normally for dynamically loading code from external libraries/object files at runtime?
I’m not familiar with that, I’ll have to check with my colleague, tomorrow. But it looks like that don’t be needed here, just declare the function you want to import using <External>
, leave the body empty, and the JNI runtime does the rest.
Actually, id i use this on Java i get
Declare Sub Foo Lib "Name" // E28 Unknown type "System.Runtime.InteropServices.DllImportAttribute"
so i assume this syntax is supported by Mercury, but not currently for Java (as the Attribute is doesn’t exist there). I suppose we could support a similar variant (optionally minus the “Lib <name>
”) on Java.
Logged as bugs://E25482.
Very cool, the attribute option is good to have in general, yet the Declare statement has always historically been used for external declarations in VB. Lib also loads the object file in which the function resides, maybe this can be altered to support the Java/Island platforms?
I’m not sure if JNI supports that. Since it doesn’t need it, Lib
will either be optional (if we can provide a name), or not supported.
Declare
will be supported on Java in tomorrow’s build.
bugs://E25482 was closed as fixed.