hacking desktop externals for mobile

[monte]

Well... I'm not experienced with JNI so I can't comment on that but I am definitely looking forward to Java externals

[LCMark]

Actually if you look at the Android.mk files its the same... So if we just want C it's not complicated... Not sure if the standalone builder is setup for that though.

Yup - for pure C externals not requiring access to Java, you can just mutatis-mutandis the revxml Android.mk. The standalone builder is setup for custom externals (although I'm not sure how well tested it is!). The structure of the lcext zips are designed so iOS and Android components can sit side-by-side - just put the resulting .so into the lcext zip at Android/External-armeabi. (The code that extracts stuff is addExternalFromFile in stack revsaveasandroidstandalone).

What I'd really like in the way of arrays is support for multidimensional arrays.

The array implementation is complete I think (although probably not very well tested) - the reason it has been pending for so long is that I wanted to ensure that the API was implementable via the new abstract types in the refactor branch (the calls exported as the 'externalv1' interface are *not* compatible - hence the wrappers that get compiled into externals, as long as we can keep the LC APIs compatible with how the engine types are going to work, when we get the new Extensions API current externals just need to be recompiled against a shim). I've added this to my list to finally double-check - if the API checks out then there's no reason I can't see for it not to be usable.

sounds good... Is it more work though than having the lcidl parser generate the JNI calls for us (which I think was the plan based on the code I've seen)... my understanding is lcidl will be upgraded to open language in due course...

The current (pending) Android external implementation was essentially intended as a way to implement native code externals that could call Java - so lcidlc can generate wrappers in both directions - so native code can easily call Java, and that Java can call native code. I've also added this to my list to review - at least I can write up what work has been done so any interested parties can take it and run with it as a baseline if they want.

[LCMark]

f you look at the lcidl stuff you will see that it generates the JNI calls for android already. I think it's all fairly close...

Indeed, it turns out it is very close, and Jan's thoughts made me realize it wasn't too far from 'pure Java' externals on Android too

Basically, I've changed things so that in the lcidl file you can do things like:

Code: Select all

java command rreMicrophoneStartRecording
             in filename as c-string
             return recording-status-enum

This will cause lcidlc to assume you want to implement that external method in Java rather than having to write any native code. Therefore, it generates a native code stub (rreMicrophoneStartRecording) and maps to a java method 'int rreMicrophoneStartRecording(String filename)' (which has to be declared as a static method in a class 'rremicrophone' in a suitable package).

I've also started work on Java wrappers around all the LC API calls. So, essentially, you'll be able to write externals purely in Java without having to write any native code (since lcidlc will generate that for you).

Still a work in progress, but you can see what's going on at https://github.com/runrevmark/livecode/ ... als_api_v5.

The array support in lcidl externals is ifdefed out but it is multi-dimensional I think.

Yup - multi-dimensional and are (I think) now suitably complete and forward-compatible.

I've also added mappings for LiveCode arrays to/from NSArray and NSDictionary types.

[mwieder]

!!!

Your message contains 3 characters. The minimum number of characters you need to enter is 10.

Oh, all right.
!!!!!!!!!!

[LCMark]

!!!

You okay there @mwieder?

[mwieder]

Got excited, but I guess I didn't get excited enough for the forum validator...

[LCMark]

Got excited, but I guess I didn't get excited enough for the forum validator...

Well, thank @Janschenkel for triggering an 'ah ha!' moment the other day.

The Java bindings I've been working on will be somewhat clunky I fear - I'm hoping that those-that-(are-forced-to)-program-in-Java might be able to weigh in there to improve that a bit. Java has never been my forte (I'd say I can get by in it, no more) and I don't think I've ever managed to make the cognitive leap of 'thinking the way the language wants you to' with it.

However, the beauty of the lcidlc approach is that nothing is set in stone - the externals carry the logic to talk to the (quite thin) engine interface. It's easy enough to add better interfaces to functionality in the future, whilst still having externals written against current iterations work as they did before.

[monte]

Awesome