LiveCode Forums

I'd like to build mergJSON for iOS but there's no array support on iOS so I'd need to work out how to get the desktop one to work on iOS... I *think* it's just a matter of adding a static library as a target in Xcode then hacking it to comply with whatever lclink.sh needs... but it's just an idea at the moment so I haven't looked into it... If it worked would it work for android too?... Jansson and therefore mergJSON has no dependencies.. it's just C...

There's no need to really 'hack' anything here - the rev externals on iOS (and Android) both use the old externals mechanism. Obviously the old mechanism doesn't have support for performing system-related stuff on iOS, but for plain C externals and such there should be no problem. In terms of longevity, it shouldn't be too much of a problem as a wrapper could most likely be written to support most of the existing old and new style externals API when we have the new Extensions API.

Edit: Meant to say - just take a look at the revxml-mobile xcodeproj... Should be easy enough to copy / modify as appropriate.

Thanks!

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

<cough>...Android?...<cough>

Ah, yes - Android externals. *oops*
I've been pondering that since the conference, but got a bit distracted by the filter enhancements.
Give me a few more days to write up a proposal...

Jan Schenkel.

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.

Ah, but there's the rub: people want to tap straight into Java externals, not build C externals as a gateway to Java functions.
And Java developers rarely like the idea of writing their own JNI calls. A few annotations should be enough and the system has to figure out the rest.
While I do have a pretty good idea of how I'd do it, I want to make sure it's well thought out before I share it here.

Jan Schenkel.

Also, the current Android.mk mechanism would give access to the current externals interface but nothing more.
What I'd really like in the way of arrays is support for multidimensional arrays.

If 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...

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

BTW lcidl externals work fairly well on OS X apart from LCObjectPost which hangs the engine... needs a heap of work for Windows though...

needs a heap of work for Windows though...

LOL. What doesn't?

There is no requirement for static linking on Android, and all .dex files in the .apk package are automatically put on the classpath.
All you need is a very thin layer of JNI and reflection to be added to the engine. Even simpler if we could move to Android 2.3 as minimum.
And I too wish we had a single consistent Externals API across platforms.
But I guess that's what the Extensions part of the Kickstarter project is about?

Jan Schenkel.

But I guess that's what the Extensions part of the Kickstarter project is about?

I think that gets us a third

Hmm... Are you thinking we would instantiate and use java objects directly in LiveCode after getting the engine to do the reflection on the classes to work out the methods and properties?

The idea is that you wouldn't have to instantiate the object yourself; the engine automatically finds all implementations of the 'com.runrev.livecode.external.ExternalLibrary' interface at startup, instantiates them and makes appropriately annotated methods available as externalCommands/externalFunctions.
Whenever you call such an externalCommand/externalFunction, the engine knows how to tap into the Java code via JNI/reflection.

Here's what such an external class could look like: And your LiveCode script could call it just as if it was an every-day external: If LiveCode really needs some sort of .lcidl mechanism to make it work, an annotation processor could be provided which churns out the file.
But I'll go into more detail next week, once I've collected all my thoughts into a coherent proposal (including how to handle callbacks).

Cheers,

Jan Schenkel.

That 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...

I haven't taken that part of the code apart yet, but I do know how easy it is to 'mangle' JNI memory management. If you're not careful, the C-side may prevent an object from getting garbage collected, or the C-side may think it has a hold of an object method but the JVM has moved it behind its back. Much safer to have a single bridge to exchange data than to have multiple bridges over the gap. At least that's been my experience.

Jan Schenkel.