Closed
Description
The idea of this issue is to start a discussion and with it reach the best decision.
- Leave generation of dex files instead of java source code
- pros:
+same code base - cons
- resulting dex are harder to maintain
- for api levels 4.x and below we need to have a recommended way of usage with multidex
- pros:
- Revert to generator creating java source code.
- pros
+ easyer Android Studio Integration
+ compiler does a lot of work for us
+ instant support for older 4.x devices (generated dex files will be in classes.dex with no effort on our side) - cons
- different codebase with runtime
- need to keep runtime binding generator and static binding generator equal on features for the most part
- pros
IMO the bigger issue is we need to take advantage of the already established native toolchain. By generating dex files directly, we skip a lot of tooling that can be useful to us like:
- Android Studio - publishing, debugging apps, native configuration
- java compiler - generation of bridge methods, code analisys
- new perspective toolchains like Jack and Jill
- gradle - optimizations like debug, release packaging and flavors
My vote goes for reverting to generation of java source code. Please give your opinion @NativeScript/android-runtime
We already had an internal discussion, but I urge everyone to give their opinion in this issue in order for all parties to get better understanding of this issue.