Almost two years ago I had the process of writing Android apps using native C code generated by the Nim compiler pretty much worked out as per this thread and a simple GitHub repo using those techniques plus other repos that advanced this, but something seems to have changed with newer Nim version(s) so that the generated C code is no longer accepted by the NDK compiler (with even more problems when everything is updated to latest versions of Nim and the NDK.
Thus the question of whether anyone has this working for recent versions?
I'm quite sure that @Yardanico's JNI inteface techniques and code still work as they are just using FFI between regularly generated Nim code and the Java JNI, but the Android NDK takes this one step further in providing its own C/C++ compiler.
I used android and nim version 1.4.8 https://github.com/marcomq/nimview/tree/main/examples/android
But I always have issues with new Nim versions as the Android Studio / Ndk isn't cleaning up all temporary files. Maybe you can just erase all temporary files mentioned in your compile error message.
@Hlaaftana, indeed, that was the major problem, although with that file replaced, there were also some other problems to do with compatibility with the latest Gradle build system (it is now required that activities have export be set to "true", and with a warning to do with compatibility with a future Gradle build system (jstore() will no longer be supported); I also updated required build SDK to the latest Android 31 (S) and NDK versions. I've updated the README.md file to reflect the changes, which are also listed in my response to the issue.
Thank you so much for your help is solving this...
Do let me know if that repo works again...
I does work again, and you are welcome to try it, as it is a minimum way of generating a mostly-native-Nim-code based Android app.
In my list of Android repos, there is also another sample version supporting call backs, and a reasonably major Sieve of Eratosthenes benchmark app that tests the speed of an Android device, but these latter two will need to be updated just as this one has been - you can see the details of updates required in my replay to @Hlaaftana and in my comments in reply to the issue in the repo.
I will be making the changes to the other repos once I hear back that the changes to this repo work for others...
@cmc,
Thanks for your support of my simple demonstration repo with your PR to add instructions for use with the command line. I'm glad it's still of use, and have merged your PR.
Thanks for letting me know that it still works with recent software versions; I haven't kept it up to date as my interests are now focused away from imperative languages such as Nim and more towards functional languages based on ML languages (although both originally were based on Algol 60 and the Great Split occurred just after that language). The latest idea that I am trying to pursue (which is kind of in line with @Araq's search for the ultimate Graphical User Interface (GUI) for Nim) is that WebView should be the target for all GUI's, which would then let a code base support all of the processors that can run on any of the major platforms as in Windows (using the Edge WebView2), macOS (using the built-in Safari Webkit), Linux (using WebkitGTK), and with both Android and iOS having built-in support, as well as use with actual web pages using either JavaScript or WebAssembly. This is similar to what Tauri attempts to do but avoids having to go through a Rust API to get there, rather just tying a thin wrapper API directly to the appropriate WebKit for the platform being supported with the API written to be called directly from the C/C++ that languages such as Nim generated (and the functional language that I want will also generate, including Nim's Arc "smart" reference counted memory management.
This project is triggered in that it seems that each "native" platform GUI requires its own version of an XML type of tagged Meta Language GUI layout description language, where there is already a proven one of these in HTML5 that seems perfectly adequate; the API will be based on a "diffing" VirtualDOM approach to minimize the traffic between the application layer and the rendering layer which is especially important when the application layer is WebAssembly. The project could be compared to Google's Flutter where the Dart language is used at the application level which also supports the same desired platforms, but it also has its own custom layout language rather than using HTML and it expressly designed to support the Dart language.
Since the project is basically a C to WebKit interface (likely using emscripten to handle the JavaScript and WebAssembly generation for web page platforms), it should be reasonably easily adapted to use by Nim applications, especially if I ensure that memory management is handled at the application interface level.
For mobile app use, this would generate a native WebKit app for both Android and iOS without the use of the Java Native Interface (JNI) to the Java/Kotlin code wrapper as in my simple demo repo in order to bypass the would UI layout language requirements...
That's quite cool Gordon!!!
I believe I have become quite taken to the 'game development toolchain' approach. It occurred to me that both- games and web apps- are the kind of thing that aren't appreciated very much in the closed world of mobile apps, but no one can afford to do without. Both are great!