hacking desktop externals for mobile
Moderators: FourthWorld, heatherlaine, Klaus, kevinmiller, LCMark
hacking desktop externals for mobile
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...
LiveCode User Group on Facebook : http://FaceBook.com/groups/LiveCodeUsers/
Re: hacking desktop externals for mobile
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.
Edit: Meant to say - just take a look at the revxml-mobile xcodeproj... Should be easy enough to copy / modify as appropriate.
Re: hacking desktop externals for mobile
Thanks!
Your message contains 7 characters. The minimum number of characters you need to enter is 10.
Your message contains 7 characters. The minimum number of characters you need to enter is 10.
LiveCode User Group on Facebook : http://FaceBook.com/groups/LiveCodeUsers/
-
- VIP Livecode Opensource Backer
- Posts: 3581
- Joined: Mon Jan 22, 2007 7:36 am
- Location: Berkeley, CA, US
- Contact:
Re: hacking desktop externals for mobile
<cough>...Android?...<cough>
PowerDebug http://powerdebug.ahsoftware.net
PowerTools http://www.ahsoftware.net/PowerTools/PowerTools.irev
PowerTools http://www.ahsoftware.net/PowerTools/PowerTools.irev
-
- VIP Livecode Opensource Backer
- Posts: 977
- Joined: Sat Apr 08, 2006 7:47 am
- Location: Aalst, Belgium
- Contact:
Re: hacking desktop externals for mobile
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.
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.
Quartam Reports & PDF Library for LiveCode
www.quartam.com
www.quartam.com
Re: hacking desktop externals for mobile
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.
LiveCode User Group on Facebook : http://FaceBook.com/groups/LiveCodeUsers/
-
- VIP Livecode Opensource Backer
- Posts: 977
- Joined: Sat Apr 08, 2006 7:47 am
- Location: Aalst, Belgium
- Contact:
Re: hacking desktop externals for mobile
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.
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.
Quartam Reports & PDF Library for LiveCode
www.quartam.com
www.quartam.com
-
- VIP Livecode Opensource Backer
- Posts: 3581
- Joined: Mon Jan 22, 2007 7:36 am
- Location: Berkeley, CA, US
- Contact:
Re: hacking desktop externals for mobile
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.
What I'd really like in the way of arrays is support for multidimensional arrays.
PowerDebug http://powerdebug.ahsoftware.net
PowerTools http://www.ahsoftware.net/PowerTools/PowerTools.irev
PowerTools http://www.ahsoftware.net/PowerTools/PowerTools.irev
Re: hacking desktop externals for mobile
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...
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...
LiveCode User Group on Facebook : http://FaceBook.com/groups/LiveCodeUsers/
-
- VIP Livecode Opensource Backer
- Posts: 3581
- Joined: Mon Jan 22, 2007 7:36 am
- Location: Berkeley, CA, US
- Contact:
Re: hacking desktop externals for mobile
LOL. What doesn't?needs a heap of work for Windows though...
PowerDebug http://powerdebug.ahsoftware.net
PowerTools http://www.ahsoftware.net/PowerTools/PowerTools.irev
PowerTools http://www.ahsoftware.net/PowerTools/PowerTools.irev
-
- VIP Livecode Opensource Backer
- Posts: 977
- Joined: Sat Apr 08, 2006 7:47 am
- Location: Aalst, Belgium
- Contact:
Re: hacking desktop externals for mobile
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.
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.
Quartam Reports & PDF Library for LiveCode
www.quartam.com
www.quartam.com
Re: hacking desktop externals for mobile
I think that gets us a thirdBut I guess that's what the Extensions part of the Kickstarter project is about?
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?
LiveCode User Group on Facebook : http://FaceBook.com/groups/LiveCodeUsers/
-
- VIP Livecode Opensource Backer
- Posts: 977
- Joined: Sat Apr 08, 2006 7:47 am
- Location: Aalst, Belgium
- Contact:
Re: hacking desktop externals for mobile
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.
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:
Code: Select all
package com.example.external;
/* imports skipped for brevity */
public class ExampleExternal implements ExternalLibrary {
@ExternalCommand
public void exampleExternalCommand(String[] args) { ... }
@ExternalFunction
public String exampleExternalFunction(String[] args) { ... }
}
Code: Select all
on mouseUp
exampleExternalCommand "foo", "bar"
answer exampleExternalFunction("baz")
end mouseUp
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.
Last edited by Janschenkel on Wed Jun 05, 2013 1:59 pm, edited 1 time in total.
Quartam Reports & PDF Library for LiveCode
www.quartam.com
www.quartam.com
Re: hacking desktop externals for mobile
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...
LiveCode User Group on Facebook : http://FaceBook.com/groups/LiveCodeUsers/
-
- VIP Livecode Opensource Backer
- Posts: 977
- Joined: Sat Apr 08, 2006 7:47 am
- Location: Aalst, Belgium
- Contact:
Re: hacking desktop externals for mobile
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.
Jan Schenkel.
Quartam Reports & PDF Library for LiveCode
www.quartam.com
www.quartam.com