On Thursday, 3 October 2019 at 19:33:37 UTC, H. S. Teoh wrote:

[snip]

That sounds exactly like the nightmare I imagined it to be. I looked at Joakim's stuff a few times but realized the solutions for D on Android were still way too tricky and delicate. What he did is a great piece of engineering, but nothing that particularly inspires you to say "Yes, I'll go with D!" I'm glad that there is a bit of movement now.

>
> (And, to dream on, in the future we could potentially have built-in Java support in D, in a similar style that we interface with C/C++ today: declare Java classes/methods using D equivalents, and have the compiler or a library auto-generate the JNI code for it.  Or potentially just ditch JNI and use JNA instead, which is far less boilerplate-y. But as far as Android is concerned, JNA may not be available yet, so for the near future JNI seems to the way to go.)
>
>
> T

That'd actually be great. Atm, interfacing D and Java is awkward. I've done it a few times (once I compiled my D code to a lib and used JavaFX for the UI), but it's certainly nothing you look forward to doing ;)

On Thursday, 3 October 2019 at 20:50:53 UTC, Ola Fosheim Grøstad wrote:

>
> What I find repulsive about the node.js world that use packages at crazy levels of pervasiveness is the security aspect of it.

The node.js world is crazy, in my opinion. Your whole project depends on some "obscure" packages. It's a big gamble and a maintenance hell. In my experience, such projects are for "instant gratification", it makes the client happy ("Wow! Looks good!"), but it quickly turns into a nightmare for those that have to maintain it. I prefer to invest time in a sound foundation and build on that. Some fancy things are easy to achieve with bog standard JS and CSS (transitions, transformations etc.), this has the advantage that you're in control and you don't depend on some obscure packages. A lot of info is here [1].

[1] https://www.w3schools.com/howto/howto_website.asp

On Thursday, 3 October 2019 at 18:52:44 UTC, mipri wrote:
> I emphasized that though as it seems to have not even
> occurred to him that I might've gotten annoyed with you for any
> reason other than "you are still not sugarcoating your views as

It doesn't matter why you get annoyed. If technology arguments quickly move to a personal/emotional level than that is something that turns off people with engineering/academic/comp-sci backgrounds who expect technical discussions to stay technical (often with the agreement to disagree). Basically, if things frequently gets emotional they will most likely not stay around and move elsewhere, like Rust.

On Thursday, 3 October 2019 at 18:27:46 UTC, Adam D. Ruppe wrote:
> On Thursday, 3 October 2019 at 18:15:10 UTC, Chris wrote:
>> How will it work once it's finished?
>
> That's part of what we still need to figure out. What I'm aiming for in the first version is you compile the D code with ldc then work the generated shared object back into your workflow, which won't be modified; you just make the blob then drop it in as if it was a closed-source library.
>
> Second pass is possibly a plugin with android studio, or at least the build system. I'm actually totally new to mobile dev (I personally don't even use smartphone apps!) so lots of learning as I go. I'm pretty thankful for the work the ldc people have already done on this, as well as the prior art Joakim did before he left.
>
> The iOS thing is being led by someone else (idk if he wants to publicly talk about it yet), but he's very much a competent Mac person so I have no doubt he'll make it work well.
>
>> Are there any plans for auto generated bridges, e.g. JNI calling rt_init() or something?
>
> I do want to put the bindings to the NDK into druntime as well in core.sys.android. The D foundation is officially backing this work which makes that more realistic.


Thanks for the effort.

But it must work out of the box. A plugin to the android studio will be best prefer. All the heavy lifting should be done by the plugin.

I would like to just install the plugin and would be fine for it. If I can get this, I might consider donating for it.

On Friday, 4 October 2019 at 09:34:16 UTC, Chris wrote:
> The node.js world is crazy, in my opinion. Your whole project depends on some "obscure" packages. It's a big gamble and a maintenance hell. In my experience, such projects are for

Yes, although I do use Angular, which also pulls in a lot of dependencies, but then I expect Google to do the maintenance. Anyway, there is a big difference between having many dependencies on something that runs on the server (bad idea) and using a framework that runs client-side in the browser "sandbox".

> foundation and build on that. Some fancy things are easy to achieve with bog standard JS and CSS (transitions, transformations etc.), this has the advantage that you're in control and you don't depend on some obscure packages. A lot of

That's true. I believe the "culture" of using libraries for such things come from around ten years ago when browsers had very different feature sets.

The exception is when you implement a UI with a standard look-and-feel. Like Google Material, which has an animated counterpart in Angular.

On Friday, 4 October 2019 at 11:54:33 UTC, Ola Fosheim Grøstad wrote:
>
> That's true. I believe the "culture" of using libraries for such things come from around ten years ago when browsers had very different feature sets.

That's definitely one of the reasons. I remember those days. But even MS finally gave in (IE just faded out, devs and users didn't care anymore), nowadays you can use JS and CSS and be confident that it will work (with a few minor exceptions like getting the selected <option> of a <select> element).

Another reason is that young people are used to frameworks and packages and often wonder why I didn't just download some fancy packages. But I wonder why I would do that if I can do it with @keyframes and JS and 10 lines of code.

Sure, web companies like Google and Facebook offer out of the box solutions, because they want devs to create apps and websites as fast as possible, and companies / startups are under pressure to impress clients and investors. Often it's disposable stuff like an app for the Soccer World Cup and the like. So there is demand and I'm not against it, but one has to decide whether or not it's good for your own project(s). Only because it's available and used all over the world doesn't mean it's the right thing for your project(s). It's like fast food. Sometimes it's a good solution, and it's good that we have it, but should you depend on it?

On Friday, 4 October 2019 at 12:33:25 UTC, Chris wrote:
> On Friday, 4 October 2019 at 11:54:33 UTC, Ola Fosheim Grøstad wrote:
>>
>> That's true. I believe the "culture" of using libraries for such things come from around ten years ago when browsers had very different feature sets.
>
> That's definitely one of the reasons. I remember those days. But even MS finally gave in (IE just faded out, devs and users didn't care anymore), nowadays you can use JS and CSS and be confident that it will work (with a few minor exceptions like

Right, and the JS APIs are much better too.  I sometimes wonder why jquery is still around? Established habits don't change easily...

> like. So there is demand and I'm not against it, but one has to decide whether or not it's good for your own project(s).

Yeah, those frameworks are generally not good for mobil devices, but can be very good for admin-desktop-user-interfaces and the like.

Although this might change, some countries have cheap and fast mobil data network providers. For instance I believe there is a scandinavian provider that allows mobile users to download 1000GB per month for around 50USD. And then you have 5G... so the limiting factors do change.

> Sometimes it's a good solution, and it's good that we have it, but should you depend on it?

Right. You usually get much more fluid performance by rolling your own. Then again, how fluid do you ned "preference settings" to be? Different tools for different purposes.

On Thursday, 3 October 2019 at 18:15:10 UTC, Chris wrote:

> Thanks. Good on you. How will it work once it's finished? How hard would it be to integrate it into an Android Studio / Xcode project / toolchain, e.g. could I add it as a dependency or would I have to compile it and package it as an additional lib? Are there any plans for auto generated bridges, e.g. JNI calling rt_init() or something?

I can give some answers related to iOS, although I'm not that guy working on the iOS project.

The simplest would probably be to add an external build step in Xcode to compile the D code, which should produce a static library. Then just link with that static library. It's a bit simpler on iOS since everything is native code and there are nothin like JNI that needs to be handled.

For interfacing between the Swift/Objective-C code either the `extern(C)` or `extern(Objective-C)` can be used. DStep [1] can generate bindings to Objective-C code.

I think it should be possible to implement an application completely in D as well.

[1] http://github.com/jacob-carlborg/dstep

On Fri, Oct 04, 2019 at 02:14:33PM +0000, Jacob Carlborg via Digitalmars-d wrote: [...]
> The simplest would probably be to add an external build step in Xcode to compile the D code, which should produce a static library. Then just link with that static library. It's a bit simpler on iOS since everything is native code and there are nothin like JNI that needs to be handled.
[...]

FYI, on Android there *is* a C API in the NDK that you can use to interface with the OS. IIRC Java/JNI is not strictly necessary, though it's certainly more convenient since a large number of built-in resources are only accessible to Java (esp. the various GUI components).

I chose the mixed Java/D route mainly so that I can just leverage off the Java stuff that's already built-in, instead of homebrewing everything from scratch in D.


T

-- 
If you think you are too small to make a difference, try sleeping in a closed room with a mosquito. -- Jan van Steenbergen

On Friday, 4 October 2019 at 15:02:36 UTC, H. S. Teoh wrote:
> FYI, on Android there *is* a C API in the NDK that you can use to interface with the OS. IIRC Java/JNI is not strictly necessary, though it's certainly more convenient since a large number of built-in resources are only accessible to Java (esp. the various GUI components).

I wonder how hard it would be to port Flutter to D and bypass Java/Swift entirely. I don't think "modern" Dart is all that different.

https://flutter.dev/docs/resources/technical-overview