Skip to content

[Proposal] Enabling java source code or direct dex generation #663

Closed
@Plamen5kov

Description

@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.

Metadata

Metadata

Assignees

Labels

Type

No type

Projects

No projects

Milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions