Thread overview
Developing and running D GUI app on Android
5 days ago
aberba
5 days ago
evilrat
5 days ago
Elronnd
5 days ago
evilrat
3 days ago
H. S. Teoh
2 days ago
aberba
2 days ago
H. S. Teoh
2 days ago
Adam D. Ruppe
5 days ago
I'm looking to explore running a D application on Android based on Adams previous foundation work. However, I'm not familiar with the Android + D integration so I need some help.

Has any of you successfully done that? Could use a sample code or anything I can use to figure out how to start.
5 days ago
On Sunday, 10 January 2021 at 18:58:13 UTC, aberba wrote:
> I'm looking to explore running a D application on Android based on Adams previous foundation work. However, I'm not familiar with the Android + D integration so I need some help.
>
> Has any of you successfully done that? Could use a sample code or anything I can use to figure out how to start.

Android itself is just linux under the hood, however the launcher starts java process that fires up your activity class (main in native languages) from there you just call your native code and that's it.

This means
1) you need to build D shared lib
2) make java wrapper in activity to call your code
3) handle your events as if it's java

I did some work in the past for DlangUI[1], you can probably take the gradle project[2] with build scripts and the Activity class as the starting point, however I have no idea what does arsd libs with gui.

Also note that I did it for existing DlangUI code based on NativeActivity library which is deprecated for years now, and that's why you need proper java wrapper.

[1] https://github.com/buggins/dlangui/tree/master/android
[2] https://github.com/buggins/dlangui/tree/master/examples/android
5 days ago
On Monday, 11 January 2021 at 06:26:41 UTC, evilrat wrote:
> Android itself is just linux under the hood, however the launcher starts java process that fires up your activity class (main in native languages) from there you just call your native code and that's it.

It turns out that you don't strictly need the java wrapper.  See https://github.com/cnlohr/rawdrawandroid
5 days ago
On Monday, 11 January 2021 at 07:38:00 UTC, Elronnd wrote:
> On Monday, 11 January 2021 at 06:26:41 UTC, evilrat wrote:
>> Android itself is just linux under the hood, however the launcher starts java process that fires up your activity class (main in native languages) from there you just call your native code and that's it.
>
> It turns out that you don't strictly need the java wrapper.  See https://github.com/cnlohr/rawdrawandroid

Sure whatever, just good luck handling IME input. It might be possible without any wrappers, though I'm unaware of any sane way to do it. I am not an android developer though.
3 days ago
On Sun, Jan 10, 2021 at 06:58:13PM +0000, aberba via Digitalmars-d-learn wrote:
> I'm looking to explore running a D application on Android based on Adams previous foundation work. However, I'm not familiar with the Android + D integration so I need some help.
> 
> Has any of you successfully done that? Could use a sample code or anything I can use to figure out how to start.

First, you need a way to build an APK, and then transfer that to your Android device for testing.  Building an APK *can* be done manually (well, scripted), but I don't recommend it.  The simplest way is probably to install Android Studio and the Android SDK, and use Gradle to build your project.  Gradle takes care of the finicky details of how to build an APK, and the Android dev tools let you install to Android in debug mode without having to find your own way of transferring APKs.

For compiling D, you'll need LDC configured to cross-compile to Android:

	https://wiki.dlang.org/Build_D_for_Android

Talk to Adam for more details -- he has done some work to remove some of the manual munging described on that page, but I don't remember how much.  For maximum convenience, you probably want to figure out how to integrate your build process with Gradle so that it can be done with a single command.  (I opted not to use Gradle, but an SCons-based system that's actually very fast at cross-compiling D and building APKs. But most people will probably want to use Gradle.)

Most of the hard work is the setup; once you have a working environment writing D for Android is pretty smooth.  Esp. with Adam's jni.d, interacting with Android's Java APIs ought to be a lot easier than ever.

If you have more specific questions I can try to answer them.


T

-- 
If it's green, it's biology, If it stinks, it's chemistry, If it has numbers it's math, If it doesn't work, it's technology.
2 days ago
On Wednesday, 13 January 2021 at 02:02:16 UTC, H. S. Teoh wrote:
> On Sun, Jan 10, 2021 at 06:58:13PM +0000, aberba via Digitalmars-d-learn wrote:
>> [...]
>
> First, you need a way to build an APK, and then transfer that to your Android device for testing.  Building an APK *can* be done manually (well, scripted), but I don't recommend it.  The simplest way is probably to install Android Studio and the Android SDK, and use Gradle to build your project.  Gradle takes care of the finicky details of how to build an APK, and the Android dev tools let you install to Android in debug mode without having to find your own way of transferring APKs.
>
> [...]

So Adam's tool setup is pretty clear (talked to him). What remains is calling Java classes and interacting with the Android's API. I know a little bit of Java but not enough Android. Just the calling conversation part.

Do you have a sample of how that works?
2 days ago
On Wed, Jan 13, 2021 at 07:51:08PM +0000, aberba via Digitalmars-d-learn wrote: [...]
> So Adam's tool setup is pretty clear (talked to him). What remains is calling Java classes and interacting with the Android's API. I know a little bit of Java but not enough Android. Just the calling conversation part.
> 
> Do you have a sample of how that works?

Android's APIs are mostly Java.  So what you'll need to do is to interface with it via JNI.  The basic idea is:

1) To call D from Java, you'd define Java methods as native methods, and
   implement the native methods in D (using the JNI naming convention so
   that the JVM knows how to match them up) to make it accessible to
   Java code. In your Java class you'd have a static {} block that calls
   System.loadLibrary to load your D code into the JVM. If your entire
   class is in D, it may be possible to auto-generate the Java wrapper;
   Adam may be written a script for this, I'm not 100% sure.

2) To call Java from D, you'd use JNI. This involves a lot of
   boilerplate to marshal your arguments and/or convert them to
   Java-compatible types, and unmarshal/convert the results, and so
   lends itself very well to automation using D templates.  Thanks to
   Adam's jni.d, this is generally very painless: you just declare the
   Java class using an equivalent D class, and jni.d uses introspection
   to auto-generate the JNI boilerplate for you, then you can just call
   it as if it were a D object.

My own code predates Adam's jni.d, though, so I have my own templates for taking care of the boilerplate.  If you want examples using jni.d you'd best ask Adam. :-D

If you ever need to look under the hood, though, e.g. for debugging purposes, take a look at the JNI spec and Android's NDK docs.


T

-- 
"I'm not childish; I'm just in touch with the child within!" - RL
2 days ago
On Wednesday, 13 January 2021 at 20:23:22 UTC, H. S. Teoh wrote:
>    Adam may be written a script for this, I'm not 100% sure.

Yeah, my code does it all, though the auto-generation is more about accessing Java from D than vice versa, since implementing the D parts are simple.

See the example at the top here:
http://dpldocs.info/experimental-docs/arsd.jni.html

Just write the @Export things in D with the right signature for the native things in Java and it will just work.

There's code in jni.d to auto-generate stubs but there's really no need since it is so simple; you rarely have all *that* many native things anyway.

>    Adam's jni.d, this is generally very painless: you just declare the
>    Java class using an equivalent D class, and jni.d uses introspection
>    to auto-generate the JNI boilerplate for you, then you can just call
>    it as if it were a D object.

yeah, and it can even read a .jar file to generate the D bindings with necessary @Imports automatically (just remember it compiles slow to bring it all in so i wouldn't do it when you just need a few things.)