Passing a reference of a NativeInterface instance as parametter of another NativeInterface method?

[Thomas]

I wonder if there is a way to pass a NativeInterface object instance as parametter of the method of another NativeInterface.

I mean when I create two objects that extends NativeInterface like this:

NativeObjectType1 o1 = (NativeObjectType1 ) NativeLookup.create(NativeObjectType1 .class);

NativeObjectType1 o2 = (NativeObjectType1 ) NativeLookup.create(NativeObjectType1 .class);

CN1 is necessarilly keeping a mapping between this CN1 java o1 object and the native one so that if I call o1.somemethod(), it would make a native call to the somemethod() method of the native o1 object (and not of the o2 one).

Now, if I have onother NativeInterface object of a the type NativeInterfacType2:

NativeObjectType2 o3 = (NativeObjectType2) NativeLookup.create(NativeObjectType2 .class);

I would like to be able to pass to some method of this object o3 an instance of a NativeObjectType1 object (so to do something like o3.amethod(o1)) as this method would depends on multiple parametters stored nativelly in NativeObjectType1 objects.

It should be feasible in theory as CN1 keep a mapping between a CN1 java object and its matching native object (to bind the calls of a NativeInterface) so if I pass a CN1 object that extends NativeInterface, it should be able to use this mapping to retrieve the matching native object and pass the pointer to it when transforming the java call into a native one...

But I don't know if this has been implemented

[Shai Almog]

It hasn't been implemented, it would have been nice but it's a lot of work since every change in this part of the code needs to be done for every port. It also needs to be replicated in the code generation and the backend generation logic. There are multiple points of failure and pain so we try to avoid changing those things. The only thing I really miss in native interfaces is a proper ByteBuffer to provide high performance shared memory although it isn't crucial as we don't have the JNI overhead and can use callbacks to map data directly.

In other words, it's technically possible but such a pain to implement we probably won't do it.

[Thomas]

OK Thanks.

As for the ByteBuffer I completely agree yes ;) (It is the basis of the binary messages solution chosen by Flutter to communicate between flutter dart code and native one and it is SO convenient and powerfull to work with that I also regret not having such an easy solution in CN1 too)

[Steve Hannah]

If you can provide more information about your use case, I may be able to suggest a way to achieve it.  While you can't just pass a NativeInterface instance as a NativeInterface parameters, there are a few crafty techniques that you can use to pass "native" objects back and forth.  E.g., on iOS, "native" objects are just pointers, which can be cast to and from longs and passed back and forth.  On java-native platforms (e.g. simulator and Android), I generally use a static lookup table, then pass ids of this lookup table back and forth.

Steve

--
You received this message because you are subscribed to the Google Groups "CodenameOne Discussions" group.
To unsubscribe from this group and stop receiving emails from it, send an email to codenameone-discu...@googlegroups.com.
Visit this group at https://groups.google.com/group/codenameone-discussions.
To view this discussion on the web visit https://groups.google.com/d/msgid/codenameone-discussions/04ecf3a6-ad0d-4ebe-b14b-07b187ead623%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

Steve Hannah

Software Developer

Codename One

http://www.codenameone.com

[Thomas]

Thanks Steeve. I already use a lookup static map as a solution to my problem. This is just that the possibility to pass a NativeInterface instance as a NativeInterface parameter (and forth, as a callback result) would have been cleaner as I wouldn't have to maintain this static map in parallel and have to worry about cleaning it when one of its elements is no longer used in my code (so that the GC can collect it)

On Friday, October 19, 2018 at 2:27:34 PM UTC+2, Steve Hannah wrote:

If you can provide more information about your use case, I may be able to suggest a way to achieve it.  While you can't just pass a NativeInterface instance as a NativeInterface parameters, there are a few crafty techniques that you can use to pass "native" objects back and forth.  E.g., on iOS, "native" objects are just pointers, which can be cast to and from longs and passed back and forth.  On java-native platforms (e.g. simulator and Android), I generally use a static lookup table, then pass ids of this lookup table back and forth.

Steve

On Thu, Oct 18, 2018 at 10:20 PM Thomas <tomber...@gmail.com> wrote:

OK Thanks.

As for the ByteBuffer I completely agree yes ;) (It is the basis of the binary messages solution chosen by Flutter to communicate between flutter dart code and native one and it is SO convenient and powerfull to work with that I also regret not having such an easy solution in CN1 too)

On Friday, October 19, 2018 at 7:07:52 AM UTC+2, Shai Almog wrote:

It hasn't been implemented, it would have been nice but it's a lot of work since every change in this part of the code needs to be done for every port. It also needs to be replicated in the code generation and the backend generation logic. There are multiple points of failure and pain so we try to avoid changing those things. The only thing I really miss in native interfaces is a proper ByteBuffer to provide high performance shared memory although it isn't crucial as we don't have the JNI overhead and can use callbacks to map data directly.

In other words, it's technically possible but such a pain to implement we probably won't do it.

--
You received this message because you are subscribed to the Google Groups "CodenameOne Discussions" group.

To unsubscribe from this group and stop receiving emails from it, send an email to codenameone-discussions+unsub...@googlegroups.com.

Visit this group at https://groups.google.com/group/codenameone-discussions.
To view this discussion on the web visit https://groups.google.com/d/msgid/codenameone-discussions/04ecf3a6-ad0d-4ebe-b14b-07b187ead623%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.