Support building native Android applications with Dart

[Sébastien Deleuze]

Now that Lollipop and its ART runtime have been officially released, I think it is time to begin discussing about using Dart for Android native application development, as described in Cyril Mottier blog post Shaping the Future of Android With Dart. When I say Dart, I talk about Dart as a language, without the VM, since the goal would be to use Dart to develop native applications that will run on top of ART runtime.

With 462 stars, the related issue I created a few month ago is by far the most popular one on Dart bug tracker. Current Java support on Android seems to stick to Java 7, and even with Java 8 support Android would be legacy compared to the Swift language now used for IOS development. IMO, Dart seems to be the perfect candidate for the the next language Android application development. Anyway, this post is not about discussing if Android should support Dart in addition to Java or not, but rather how this should be implemented, in order to evaluate the technical issues, found potential workaround, and get community (and perhaps Googlers) feedback about the best way to achieve that.

I think we could identify 2 main needs:

1. Generate a Dart version of Android Java API
   
2. Create a compile chain from Dart to DEX and/or OAT (more details here)
   

For the first point, the obvious solution is to create a tool that will automatically generate a Dart Android API based on Java one. The main difficulty here is how do we expose in Dart Java specific behaviors like threads or method overloading.

For threads, my proposal would be:

 - To have a 1 thread = 1 isolate model

 - Create a mechanism that could allow developers to pass easily a function to an isolate and get notified when this function has been completed (like the current AsyncTask). It may be implemented with current message passing mechanism or by adding new capabilities to Dart. Maybe something like Justin described here.

For method overloading in Java, the Dart API automatically generated from the existing Java one should be able to have single methods with optional/named parameters based on the overloaded methods found in the Java API.

For the second point, there are various possibilities.

For a production grade solution, adding a DART frontend in addition to the Java one in the new Jack compiler seems IMO the more robust way to implement it. From what I have understood of Jack, with a Dart front end it could be possible to generate bytecode with any of the Jack backend (currently DEX or Jayce, a new undocumented bytecode format). But this is a lot of work, and even if the source code is available, it may be difficult for people outside Google to do that.

For a prototype, any solution capable to generate Java source code, Java bytecode (Java 7 without InvokeDynamic instructions) or DEX bytecode could allow us to create a first prototype.

Compiling Dart source code to DEX bytecode directly will be hard and not future proof if not done with Jack, so I guess it's not a good idea. A Dart to Java bytecode compiler prototype has been created a few years ago by Rémi Forax, but it uses heavily InvokeDynamic instructions, not supported by Android compile chain. Additionally .class support may be removed from Jack at some point.

The Dart to Java transpiler option seems to me the "simplest" one for a prototype.

I am really interested by getting in this thread your ideas and proposals about how to implement Dart support for Android, as well as your feedbacks about what I have proposed in this message.

Sébastien

[Yulian Kuncheff]

Great idea starting this discussion.

I think the best way would be a transpiler similar to j2objc or even dart2js. We might be able to take advantage of dart2dart and dart2js to see if we can make a dart2java. Once its in Java, the normal stuff takes over. I think another alternative is to write Dart2ART. or a Dart Art module of some sort. Directly plug into ART instead of taking any of the middle steps. Pretty much converting Dart code to ART Bytecode or whatever it uses.

We might be able to take advantage of stuff like Jetbrains MPS or something.

-Yulian

[Cogman]

@Yulian  Wouldn't it be dart->DEX?

Really, the thing we would want is to be able to use Dart with the android libraries.  Getting it into ART doesn't really accomplish much if we aren't able to work with the android OS in any meaningful way.

I would suggest we look at how JRuby and JPython get this done.  Perhaps we can take a similar approach to JDart.

--
For other discussions, see https://groups.google.com/a/dartlang.org/
 
For HOWTO questions, visit http://stackoverflow.com/tags/dart
 
To file a bug report or feature request, go to http://www.dartbug.com/new

To unsubscribe from this group and stop receiving emails from it, send an email to misc+uns...@dartlang.org.

[Hans - Jürgen Alps]

Threads and background tasks are essential for Android in order not to block the UI thread.  Dart is single threaded. So it is very questionable if Dart is the right choice for Android. 

If this problem would be solved somehow then I would not spend effort into a Dart to Java compiler but I would enhance the Dalvik VM to be also capable of executing Dart byte code.

Hans

--

[Sébastien Deleuze]

Dart is single threaded, but supports concurrency through isolates.

By improving Justin Fagnani initial work on running services in Isolates, I think it could solve the problem for Android.

See https://github.com/justinfagnani/services/tree/initial for more informations ...

[Günter Zöchbauer]

If this would be a blocking issue Dart would also not work well in the browser.

Dart has isolates and heavy computation should be moved away from the UI isolate but otherwise the async execution model works fine for this use case.

[Hans - Jürgen Alps]

I would recommend you to read the following article of the dart documentation.  https://www.dartlang.org/articles/event-loop/
In the browser Dart is compiled to JavaScript and Javascript is single threaded by design.  Isolates can be used with the VM, but they are not the same as threads because they can not be interrupted and can communicate only via messages.

[Lex Berezhny]

Hello,

I think that trying to get Dart to work well (production quality) with native Android APIs *as they are today* is not going to be worth the large amount of effort it would take.

Looking at some of the Chrome talks from the last Google I/O (example: https://www.youtube.com/watch?v=_yy0CDLnhMA) and considering the direction other Mobile OS'es are headed: Tizen, Ubuntu Phone, Windows Phone, etc. It would seem that HTML5 based apps are being pushed to the level of native apps.

This means Dart -> Java is definitely a dead end/wasted effort. Dart already runs on Android natively (https://code.google.com/p/dart/wiki/Android). Many of the performance and other exceptional work being done on Dart VM would be a waste if you end up transpiling to Java. SIMD support in Dart comes to mind...

It seems to me that the unspoken recommendation from Google with their port of the Android Paper UI to Polymer and support in Dart Editor and Chrome Dev Editor for building mobile apps that the end goal is to transition people to building HTML5 apps as native apps.

I think by the time a production quality Dart -> Java transpiler with accompanying library, tooling and paradigm mismatches resolved (threading vs isolates, etc) is built... Dart VM will run as fast and efficiently as Dalvik and the Blink rendering engine will render your Polymer based list components at comparable speeds to Android native ListView. All that with the added benefit that your app now also works in Chrome and Chrome OS (and iOS, Tizen, Ubuntu Phone, etc).

While Dart VM is not on every Android phone it probably will be with the next Android release...

In the meantime you can sample the future by building Chrome Apps in Dart and using Google fork of Apache Cordova to deploy your app to Android and iOS. It's true that for now the Cordova framework compiles your dart to JS but I think that's only a temporary crutch, it allows people to start learning and building with the technology *today*, while the rest of the necessary pieces fall into place to have Dart VM on all Android phones.

Step 1: Chrome app in Dart: https://github.com/dart-gde/chrome.dart

Step 2: Chrome App -> Android/iOS: https://developer.chrome.com/apps/chrome_apps_on_mobile

Googles fork of Cordova has already produced dozens (maybe hundreds) of new APIs that expose Android/iOS to Cordova and thus Dart (through dart2js). I don't think they would have put this much effort into this if they weren't intending for people to use this tool chain.

I think the best time spent right now would be porting the Cordova stuff from JavaScript to pure Dart. That can probably even be automated to some extent but once that part is done than you can take the dart2js step out of the equation completely. You'd get native Dart VM performance, Blink rendering and access to native Android and iOS APIs (Cordova actually also supports Tizen and many others but this doesn't appear in the Google fork of Cordova yet...)

Anyways, that's my take on this whole thing.

 - lex

[Lex Berezhny]

On Tue, Nov 25, 2014 at 12:06 PM, Hans - Jürgen Alps <hansjuer...@googlemail.com> wrote:

If this problem would be solved somehow then I would not spend effort into a Dart to Java compiler but I would enhance the Dalvik VM to be also capable of executing Dart byte code.

Dart doesn't have byte code. See:  https://www.dartlang.org/articles/why-not-bytecode/

 - lex

[Fun And Jokes]

I think the way this will be implemented is Dart VM in Android Chrome and users being able to download the website as a app. Users can already set websites as apps but being able to download for offline is something they need. We may need the API to for notification and camera.

[Günter Zöchbauer]

There is no big difference between the models when Dart code is executed in the Dart VM or built to JS. In JS isolates are workers which are similar to isolates in the Dart VM. This doesn't change anything.

[Günter Zöchbauer]

I also expect this is the way Dart will be made available to Android.

[Günter Zöchbauer]

Which doesn't mean it isn't possible to compile Dart to some sort of bytecode (Java byte code, ...) of course only if someone builds such a compiler.

[Sébastien Deleuze]

I think I need to elaborate more why I think the Dart VM is not an option (even if like you, I am a strong supporter of this awesome VM).

I fully understand and agree that it is frustrating to have this awesome Dart VM and not reusing it for Android native application development, but I really think the bytecode + ART runtime way is the only one possible if we talk about first class support.

I am not an Android developer but I try to take the POV of Android team at Google and Android developers since THEY are going to decide if they are going to use Dart or not. Mobile native development is not Web development. These are 2 different worlds and if you have a look in detail to Android 5.0, you will see that these are going to stay 2 different worlds at runtime level for quite a long time, even if there will be some convergence, like Paper Elements, Material Design, perhaps for the component model ... Google has put a HUGE effort in creating this ART runtime that uses OAT bytecode compiled Ahead Of Time on the device to go faster, consume less power, etc. Android API is huge, and is developed to run as bytecode (DEX on Android <= 4.0 or OAT created from DEX in Android >= 5.0).

If you have a look to ART in detail (See What is ART ? and also this article on Jack and Jill compilers), you will see that Google is progressively removing .class from the Android compile chain. That's why every solution implying .class or .java file is not a future proof solution. I only mentioned this possibility as a potential first Proof Of Concept, nothing more.

Using Dart to develop Android application means that you will have to support pre Lollipop devices, so you will need to be able to generate DEX bytecode. I guess there will be also an improved byetcode format (Jayce ?) with better capabilities (no 65K method limit, more suited for dynamic languages) that will be used in the Android >= 5.0 compile chain, but anyway being able to generate DEX bytecode at least for compatibility with pre Lollipop devices is mandatory.

Jack is the new Android compiler (source code available here) that support multiple frontends (input files) and backends (bytecode output). Currently there is a Java frontend (source code) and  2 backends : a DEX one (source code) and a Jayce one (source code).

For me, the only production grade possible solution is to add a Dart frontend to Jack in addition to the Java one, that will allow to produce DEX or Jayce bytecode from Dart source code and execute it in ART runtime. If anybody has the skills and the time to analyse the Jack codebase and make a feedback about the feasibility of this, it would be awesome.

Any Dart for Android solution will require these 2 different worlds (Android and Dart) to collaborate and understand each other. This will be a technical AND also a cultural challenge, but I really hope it will happen ...

[Lex Berezhny]

On Tue, Nov 25, 2014 at 3:31 PM, Sébastien Deleuze <s...@deleuze.fr> wrote:

I fully understand and agree that it is frustrating to have this awesome Dart VM and not reusing it for Android native application development, but I really think the bytecode + ART runtime way is the only one possible if we talk about first class support.

Why do you think that ART runtime will be the only possible way to build first class apps?

Specifically, why do you think Dart VM will not be added to Android as a first class citizen (lets say by next Google I/O)?

I am not an Android developer but I try to take the POV of Android team at Google and Android developers since THEY are going to decide if they are going to use Dart or not. Mobile native development is not Web development. These are 2 different worlds and if you have a look in detail to Android 5.0, you will see that these are going to stay 2 different worlds at runtime level for quite a long time, even if there will be some convergence, like Paper Elements, Material Design, perhaps for the component model ... Google has put a HUGE effort in creating this ART runtime that uses OAT bytecode compiled Ahead Of Time on the device to go faster, consume less power, etc. Android API is huge, and is developed to run as bytecode (DEX on Android <= 4.0 or OAT created from DEX in Android >= 5.0).

It makes sense that Google will continue to improve the current Java ecosystem since Android is written using these tools and a lot of businesses and developers depend on this ecosystem. Google has a bad rap for abandoning technology and in this case a lot of people would be upset if Android completely switched to Dart and only Dart.

Here is an analogy: Once Dart is in Chrome standard will Google remove v8? I don't think so.

Sames applies to Java ecosystem in Android once Dart is added as first class citizen.

There are over a million apps already written for Android using Java tools, there is no way Google would release a new version of Android that does not run all of those apps. And if they have to maintain that tool chain, might as well continue to improve it and make those millions of apps run faster and more efficiently.

 - lex

[kc]

Google should give devs a roadmap for it's client side platforms. We shouldn't have to guess or create workarounds.

[Lex Berezhny]

I doubt they'll ever provide a roadmap for the same reason no other large commercial company provides roadmaps to their activities. 1) They don't really know what will happen, 2) people will complain if they don't do what they said they would do and 3) they don't want competitors to know what's in the works.

More importantly, Google seems to only keep around projects that have significant uptake. Dart is too new to make any grand plans.

[Greg Lowe]

There is a push to expose all mobile capabilities to the web and packaged apps. In the meantime there is also cordova.

For apps which require native performance there is also the Android NDK.

I think we will see web technologies replacing most Java based android development in the not too distant future.

But if you want to hack on this in the meantime, a good starting point might be to read about how the mono guys brought c# to android.

http://blog.xamarin.com/android-in-c-sharp/

[kc]

Roadmap:
Apple - Swift.
MS - open source Core .Net. (Though MS still need to flesh out its client side story).

No one in Google outside of the Dart project has described its future. Dart kicked off when the Android and Chrome/OS teams were separate. This is no longer the case.

[Sébastien Deleuze]

Android and Chrome/OS teams are still separated, but Sundar Pichai is now in charge of both, so indeed we may expect to see more convergence between both.

But using Dart for both Web and Mobile development does not mean using Dart VM everywhere for runtime.

The same way that some web developers were not very happy to see Dart VM in addition to V8 (do you remember the Dart is here to replace Javascript bad buzz), I think most Android developers would not be happy to see a solution where Dart run in the Dart VM and call Android API with a wrapper. Android API is millions line of code and run as DEX or OAT bytecode, so by definition, a native Android application has to run also in Android VM (Dalvik or ART). And since Google has just created a whole new VM and compile chain, and seems to be designed to support other languages in addition to Java (note that I never said that Java support will be discarded), I think it is the best way to implement that.

I have 0 insight about Google roadmap but what I see is that:

 - There was nothing about Dart at Chrome Dev Summit 2014!

 - After a long battle between Dart VM and V8 on performance side, Dart VM runs less than 2x faster than V8 (not because Dart VM is bad, but rather because V8 is awesome)

 - Google need a better language than Java for Android development or it will quickly become a legacy technology

 - Dart is now supported on Google Cloud platform

I am more convince than ever that Dart is the ultimate language but could follow a different strategy than expected initially for runtime by not trying to replace everything with its Dart VM.

That means trying to integrate as natively as possible into the various platforms:

 - On server side, Dart VM is used and supported on Google Cloud Platform, no problem.

 - Use dart2js for all browsers, including Chrome, for Web development

 - Create a Dart compile chain to produce bytecode that will run natively on Android VMs

That's just a guess, so I may be wrong, but I hope it is their roadmap ...

[Victor Mendiluce]

Can't you just retrofit the Dart VM in Crosswalk like they did with Dartium?

I like the Mobile Chrome Apps approach. And you don't need to port the cordova plugins to dart, from dart you can just use the dart <-> js interop.

I don't know what would Apple say about having a VM deployed alongside apps, though.

[Greg Lowe]

> "by definition, a native Android application has to run also in Android VM"

The developers at Xamarin disagree.

"On Android, Xamarin ships a fully functional implementation of the .NET runtime, called Mono, bundled with your app so that your code executes with all of the power of C# and .NET, including JIT-compilation, memory management, reflection, and the .NET base class libraries. Developers can use any native features by interacting with .NET class libraries that provide one-to-one mappings to all of the native APIs on Android." http://xamarin.com/faq

--

[Sébastien Deleuze]

Google has just introduced ahead-of-time (AOT) compilation with ART for a lot of good reasons (performance, battery), I don't see them push another way to run applications on Android.

But like Xamarin guys did for IOS, if possible, it would be awesome to be able to reuse the Dart VM in the AOT compilation step performed on the device.

[Greg Lowe]

Given the incredible speed improvements of chrome on android, combined with the improved device api support in chrome apps, the reasons for using the Android Java apis are rapidly vanishing. Dart will come to android as part of chrome. If you need raw speed, then Java won't cut it either, and you'll need to develop the performance critical part of your application in C++ via the NDK. The advantage of developing this way also allows sharing more code with iOS, and web.

Also - I imagine the Dart language is not ideal for AOT given its very dynamic nature.

[Sébastien Deleuze]

I don't think dynamic languages are an issue for AOT compilation.

Another interesting information from https://sourcex.wordpress.com/tag/aot-compiler/: "Any language with an LLVM front end could be used to develop apps with ART (not just a language limitation)".

So a Dart compiler to LLVM may be also a good bet ;-)

[kc]

Google need to give the convergence story. MS have woken up.

[Greg Lowe]

> I don't think dynamic languages are an issue for AOT compilation.

You could compile to unoptimized code. But this is very slow. Using static analysis on a Dart program to infer the types, without looking at developer provided types would only provide partial results, and probably only help a little. But I guess you could have a flag to force the aot to trust the developer provided types, which would make things faster.

But the main point is why put all of the effort into writing an aot compiler, when you already have a vm with fast start up time? What does it gain? Certainly not performance - the aot code will not perform as well as the dart vm. And either way if you use aot or the dart vm you still need to port the entire android java api across to dart. (However the big benefit would be for cross compiling to ios.)

[Lex Berezhny]

If you can make your app look native (Polymer Paper UI), run at native speed (Dart VM on Android) and have access to most of the hardware and useful Android/iOS APIs (googles fork of Cordova) and produce re-usable code that will work on mobile and your web app, what would you gain from the gargantuan effort of porting Android API to Dart?

By programming against Android only API you are producing non-portable code. It seems the direction Google is taking Dart and Cordova is actually less lock-in and better for developers.

Why the eagerness to lock yourself into a single platform?

 - lex

To unsubscribe from this group and stop receiving emails from it, send an email to misc+uns...@dartlang.org.

[Lex Berezhny]

On Wed, Nov 26, 2014 at 3:38 AM, Victor Mendiluce <vme...@gmail.com> wrote:

I like the Mobile Chrome Apps approach. And you don't need to port the cordova plugins to dart, from dart you can just use the dart <-> js interop.

You are probably right. I may be thinking of premature optimization.

With js interop you'd end up going through quite a long chain of runtimes. For example to get the GPS location from device would end up being something like:

Dart VM -> js interop (Cordova) -> Dalvik VM/ART -> C++ -> hardware

Although *today* you have to run dart through dart2js to deploy with Cordova so it ends up being just an extra JS function call...

 - lex

[Sébastien Deleuze]

Thanks for your feedbacks, I think this discussion is interesting even if we don't agree ;-)

On mobile, native and web based applications do not offer the same user experience, the same functionalities, the same performance, and the same battery consumption. That's why most of the top Android applications are built as native apps and not with Cordova. I think Facebook app going native is a good example of what I mean.

I am a Web developer, so I would have preferred like you building Android application with Web technologies and Dart VM, but on mobile performance and battery are limited, and that changes everything. And I repeat that there was not a single word about Dart at Chrome Dev Summit last week, so don't take Dart inclusion in Chrome for granted.

I have never said that Android API implementation should be ported to Dart! The solution I have described would be to generate a Dart Android API (interfaces, not implementation) in order to have autocomplete, documentation and compilation working when building a native application with Dart. But when executing the application (as DEX or OAT bytecode), the existing Android API implementation would be called directly.

Please find bellow some updates about the latest information I found about LLVM.

ART support for LLVM is available here. LLVM tool repository is here and has already 2 bindings (ocaml and python). I think adding a Dart binding perfectly makes sense. Pre Lollipop devices will still need DEX bytecode but we can see this part later (or ART is perhaps able to generate DEX bytecode based on LLVM one). I don't think creating a Dart binding for LLVM is an impossible task. That said, there is no documentation for LLVM toolchain and ART so it is close to impossible to start something without Google involved ...

Somebody has written a LLVM IR to Dart converter. I have no knowledge of LLVM yet, so I can't know if this is relevant or not. 

I think we are at a point where a feedback from Dart and/or Android teams on this topic would really appreciated:

• What about the Dart VM versus ART solutions ?
  
• Is Dart -> LLVM -> ART solution an interesting one ?
  
• Is Google interested to work on the open on this topic in order to have some community involvement and feedbacks ?

[Sébastien Deleuze]

I have been able to discuss by mail with Eric Laforturne, the author ProGuard and of the Jack and Jill blog post.

Here is its feedback:

"I don't think there is support for directly interfacing with ART, so LLVM is irrelevant.

A standard app doesn't even know if it is running in a Dalvik runtime or in an ART runtime.

With the current Android runtime, I see two options to support non-Java languages:

• Compile to Dalvik bytecode (perhaps through Java bytecode, perhaps through Jayce bytecode) and let ART compile it to native code on the device.
  
• Compile straight to native code (ARM, x86, MIPS,...), with JNI for interfacing to the runtime. Most of the Android runtime is still written in Java.

As far as I know, Android uses LLVM in a number of completely different places:

• In ART in dex2oat (on the device), to compile Dalvik bytecode to native code.
• In Renderscript (on the development computer), to compile Renderscript (C) sourcecode to Renderscript (LLVM) bytecode.
• In Renderscript (on the device), to compile Renderscript bytecode to native code (or GPU code).

I might be missing some more. The code for LLVM in ART (art/compiler/llvm) is different from the other one you found (toolchain/llvm). Even if dex2oat uses a specialized version of LLVM, that is all invisible to the developer.

Jack uses the Eclipse front-end and does not seem to depend on LLVM."

So it seems that using LLVM is not a valid option.

This is a very valuable feedback since Eric is one of the world best Android bytecode specialist outside Google.

[Sébastien Deleuze]

Eric feedback makes me think that Dart support for building Android applications should be implemented:

 - With the Dart VM + JNI for interfacing to the Android runtime

 - With a Dart to Jayce bytecode compiler

I think the "Dart to Jayce bytecode compiler" is the best solution (the most native one), but we have currently no documentation of Jayce bytecode format ...

Any thoughts ?

[Filipe Morgado]

We don't how much Google is committed to Dart.

Maybe Dart should find its own way.

LLVM maybe not be currently an option on Android, but it could open other doors.

Back-ends include PNaCl, asm.js and native code, including iOS.

Even the flash player (AIR) would be an option. Still better than the DOM for most (mobile) cases.

IMO, Android should support LLVM and open the tool-chain to a lot more languages.

It wouldn't give us a unified API, but a unified language is a first step.

Something like OpenFL could follow for the UI (DOM fallback for the web).

Haxe, Xamarin and Microsoft, etc are doing it.

Would still love for it to happen.

Adding native int32/uint32/int64/uint64/etc (converted to int/num if boxed)... and structures would help for interop (and performance in some cases).

[Greg Lowe]

> in mobile, native and web based applications do not offer the same user experience, the same functionalities, the same performance, and the same battery consumption.

My prediction is that by the end of 2015 we will see:

• Dart in chrome
• A set of web components which match android ui
  
• Chrome app device apis on par with android apis
• Performance on par or better than Java developed android apps (including battery)

If this happens it will make a dart to dalvik aot compiler a waste of engineering effort.

It's difficult to predict the future - but it's not long to wait to see how this one turns out.

[kc]

Google are funding Dart but are they backing it?

We shouldn't have to examine the entrails of ART for an augary.

[Kévin Platel]

I personally think that it's a great idea to try to put Dart as an option to create native android app, and will be happy to help if a project begin in that way,

but i think that an effort put in a Dart2Class can be a better option because it can allow dart not to only be usable for android but also to interact with the all java world. 

[Eyal LEZMY]

Hi guys,

As an Android developer the Sebastien's point of view seems really relevant.

I would be really interested by following this project and why not trying to contribute to it. Even I'm still not familiar with the compilers internals.

The Dart to Jayce format solution seems good even if I wonder if it's not better to try to work first on Dart to Dalvik by using Java bytecode as a first proof of concept.

Sebastien, you mentionned a Dart to Java bytecode how much you think is it a good starting point for the project?

[Sébastien Deleuze]

Thanks for your feedback Eyal.

The JDart project is really a POC and uses heavily InvokeDynamic, but this kind of instruction is from what I understand, no supported by the Android compiler.

[Sébastien Deleuze]

This new article about Jack and Jill contains interesting informations:

One of the most distinct additions to Jack is ANTLR v3.4, a very powerful tool for generating language parsers. This may prove to be the first step towards language-level customizations, support for additional languages, or very advanced language inlining. For example, it may soon be possible write raw SQLite queries in the middle of code, or write an app in C# or Python without the use of special libraries (assuming the runtime supports all of the necessary features).

 

There are existing ANTLR 3 and ANTLR 4 runtimes for Dart, so it may be another interesting way to explore for Dart support on Android.

[kc]

I suggested a while back in the thread 'Dart and a Unified Runtime for Google' if:

"Anyways - could someone write a Dart to Dalvik compiler. That opens up the possibility of some kind of synthesis between the Chrome and Android platforms."


But, I really think it's Google who should start pulling things together with a roadmap. Dart VM and ART? JS and GWT?

Geographically dispersed teams working on overlapping projects at somewhat cross purposes will cause problems eventually. Including developer confusion.

[Steven Roose]

If only someone from the Dart or Android team would give us a quick heads up on how they currently see it.
What's with the secrecy? Or is it just ignorance?