Hi guys, I'd like to ask if there is interest in having a "Nim-native" access to all Android features and hardware, through both creating many bindings to the native api, and via jnim as a bridge, and consolidating it all in one Nim style API.
I can have one or two days a week to work on this, but could be more - how much i can expend depends on accumulated funds.
The Vision:
In essence the initiative would expand Nim's reach, allow us to develop mobile applications without leaving the language we love.
By bringing Android support to Nim, we'd be advancing the language into the modern mobile platform.
Mobile development, and Embedded are two areas that I see quite lacking in Nim support, and bringing such a beautiful language, with our API of choice, macros, templates etc can all create a joy of experience.
I envision the progress milestones as "unlocking" a feature each time in a separate module.
But to make it a success, I'm trying to gauge how many people are willing to join and donate to make it happen.
The Android API is also quite huge, so the priorities should be chosen by you or the ones who participate.
I see this infrastructure development as libraries that can open a whole platform, and having someone to do it accelerates or enables everyone.
So, tell me your honest thoughts
Thanks, Kobi
PS: the initial scope is likely to be similar to plyer a python lib related to kivy the mobile gui kit.
You are the original pioneer! ;-)
I saw your bindings, very nice, i was suggesting a more comprehensive approach.
But I guess there's no interest.
Building a class2nim i think it's not so hard.
If that tool was made, how do you envision the process or using it to accomplish whatever goal you had in mind?
adding JVM backend to Nim seems to be a comparable effort...
No, not at all. Adding a JVM backend to Nim is a terrible idea:
It's just a stupid idea.
I think this would be absolutely amazing.
A great place to start might be the SDL2 Android stub Java classes. I think they have most the features you mentioned. They expose all the Java API stuff as a C library via "Native Calls".
I think it would be quite possible to take the unchanged SDL java classes and extract the Nim wrapper for those calls to achieve your goal faster.
I have a convenient self-contained cmake setup for Nim and SDL2 on Android <https://github.com/capocasa/snab>. This is all based on @yglukhov and @treeform stuff that I adapted for the standard android command line build system.
It might be a good idea to write a class2nim translator that will introspect java class files and output jnim definitions. I wanted to do it for my android bindings but of course, never got around.
So, this tool is now a reality. I used JavaParser (used from the java side) to select all the public functions in the classes (and ran it on the android folder of the sdk source), the output is in json. Then a nim program creates jnim declarations (jclass imports) from the json files.
@yglukhov If it's not too much trouble, i am not entirely sure how to use jnim:
For now, the converter outputs just jclass and the types.
for example:
jclass android.content.Context* of JVMObject:
proc getAssets*(): AssetManagerHowever in your code, I see other keywords:
jclassDef, jclassImpl, jcast, jexport ... are there more?
Also, if a class is empty, or we don't need its fields,
can we just do jclass SomeClass*: ` -- do we need a `discard or sth on the next line?
Thanks a lot, kobi
PS: as you see for now I am going forth with it, but no obligations and no promises.
Also, once that's out of the way, i'll showcase the planned api (according to my research so far) and would love feedback because I am actually new to Android development, so any knowledge and expertise is helpful
So, this tool is now a reality.
That's some awesome news! Thanks for doing that!
jclassDef, jclassImpl, jcast, jexport ... are there more?
In manually-crafted bindings most of the time you can get away with just jclass definitions. jclassDef and jclassImpl should be used when you want to split definition and method decls, e.g. in case of circular dependencies. For an automated tool it could be simpler to always produce tons of jclassDefs followed by jclassImpls once all of the related classes are declared.
jcast is really just a cast between JObjects, with additional runtime check that this cast can be made. This should not be a concern for your tool.
jexport is a separate beast used to implement and/or subclass java classes in nim. It results in generating a .java file during nim compilation, and this file has to be used in subsequent build tools, to be included in java compilation somehow. Likewise, I don't think your tool has to be concerned about it.
To summarize, by talking about jnim definitions previously I was talking mainly about jclass definitions, with optional fallback to jclassDef/jsclassImpl in case of circular dependencies. If your tool doesn't analyze for circular dependencies, it may be easier for it to always go with jclassDef/jclassImpl. Hope that helps!