LiveCode Forums.

I thought you'd say that. What about a class between Activity and LiveCodeActivity?

@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).

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

@runrevmark Ok. com.runrev.android.ExternalInterface? And you want to implement it on Engine? I can do this if you want.

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

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

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.

I shall see what I can do...

yes it does resolve the quirky syntax on a few counts (java prefix, c parameters)

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.

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?

I think declaring interface methods abstract and possibly even public is redundant

Apparantly so...

We are declaring ActivityResultCallback twice in LC and in EngineAPI

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.

Should com.runrev.android.EngineAPI be pumped out next to LC.java?

No - for the reasons given above.

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.

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?

Never mind.. had to add the engine jar

Whoop... mergZXingGetBarcode!!!!

monte wrote:Whoop... mergZXingGetBarcode!!!!

hope the other extnl's are not too far behind

monte wrote:Whoop... mergZXingGetBarcode!!!!

WOW!

hope the other extnl's are not too far behind

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.

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.

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.

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 onward

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.

That's a neat idea.

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.