How feasible would it be to use this as an Android backend? about idris-java HOT 4 OPEN

You need to port over the runtime system, which should be easy or nothing to do at all. Then you need to hack to make the buildsystem work. I tried it a while ago and got appalled by the Ant voodoo Android is using. Further you need some way to get feedback from the app, since console projects are not quite what Android was made for.

from idris-java.

Thanks for the direction @JanBessai. I have been trying to hack on this to make a an android backend in my spare time. One of the things I can't seem to figure out is how to handle the code generation since android doesn't have a main function, it only has a main Activity class with callbacks to handle the app's life cycle.

Is android dissimilar enough to warrant it's own backend?

If it should be apart of this backend does anyone have an idea/opinion about how to tell it to generate a main Activity class as opposed to a main function (like target android instead of just java)?

Does anyone have an idea about how the code generation should handle the life cycle callbacks like onCreate, onResume, onStop, etc?

from idris-java.

While I've been working on the Java backend for Idris, I'm not sure that this is the best approach for Android. In particular, there are some advantages to using the Java backend, e.g. when JNI interop is necessary, however, it is not clear that it will be as performant as the C backend and in fact I've been hitting issues with to large methods (4K limit and so on). I think this is down to defunctionlization and other transformations that happen in lowering, done by the Idris compiler, but given the current compilation method is not going to be trivial to solve.

To this end I would think it might make more sense to use the C backend for Idris and run the application as a native Android application. This would avoid a lot of the issues that might come up with Java and possibly you will see better performance and avoids the two large method problems. Of course, this will depend on what you want to do with Idris code on Android and if you are expecting a lot of interop with Java, then this might not be a good design choice, but if not I expect this will actually be a more stable approach.

from idris-java.

Ultimately what I would like to do is implement a generic graphics library a lot like elm's graphics library. Only I want to be able to use the library for multiple backends.

So as an example one would use a data structure in idris that could describe an image with it's attributes and where it should be placed. Then using the FFI you would send that data structure to a "render" function that would be implemented for whatever backend you would like. In C it could use GTK, in javascript it could use html, and with Java it could use android.

I think I could use opengl instead of native android gui elements. However I would like to allow for an ability to use native gui elements if someone wants that. So if I made a library that implemented a list view, I might want the javascript render function to just use a simple <ul> tag, but for the java backend I might be able to choose between an ffi library that renders a list view using opengl, or a native android ListView class. So I want the option of good interop with Java.

I guess I can just focus on other targets like just iOS, and javascript to flush out some of the details and save android for later.

If anyone has any thoughts or ideas about this please let me know.

from idris-java.