-
Notifications
You must be signed in to change notification settings - Fork 158
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Only re-dex class files if class files have changed #31
Comments
also see this blog post: http://skepcode.posterous.com/reflection-hack-override-an-android-activitys |
Yeah, I've been meaning to try that. Basically we'd have a Ruboto Core app people install, and then other Ruboto apps could just depend in it having the pre-dexed JRuby stuff in /data/data/org.ruboto/files/jruby.jar. Might not be hard to prototype As a result, Ruboto apps would be tiny. |
I have been able to load a class from a separate app. I have added the code (commented) to RubotoActivity.java. I have no idea what the next step should be. Please help! I do create a classloader. How do we make that classloader active for JRuby? |
The original intent of this issue requires not using ANT to build the APK. I am thinking this might be a good idea, but I would like to hear from you all if you think we should struggle to gain control over the build process, and ditch ANT over time, or strive to re-use as much as possible from the ANT build scripts? Any thoughts? |
Postponing to version 0.5. |
Not re-dexing unchanged classes is now a standard feature of the Android SDK. Closing. |
Currently every time you build "debug" or "release" apk from a ruboto-core project, it re-dexes all of JRuby and your app's Java code. That's obviously unnecessary if the app's logic is mostly in Ruby.
update_scripts helps a lot, of course, but it would be nice if you could just build .apk files without re-dexing stuff that hasn't changed. It would also avoid the confusing situation where an app has been re-built and re-installed, but the scripts have not been updated.
We should have dexing happen as a separate step, dependent on whether the libs jars and the app's .java/.class files have actually changed. If they have not, the existing dex file can be used. This would greatly speed up the build/deploy/test cycle for Ruboto apps.
The text was updated successfully, but these errors were encountered: