Replies: 2 comments 1 reply
-
Any attempt at modularization is always welcome. Just like when google modularized their colossal play services library years ago, and everyone instantly benefited from that. And I'm thinking if javet ever supports i18n, it could be done the same way, so the people who never needed it will not be bothered in an javet upgrade. I'd even welcome a callback or an option to load javet native .so libraries, and have them loaded by myself. When apps are not distributed by play store (where you can use android bundles for smaller size), you usually need to create a huge universal apk containing code for every platform. There are already ways to do this (remove .so files from .aar, download manually the corresponding .so for the architecture of the device, then do System.loadLibrary() before touching any of the javet classes), but official support could be nice. |
Beta Was this translation helpful? Give feedback.
-
Here's a proposal: implementation("com.caoccao.javet:javet-android-base:3.0.4") javet-android-base would be mandatory for everyone, and base-native-libs for most people too, and you'd have nodejs and a hypotetical i18n optional. This way, if some other optional future feature that requires huge files becomes a possibility, you could add it this way painlessly. |
Beta Was this translation helpful? Give feedback.
-
Node.js for Android will be supported in v3.1.0. There are 2 options in terms of how to organize the AAR files.
1. All in One
Both Node.js and V8 will be packaged in the same AAR file.
PROS
CONS
exclude
needs to be put in the gradle file.2. Separated
Node.js and V8 will be packaged in separate AAR files.
PROS
exclude
in the gradle file.CONS
Note
8 votes ·
Beta Was this translation helpful? Give feedback.
All reactions