android externals

[monte]

Ah, it isn't creating an empty file, the code that calls lcextExtractExternal doesn't check if the external was actually extracted.... Perhaps lcextExtractExternal should be a function returning a boolean success indicator? Then only add to the rExternals array if successful.

[monte]

FYI I'm debugging an issue with java__from_string not handling empty strings... you get an out of memory error.

[LCMark]

@monte: I've integrated your fix for the standalone building problem... I think it was because the engine was trying to load the alien external (even though it wouldn't have had a file, it would have had an entry in the 'externals' list built into the standalone) and failing to, so dieing. This fix will be in the next build of 6.1.1 (rc-5).

Have you managed to sort the empty string problem?

[monte]

I think so it's part of my open pull request for the default value stuff:
https://github.com/montegoulding/liveco ... aee00a52cc

I was scratching my head why this resolved anything but I just noticed it probably should have been if (!java_from__string rather than if (java_from__string... I think this code is a bit clearer anyway. It may have just been on any default value it just happened I noticed it on empty ones. However I'm not really sure why the empty strings don't still throw the error because it looks like we are doing malloc(0) for them which should be null and therefore get the error... So I'll test again...

[LCMark]

@monte: Although it used to be inconsistent across (malloc) implementations, these days malloc(0) will return you a non-nil pointer so that aspect of things should be fine.

[monte]

Good to know, thanks

[SamanthaLC]

One of the scenarios that is not discussed in this thread is the ability to include external (not "LiveCode External") Java code which is invoked for particular intents and packaged along with the LiveCode application. This would be in addition to any traditional LiveCode Externals which are accessed via the engine and used in stacks as normal.

For example, if there is a third party library which needs to handle android.intent.action.BOOT_COMPLETED intent, and call into that Java code, not a LiveCode stack, the following support would need to be added into the generated Stand-alone Android package (.apk), both the Manifest:

Code: Select all

       <service android:name=".JavaIntentSvcHook"
                 android:label="@string/app_name"
                 android:exported="false">
            <intent-filter>
                <action android:name="android.intent.action.BOOT_COMPLETED" />

                <category android:name="android.intent.category.DEFAULT" />
            </intent-filter>
        </service>

And the included .jar or .class files provided the JavaIntentSvcHook class would need to be linked in. This would be similar to using LOCAL_SHARED_LIBRARIES in an Android NDK project to include third party components.

I want to be clear that this is to support calling third party Java code via Intents registered in the application Manifest, rather than calling into specific stacks or code in LiveCode.

Would it be possible to bootstrap such a third party library into a stand-alone build using any undocumented methods?

[monte]

Well it's all undocumented so welcome to the party

I use a dynamically registered broadcast receiver in one of my mergAndroid experiments so I don't see why you couldn't do the same with a manifest registered one. Until we get an api for a general notification to the default card though you will need to have a way to get an object reference to post a message to.

So I would say you would need an external to glue lc to the third party library. Handle the broadcast and call the library etc. You may even want two... one a generic broadcast receiver which posts back to lc and one to call the library which you call from lc.

Perhaps I should see if I can knock up the generic broadcast receiver as a functional equivalent to my iOS external mergNotify... services should be the same. However, I'm for a service which is meant to be a background process it could get messy. Perhaps @runrevmark could chime in on that?

[SamanthaLC]

Thank you for the quick reply monte!

Is the source code for your mergAndroid experiment using a broadcast receiver? I'd love to see an example to play with.

Using an external to glue LiveCode around the third party library might work, but it seems less elegant and more painful. I would really like to be able to just call into the third party library as handled by a registered intent in the Manifest, as this is the way the third party library was intended to be utilized.

If you know of other resources that might be helpful regarding broadcast receivers or service intents registered in the Manifest I would be grateful to know of them.

Thanks again!

[monte]

Is the source code for your mergAndroid experiment using a broadcast receiver? I'd love to see an example to play with.

No, the only public source of an android external is revtestexternal in the externals v5 branch of @runrevmark's fork of lc.

Using an external to glue LiveCode around the third party library might work, but it seems less elegant and more painful. I would really like to be able to just call into the third party library as handled by a registered intent in the Manifest, as this is the way the third party library was intended to be utilized.

Well if you don't need any callbacks to your app at all and the library comes with implementations of broadcast receivers then you probably only need to put it in the libs folder (the class loader should just load it from there) and use the full class path in the manifest.

[SteveTX]

I would be willing to offer a bounty for the development proposed by SamanthaLC. We need access to android's JNI.

[monte]

@SteveTX that's what this whole thread is all about. I think @SamanthaLC has a very specific use case that perhaps makes an external unnecessary though.

[SteveTX]

Monte: While It is different than a normal LC external, in the mobile realm that isn't games we rely on presence, background services, automated test intrumentation, and other resources that make it necessary. The ability to apply 3rd party code to specific intents, which is the purpose of the manifest, is absolutely essential and critical to a development environment for mobile. I need this code two months ago.

[monte]

@SteveTX what code? What you're talking about is having third party libraries handle intents defined in the manifest. So there's no code other than the third party library.

[SteveTX]

Exactly. LiveCode is the GUI, not the app.