[Haskell-cafe] Mobile app development?

[Kristopher Micinski]

For reference, the only components provided by the Android platform
(listed on the Android website, and what I found digging through the
provided NDK) are:

libc (C library) headers
libm (math library) headers
JNI interface headers
libz (Zlib compression) headers
liblog (Android logging) header
OpenGL ES 1.1 and OpenGL ES 2.0 (3D graphics libraries) headers
libjnigraphics (Pixel buffer access) header (for Android 2.2 and above).
A Minimal set of headers for C++ support
OpenSL ES native audio libraries
Android native application APIS

Having these things is a far cry from being able to use any of the
typical Android facilities from native code: you can't even implement
GUI normally.

The one project I've seen which attempts to generate stubs for easy
use by native code is:
http://code.google.com/p/cle-for-android/

I'm not sure of the current status, but the last I checked it was
still a bit premature.

Kris

On Wed, Jan 23, 2013 at 1:48 PM, Kristopher Micinski
<krismicinski at gmail.com> wrote:
> In what way are they exposed for use?  I certainly haven't seen any
> API which lets you touch any of the standard GUI utilities without
> writing JNI wrappers that communicate to the Java based UI elements.
>
> As far as I know there is no way to use the actual Android API: you
> have to write a wrapper through the JNI to use the Java version.
>
> Can you point to a native library which allows you to hook in to the
> Android SDK?  I'd be very interested in seeing it.
>
> Kris
>
>
> On Wed, Jan 23, 2013 at 10:54 AM, Brandon Allbery <allbery.b at gmail.com> wrote:
>> On Tue, Jan 22, 2013 at 8:37 PM, Kristopher Micinski
>> <krismicinski at gmail.com> wrote:
>>>
>>> By the way, the Android APIs aren't really meant to be used by native
>>> code: the only real use for native code in Android is GPU code and
>>> math code (think games and DSP-type programs).
>>
>>
>> They may not be "meant" to be in some sense, but from Android 2.3 on they
>> are exposed for such use --- and I believe language porting like this is one
>> of the intended uses.
>>
>>
>> --
>> brandon s allbery kf8nh                               sine nomine associates
>> allbery.b at gmail.com                                  ballbery at sinenomine.net
>> unix, openafs, kerberos, infrastructure, xmonad        http://sinenomine.net