Tue Jan 15 10:41:25 CET 2013
On Mon, Jan 14, 2013 at 9:04 PM, Erik Reitsma <erlang@REDACTED> wrote:
> On 01/14/2013 11:37 AM, Joe Armstrong wrote:
>> This is amazing - works like a charm - fantastic.
>> I am glad it not only works on my own devices. :-)
> Quick comment -
>> It would be very nice to make the client and server in
>> fac_example.zip run "out of the box"
>> client.erl is a *must read* file. server.erl does not export main/0 and
>> should be changed to
>> spawn the server - otherwise you don't get control in the shell ...
>> The server was intended to be run on some server, not on the Android
> device. Only the client should run on the device. Of course, the server
> could easily be adapted to run on the same device, or another device, as
> The example was mainly intended for people familiar with Erlang, who want
> to try their Erlang skills on Android. A different example may be required
> for Android programmers who do not yet know Erlang.
> First thoughts/questions:
>> - The download is rather large - I'm sure this could be made a *lot
> Definitely. As I wrote, I put in as much as I could, mainly to show that
> all those libraries could run on the device. I intend to make a minimal
> installation too. The current download includes almost everything from OTP,
> including things like epmd (which also works, but you will need to start
> Erlang from a shell, probably with root permissions). I think I can
> probably remove the corba applications, the megaco application, ASN.1 and
> many others. I will see if I can make it possible to make your own
> selection of OTP applications, and perhaps even allow other repositories
> with non-OTP-applications.
> - Need Erlang APIs to the camera, GPS, .... etc.
> For now the easiest way to do this is write wrappers around the SL4A APIs.
> Have you looked at those and found them lacking? You can find all available
> functions here: http://code.google.com/p/**android-scripting/wiki/**
> ApiReference<http://code.google.com/p/android-scripting/wiki/ApiReference>I have actually only tried a view of them myself.
> All functionality from SL4A is available through the module android. I
> have implemented this using a dirty trick: I have modified
> error_handler.erl such that for an undefined function android:F(Args), the
> function android:rpc([Args]) will be called. So I only implemented
> android:rpc/1, which will be called for any other function android:F/N.
> Dirty, but if there is a new function in SL4A, it will be supported
> automagically. This is similar to the implementation for Python4Android.
Golly - I read the code - you modified error_handler.erl !!!!
So what happens is ...
I call android:fooBar(Args) - fooBar is not defined in android.erl
so it's caught in error_handler and then android:rpc(fooBar, [...]) is
and this ends up as a Json call to a socket -
(aside) I'm not sure I'm totally happy with modifying the error_handler
what's wrong with calling android:rpc(Func, Args) in your code and not
changing the error handler?
It appears that SL4A is interfaced via a socket carrying JSON encode
terms - is that correct?
I Googled a bit to see if I could find where the protocol is defined -
but found nothing.
Where, for example, is the handshake that you perform in android:init
If I want to call an andoid function I need to create a JSON argument
list from erlang -
what are the calling conventions?
This is all very interesting stuff - I'd really like some documentation
though, how the
heck did you figure out how the interface works? - did you have to sniff
the socket? - is there an architectural description somewhere?
> - The client.erl example shows I can make an application *without*
>> it would be very nice top abstract the details of the layout()
>> so as not to see the XML :-)
>> Yes. :-) SL4A does not provide an API to dynamically create gui
> elements, so this is a limitation with the current approach. It would be
> possible to write Erlang code that transforms something erlangy into the
> required XML. I would have to look at how generic that could be made,
> because I may be too lazy to specifically implement all possibilities for
> the layout XML. I think it would be possible to make some simple
> XML-generation from lists of tuples records. I will give it some thought.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the erlang-questions