android externals
Moderators: FourthWorld, heatherlaine, Klaus, kevinmiller, LCMark
Re: android externals
I thought you'd say that. What about a class between Activity and LiveCodeActivity?
LiveCode User Group on Facebook : http://FaceBook.com/groups/LiveCodeUsers/
Re: android externals
@monte: Or, how about an interface... We can define an interface which the engine class implements and then in the Support.java file, the LC class can import that and use it to provide the API calls which don't need any interaction with the core (C++) engine. This has the advantage of keeping the clean separation between external (module) and core. i.e. All API calls will still be vectored through the 'LC' class, but it can directly use Java to provide the functionality rather than the rather tortuous root of going through the JNI twice (once into C++, and then once out into Java).
Re: android externals
@runrevmark Ok. com.runrev.android.ExternalInterface? And you want to implement it on Engine? I can do this if you want.
BTW is there any chance that the engine changes for this stuff could be merged into 6.1.1? Then I can start getting a few eternals out.
BTW is there any chance that the engine changes for this stuff could be merged into 6.1.1? Then I can start getting a few eternals out.
LiveCode User Group on Facebook : http://FaceBook.com/groups/LiveCodeUsers/
Re: android externals
Done - at least an initial version. There's now an 'EngineApi' interface which is still 'private' (like the externalsv1 interface is), but exposed to the LC support class where it's used to implement the functionality. There's a 'LC.ActivityRun' method which runs (in a blocking fashion) an activity and then calls a callback when done. (As it 'waits' ActivityRun must be called from the script thread).@runrevmark Ok. com.runrev.android.ExternalInterface? And you want to implement it on Engine? I can do this if you want.
I've also implemented the 'LC.Wait' class and 'LC.RunOnSystemThread' primitives which should hopefully help with a good deal of other Android UI interactions.
There are examples of both things as new buttons in the 'revtestexternal.livecode' stack and in 'revtestexternal'.
I shall see what I can do...BTW is there any chance that the engine changes for this stuff could be merged into 6.1.1? Then I can start getting a few eternals out.
Re: android externals
I started working on the lcidl syntax changes and such to support the general types and extended 'use' parameter the other day as well - needs a bit more work until its suitable to commit, but its getting there.yes it does resolve the quirky syntax on a few counts (java prefix, c parameters)
Re: android externals
Great, this is much better than multiple JNI calls. I'm not sure if there's a use case for starting an activity in a non-blocking way. I guess if we come up with one we can work it out...
A few things I noticed:
- I think declaring interface methods abstract and possibly even public is redundant
- We are declaring ActivityResultCallback twice in LC and in EngineAPI
- Should com.runrev.android.EngineAPI be pumped out next to LC.java?
A few things I noticed:
- I think declaring interface methods abstract and possibly even public is redundant
- We are declaring ActivityResultCallback twice in LC and in EngineAPI
- Should com.runrev.android.EngineAPI be pumped out next to LC.java?
LiveCode User Group on Facebook : http://FaceBook.com/groups/LiveCodeUsers/
Re: android externals
Apparantly so...I think declaring interface methods abstract and possibly even public is redundant
Yes - this is for consistent naming (then everything is LC.) and also because EngineAPI interface is private from the point of view of externals. The public interface that externals have access to in Java is the LC class. Just like the LC API calls in native code, these use the private externalv1 interface to provide functionality that may not be the same and may be augmented.We are declaring ActivityResultCallback twice in LC and in EngineAPI
No - for the reasons given above.Should com.runrev.android.EngineAPI be pumped out next to LC.java?
Eventually, there will be a public interface on both the Java side and native side which is a direct interface on the engine - but we're not at a point that's appropriate to 'fix' that, so the private interface with wrappers is the way things need to be for now.
Re: android externals
OK, I'm trying to play with this but I've getting an error from the standalone builder. I've built the android engine, built and run the IDE all debug mode, built my external, chosen my device then clicking test gets me "could not encode class bundle"... it's fine if I don't include my external. Any ideas?
LiveCode User Group on Facebook : http://FaceBook.com/groups/LiveCodeUsers/
Re: android externals
Never mind.. had to add the engine jar
LiveCode User Group on Facebook : http://FaceBook.com/groups/LiveCodeUsers/
Re: android externals
Whoop... mergZXingGetBarcode!!!!
LiveCode User Group on Facebook : http://FaceBook.com/groups/LiveCodeUsers/
-
- VIP Livecode Opensource Backer
- Posts: 16
- Joined: Fri Dec 31, 2010 8:13 am
Re: android externals
monte wrote:Whoop... mergZXingGetBarcode!!!!
hope the other extnl's are not too far behind
Re: android externals
WOW!monte wrote:Whoop... mergZXingGetBarcode!!!!
Re: android externals
It will take a while to get where I am on iOS on Android. As we work out the SDK I'm implementing some things but most of mergExt will need to wait for people to fund it.hope the other extnl's are not too far behind
LiveCode User Group on Facebook : http://FaceBook.com/groups/LiveCodeUsers/
Re: android externals
Platform specific enum values might be nice...
Here on Android "earth" is 1, on iOS and OS X "mars" is 1 and on all other platforms "world" is 1. Appropriate errors would be thrown if the wrong parameter was sent for the wrong platform.
Code: Select all
enum some-enum
"hello" as 0
"world" as 1
"earth" as 1 on Android
"mars" as 1 on iOS,OS X
LiveCode User Group on Facebook : http://FaceBook.com/groups/LiveCodeUsers/
Re: android externals
I committed the engine-side changes from my externals-api-v5 branch into release-6.1.1 this morning so externals built using stuff from feature-externals_api_v5 in my repo should load and work with 6.1.1-rc-2 and onwardBTW is there any chance that the engine changes for this stuff could be merged into 6.1.1? Then I can start getting a few eternals out.
That's a neat idea.Here on Android "earth" is 1, on iOS and OS X "mars" is 1 and on all other platforms "world" is 1. Appropriate errors would be thrown if the wrong parameter was sent for the wrong platform.
On a related note, I've got a fair bit further with the syntax changes and restructuring needed for we've previously discussed, indeed, I merged the 'syntax_changes' branch into feature-externals_api_v5 the other day and things seems to be working okay. In the process I cleaned up the lcidlc code generation a little - particularly the type-mapping stuff - and also made it so that Java implementations are called directly from the 'variant_' functions, rather than calling a shim.