The answer is: Yes. Gluon provides the ability to craft cross platform/cross device ; single code base applications/apps based on Java. (akin to Xamarin; but embraces linux as a target (in addition to Android/ios)… Uses Oracle Graalvm to compile java (and other jvm based languages) to native.
I am still quite the noobie when in comes to Java and Java Android.
BTW - Just took receipt of your Programming Android book; and interestingly I already had Enterprise Android in my personal library already.
That said…still a noobie.
Gluonhq has crafted a development environment based on IntelliJ and/or Netbeans to AOT compile java (and other jvm based languages) to native targets including Android, IOS, Linux (my intended targets); as well as WINxx.
But because of my noobie-ness I dont know how to link/deploy an aar library (in this case couch-base-lite-android-ee) into the development environment and tool chain to facilitate deployment to (android) in this case.
The whole point of the Gluon approach is analogous to Xamarin (platform agnostic UI) bound to native components for deployment.
I have read that one can uncompress the aar and (convert/morph it) to behave as a jar library.
I am unfamiliar with Gluon but it may not provide a simple answer here. Couchbase Lite functionality is mostly written in C/C++ and compiled to a (non-portable) native binary. Somehow, the “portable” code is going to have to figure out which native binary to use and how to load it.
You are right that you can uncompress an aar. It is just a zipped directory structure. I’m not sure that’s going to help, though…
There is another developer, in these forums, attempting something very similar. If you look around this mobile channel, you should be able to find him. You might benefit from his experience.
… and sincerely hope you enjoy the books! They are both a bit dated, at this point. You might want to have a look at the more recent one that I did with Pierre-Olivier Laurence and Amanda Hinchman-Dominguez: Programming Android with Kotlin.
Thanks for that guidance. I did see the new book; just reticent to add another language to the 10+ already in my head (its like bee’s flying around in one’s head?!)
Presumably those native binaries you are referring to are bound at run-time; and the couchbase logic is detecting android h/w architecture to determine which native binary to bind on the fly. Do I have this correct?
Yes… Sort of like that. The strategy that the Android bindings use is substantially different from the strategy that the JVM bindings use. Have a look at the code in CouchbaseLiteInternal.
Actually figuring out which version of the native binary to use is largely something that the OS takes care of. The naming conventions are different, on different OSs (.so, .dll, lib, etc). Android handles the whole thing. For the JVM platform, we have to unpack the native lib to the file system and then figure out which one to use. The algorithm is not very general, because we can only support OS/ABI combinations for which we’ve built a version of LiteCore.
Is there any requirement that the same jar/aar/binary be used on both the Android and the Linux devices?
You could, most definitely, do this, using P2P, with separate applications for each of the platforms. We absolutely support that and many of our clients are doing it, that way: Java bindings for Linux, Android bindings for Android and iOS bindings for iOS.
Although it would be quite difficult to use the same application in all three places (that is why we write the bindings for you!), the code for the three applications could be very similar and, in some places, even shared.
No…there is no requirement that the same jar/aar/binary be on all of the devices. I fully expected to treat cbl-ee as a device specific (native) component/library.
The heavy lift for me (because I am new on the android/ios devices); is to identify a java/android-based reference implementation that demonstrates android/android p2p sync. I regard the published Xamarin example as a distraction, since it does not support deployment to linux.