digitalmars.D - semi OT: Android -> chrome native client in the browser
- Laeeth Isharc (38/38) Apr 02 2015 Hi.
- Laeeth Isharc (11/11) Apr 02 2015 http://9to5google.com/2015/04/01/how-to-use-arc-welder-to-run-a-plethora...
- Rikki Cattermole (3/38) Apr 02 2015 Might be an interesting little project to get D running on.
- Laeeth Isharc (4/6) Apr 02 2015 In theory if an application works on android/x86, there should be
- Rikki Cattermole (2/8) Apr 02 2015 Don't be so sure. Won't ARC not support native code?
- Laeeth Isharc (21/33) Apr 02 2015 The answer should be simple to tell, except that things have
- Joakim (39/62) Apr 02 2015 Thanks, I had not seen this, only the earlier hack where some dev
- Laeeth Isharc (71/101) Apr 02 2015 Yes - my judgement (acknowledging I am stepping outside of my
- Joakim (6/13) Apr 03 2015 With native approaches like asm.js or Native Client, you're still
Hi. I am sure most of you saw this: http://arstechnica.com/gadgets/2015/04/googles-arc-opens-up-to-developers-runs-android-apps-on-most-desktop-oses/ Relates to the Google native client technology which caught attention a while back (not all of it favourable - 'I thought we put a stake through the Active-X vampire, and yet it returns') but seems to have gone quiet, although in meantime as I understand it chrome store apps can be written in C, C++, etc. It's just that nobody uses the chrome store. There are potentially some benefits for light enterprise applications (particularly from third party vendors) through not having to go through the barrier of getting the user to receive IT approval for the application, have them get around to installing it, reinstall when the first time didn't work etc. But the shine off that is taken away by the presentation problem of having your app show up in the same context as some game for teens. From a D perspective, native client seemed lots of work for little tangible benefit, since it depends on a heavily modified compiler toolchain. (It uses a restricted instruction set, a little more restricted than originally as holes were found). https://developer.chrome.com/native-client https://developer.chrome.com/apps/getstarted_arc The idea of being able to have your application run as native code for speed and not have to work in two languages is appealing though. So perhaps keeping an eye on the new development that allows any Android app to be run on Chrome OS, Windows, Mac OS X, and Linux (via a conversion tool called ARC Welder). As I understand it, DMD works more or less with Android/x86 (so presumably this tool might be able to convert DMD applications to native client so they run in the browser). When we have android support for ARM, I guess it is feasible to write D apps that run in a browser on ARM phones/tablets. I have zero experience with ARM and Android development, so I may be missing something. I will take Adam's advice on trying things and give it a try if I get time. Laeeth.
Apr 02 2015
"Laeeth Isharc" <nospamlaeeth nospam.laeeth.com> http://9to5google.com/2015/04/01/how-to-use-arc-welder-to-run-a-plethora-of-android-apps-in-chrome/?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%3A+9to5Google+%289to5+Google+-+Beyond+Good+and+Evil%29 "Fair warning: While Instagram seems to be functional all around, a lot of apps are completely broken. If you think that you can just load up ARC Welder and run any Android app in existence, you’re going to be sorely disappointed. For one thing, Google Play Services is completely missing—so most Google apps are going to be rendered useless. This is only because ARC Welder is in beta, though, so we should expect to see support come at sometime in the future. Also, some apps just don’t work. The perfect example is Netflix, which simply didn’t load at all."
Apr 02 2015
On 3/04/2015 1:40 a.m., Laeeth Isharc wrote:Hi. I am sure most of you saw this: http://arstechnica.com/gadgets/2015/04/googles-arc-opens-up-to-developers-runs-android-apps-on-most-desktop-oses/ Relates to the Google native client technology which caught attention a while back (not all of it favourable - 'I thought we put a stake through the Active-X vampire, and yet it returns') but seems to have gone quiet, although in meantime as I understand it chrome store apps can be written in C, C++, etc. It's just that nobody uses the chrome store. There are potentially some benefits for light enterprise applications (particularly from third party vendors) through not having to go through the barrier of getting the user to receive IT approval for the application, have them get around to installing it, reinstall when the first time didn't work etc. But the shine off that is taken away by the presentation problem of having your app show up in the same context as some game for teens. From a D perspective, native client seemed lots of work for little tangible benefit, since it depends on a heavily modified compiler toolchain. (It uses a restricted instruction set, a little more restricted than originally as holes were found). https://developer.chrome.com/native-client https://developer.chrome.com/apps/getstarted_arc The idea of being able to have your application run as native code for speed and not have to work in two languages is appealing though. So perhaps keeping an eye on the new development that allows any Android app to be run on Chrome OS, Windows, Mac OS X, and Linux (via a conversion tool called ARC Welder). As I understand it, DMD works more or less with Android/x86 (so presumably this tool might be able to convert DMD applications to native client so they run in the browser). When we have android support for ARM, I guess it is feasible to write D apps that run in a browser on ARM phones/tablets. I have zero experience with ARM and Android development, so I may be missing something. I will take Adam's advice on trying things and give it a try if I get time. Laeeth.Might be an interesting little project to get D running on. Probably only worth a small toy project.
Apr 02 2015
Might be an interesting little project to get D running on. Probably only worth a small toy project.In theory if an application works on android/x86, there should be nothing more to do to get it running in the browser (just a 1 minute conversion). Just need to get the android cross-compiler up and running and then will see.
Apr 02 2015
On 3/04/2015 2:17 a.m., Laeeth Isharc wrote:Don't be so sure. Won't ARC not support native code?Might be an interesting little project to get D running on. Probably only worth a small toy project.In theory if an application works on android/x86, there should be nothing more to do to get it running in the browser (just a 1 minute conversion). Just need to get the android cross-compiler up and running and then will see.
Apr 02 2015
On Thursday, 2 April 2015 at 13:24:34 UTC, Rikki Cattermole wrote:On 3/04/2015 2:17 a.m., Laeeth Isharc wrote:The answer should be simple to tell, except that things have shifted a bit since the instructions were written so I don't yet have the dmd/android compiler running. But, as I understand it (which may be mistaken): native client (what we have had for some time in the app store) runs only a subset of machine code: https://developer.chrome.com/native-client However for an android app using NDK, nobody has ever said you cannot use a regular C compiler (and indeed the D compiler was not written to any such rules and apparently works). Since ARC-weld translates generic android apps (eg Instagram) - (although some do not work for unknown reasons) - it must be the case that ARC-weld does support native code and does something clever when it comes across instructions that are not permitted. If that's right, then you can now write chrome apps using D - there are some already in the store that have been translated, so it looks like although the program is beta, they allow you to submit translated apps (or allow some people to submit some apps, anyway). But it would be better to try than to guess.Don't be so sure. Won't ARC not support native code?Might be an interesting little project to get D running on. Probably only worth a small toy project.In theory if an application works on android/x86, there should be nothing more to do to get it running in the browser (just a 1 minute conversion). Just need to get the android cross-compiler up and running and then will see.
Apr 02 2015
On Thursday, 2 April 2015 at 12:40:14 UTC, Laeeth Isharc wrote:Hi. I am sure most of you saw this: http://arstechnica.com/gadgets/2015/04/googles-arc-opens-up-to-developers-runs-android-apps-on-most-desktop-oses/Thanks, I had not seen this, only the earlier hack where some dev got the alpha version of ARC working on desktop OS's on his own, which I thought about mentioning here but didn't. I figured it wasn't that important.Relates to the Google native client technology which caught attention a while back (not all of it favourable - 'I thought we put a stake through the Active-X vampire, and yet it returns') but seems to have gone quiet, although in meantime as I understand it chrome store apps can be written in C, C++, etc. It's just that nobody uses the chrome store.To be fair, they've actually done a lot to secure NaCl, unlike ActiveX. ;) But yes, nobody uses the Chrome Store: they seem to be trying to change that with ARC.From a D perspective, native client seemed lots of work for little tangible benefit, since it depends on a heavily modified compiler toolchain. (It uses a restricted instruction set, a little more restricted than originally as holes were found). https://developer.chrome.com/native-client https://developer.chrome.com/apps/getstarted_arc The idea of being able to have your application run as native code for speed and not have to work in two languages is appealing though.--snip--As I understand it, DMD works more or less with Android/x86 (so presumably this tool might be able to convert DMD applications to native client so they run in the browser). When we have android support for ARM, I guess it is feasible to write D apps that run in a browser on ARM phones/tablets.If we have Android support for ARM, what is the advantage of running in the browser on mobile devices? This is never going to work on iOS, because Apple doesn't allow full Chrome with NaCl on iOS, only the Chrome UI wrapped around Apple's local WebKit. WP? :D As for converting native Android D apps to run on ARC, they don't mention NDK, ie native, apps on their ARC webpage, but the Chromium bug tracker shows that they're working on some kind of NDK translation layer (funny that they hit the same 64-bit long double issues on x86 that I did): https://code.google.com/p/chromium/issues/list?can=1&q=ndk+label%3ACr-Platform-ARC As you said, NaCl requires a modified compiler that restricts the compiled binary to a more secure subset, so they appear to be translating NDK-compiled or our D code to what the NaCl sandbox accepts for it to work. There's talk of Posix translation and some sort of NDK translation source in a handful of those issues, but I don't see that source folder in the public git repo, so maybe it's unreleased: https://chromium.googlesource.com/arc/arc/+/master/src/ This may allow us to target NaCl easier by using D's existing Android support, assuming they ever get NDK Android apps fully translated to ARC. But I'm skeptical that all these native workarounds in the browser will ever really amount to anything- they haven't so far- not because I don't believe in native, but because you're often still stuck in the browser, ie the horrible HTML/DOM/js stack. I suppose they want to take the Android runtime everywhere, including the ART support that they're working on now apparently, so given the great success of the Android platform so far, who knows what will come of it.
Apr 02 2015
Thanks, I had not seen this, only the earlier hack where some dev got the alpha version of ARC working on desktop OS's on his own, which I thought about mentioning here but didn't. I figured it wasn't that important.Yes - my judgement (acknowledging I am stepping outside of my area of core expertise) is that this might turn out to be very important indeed. It's a slightly crazy situation today where you have to develop for the Mac, Linux, Windows, iOS, and Android - and it's not even all that comfortable to use one language for the different ports. I acknowledge that there are choices that make it easier in some ways than this simplistic description, but none of these options from what I have read (but without experience so far) seem to be without their faults too. [Tangent follows: We seem to be in a time when it pays to iterate rapidly. My interest and experience is more on the enterprise (or at least commercial) side, and there it is a real pain to deal with repeated updates from applications (that always seem to break things in their interactions with other things on Windows machines). I dealt with this personally in a similar way to a friend of mine who announced that he would be doing his own IT support henceforth and wished to be disconnected from the internal network and put on a DMZ. (Partner at a tech asset manager, so he could). But my point is - even at enterprise level, where it's a less obvious domain - some possibility that there are gains to be had (with appropriate restrictions, no doubt). On the other hand, as an economist I believe that if a resource becomes free due to temporary abundance, human beings find a way to make use of it - but it takes time, and for a while people get into the habit of wasting things and have a rude awakening when it becomes rather less scarce (which may not happen gently, life being what it is). I reckon that might be happening with memory usage and efficiency (if you act like I/O is the bottleneck, in a few years you can be sure it won't be any longer) - and until this is the new consensus, I adopt the position of a native code fanatic (as a multi-year trading view, not for a lifetime)].To be fair, they've actually done a lot to secure NaCl, unlike ActiveX. ;) But yes, nobody uses the Chrome Store: they seem to be trying to change that with ARC.Yes - the concept was not necessarily mistaken, but their timing was off, and they (Microsoft) were not the right people to do it.If we have Android support for ARM, what is the advantage of running in the browser on mobile devices? This is never going to work on iOS, because Apple doesn't allow full Chrome with NaCl on iOS, only the Chrome UI wrapped around Apple's local WebKit. WP? :DNot so much benefit to running in the browser on Android, obviously, except that I am somewhat pickier about the apps I install than the websites I take a look at, and probably this is true of many people. Small frictions cumulatively have large consequences in an age of short attention spans, low future time orientation, and a lack of determination and nerve. The benefit is you (if I have understood correctly - and I am not yet confident I have) can write something and have it be kind of usable across desktop platforms and android. (Presuming they do open up the app store - it looks like for now perhaps it is opened up to Arc-weld ported apps, but only for chromeos - although it is not clear). Of course you need to tweak according to the platform, and one shouldn't underestimate the trouble involved. But being able to produce something usable quickly is quite valuable.As for converting native Android D apps to run on ARC, they don't mention NDK, ie native, apps on their ARC webpage, but the Chromium bug tracker shows that they're working on some kind of NDK translation layer (funny that they hit the same 64-bit long double issues on x86 that I did):I think they might have it kind of working but maybe with glitches on native code. I don't know how much slow down is involved in the translation. Obviously ART/AOT changes many factors wrt relative advantage of native code (since it helps Java especially) - people say the difference is small, but the improvement in responsiveness doesn't seem small to me. But that doesn't detract from the possibly very appealing idea of being able to write in one language across everything. (except iOS).As you said, NaCl requires a modified compiler that restricts the compiled binary to a more secure subset, so they appear to be translating NDK-compiled or our D code to what the NaCl sandbox accepts for it to work.BTW here is what it looks like for x86: https://developer.chrome.com/native-client/reference/sandbox_internals/x86-64-sandbox#x86-64-sandbox Here is the API for a pure Chrome native client app: https://developer.chrome.com/native-client/c-api Here are some libraries that have been ported: https://code.google.com/p/naclports/wiki/PortListBut I'm skeptical that all these native workarounds in the browser will ever really amount to anything- they haven't so far- not because I don't believe in native, but because you're often still stuck in the browser, ie the horrible HTML/DOM/js stack.But you are stuck because people use IE, Firefox, Safari etc? Or something else? It's worth taking a quick look at the native client demos - there was some python thing to fix to get them to work when I looked at a few months back, but I can't recall exactly what it was - a few lines needed to be changed for one of the python scripts used to install them.I suppose they want to take the Android runtime everywhere, including the ART support that they're working on now apparently, so given the great success of the Android platform so far, who knows what will come of it.I agree, although things don't change overnight.
Apr 02 2015
On Friday, 3 April 2015 at 02:09:04 UTC, Laeeth Isharc wrote:With native approaches like asm.js or Native Client, you're still stuck with many web APIs. Not the case with ARC maybe, but it's brand new. As for other browsers, that has hurt NaCl and other native fallbacks, as each browser has their own preferred native route and none want to support the others.But I'm skeptical that all these native workarounds in the browser will ever really amount to anything- they haven't so far- not because I don't believe in native, but because you're often still stuck in the browser, ie the horrible HTML/DOM/js stack.But you are stuck because people use IE, Firefox, Safari etc? Or something else?
Apr 03 2015