Android-runtime: [Proposal] Enabling java source code or direct dex generation

[Plamen5kov]

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
    
    
    
  
  
• 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
    
    
    
  
  

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.

[petekanev]

I think reverting to the java source code generator is the way to go, not only because of the Android Studio integration, but also because users can, if and whenever necessary, peek into the Java files to see what has been generated for them. We need to make sure that both generators will pass the SAME tests, and have the same features.

In addition we can start discussing if and whether we are making changes to the plugin structure, because the current solution (flavors) does not scale, uses flavors inappropriately, and already causes problems when attempting to open a NativeScript project in Android Studio, or when trying to integrate NativeScript project in a native one. That will of course be a major breaking change for plugin authors, and if we are doing it, it will need to happen in stages (about 2 releases time?), with an announcement ahead of time, and eventually tooling (android studio project templates?) to help contributors upgrade.

[NathanaelA]

1. Can you explain what the differences to plugins will be, this is actually a pretty important thing to get on the table so we can know what changes we need to expect?
2. Any way we can do ALL the breaking changes all at the same time with the breaking changes(?) that are coming with the redesign of the lower level classes, and stylers.

[atanasovg]

@NathanaelA Such a change should be transparent to plugin authors and no breaking changes are expected.

[NathanaelA]

@atanasovg - According to Peter in his post on Dec 20th

That will of course be a major breaking change for plugin authors, and if we are doing it, it will need to happen in stages (about 2 releases time?),

So is this a breaking change for plugins or not?

[Plamen5kov]

@NathanaelA, there will be no breaking changes concerning the android plugins for the 3.0 release.