Skip to content
This repository has been archived by the owner on Oct 27, 2020. It is now read-only.

Dynamic jar-loading system. #18

Closed
wants to merge 24 commits into from
Closed

Dynamic jar-loading system. #18

wants to merge 24 commits into from

Conversation

ZachOhara
Copy link

After only a little while working with Android Studio, I started to realize how much faster my workflow could be if I didn't have to deal with Android Studio. I wrote some software that will read jar files out of the "/FIRST/" folder on the phone's SD card, and register those with the app. This has a number of advantages, which I plan to explain all of.

First, here are the general steps as to how the app opens the jar files:

  1. Recursively search the /FIRST/ directory for files ending in ".jar".
  2. Use Android's "dx.jar" library to convert all the found jar files into a format that is readable by the Dalvik VM. Cache these converted jars in the app's private cache directory.
  3. Iterate over all classes found in all the jars. If any given class is instantiable and is a subclass of OpMode, it is added to a list of valid op modes.
  4. Inside FtcOpModeRegister.register(OpModeManager), all the op modes in the list are registered.

Advantages of this process:

  • Teams will not have to ever open Android Studio. Any Java IDE can be used. As a byproduct of this, teams will not have to install any Android SDK, or struggle with getting their Android Studio to compile successfully. These may be trivial things to those who are familiar with Android Studio, but I struggled with this before I knew what I was doing.
  • There will only ever need to be one .apk file for teams to install. This, in my (limited) experience, vastly accelerates the development process when writing robot code.
  • Teams will be able to use any Java IDE that they feel comfortable with, as long as they have a way to compile their code to a jar file. Programmers that are new to the Android platform, or even to Java itself, will have a much easier time developing code for the new FTC control system.

Disadvantages of this process:

  • Starting the app is very slow. From my initial tests, every jar file in the /FIRST/ directory adds about one second to the load time of the app. This slowdown is mostly due to the time it takes to convert the files from a standard jar format to a Dalvik-compatible format. Luckily, this difference is almost negligible if teams package their code in a small amount of jar files. Additionally, this may be further sped up if the app caches the Dalvik-compatible jars and reads directly from them.
  • Robot code must be written and compiled in Java 6. This is not a huge disadvantage, as Java 6 is almost identical to the current version (Java 8, as of writing this). Some fancy features of Java 7 and 8 (anonymous classes, lambdas, etc.) are not available. The biggest downside of this is that teams will have to figure out how to compile their code using Java 6.
  • The Robotcore library will have to be manually added to the compile path of a team's chosen IDE(s). This does not require distributing the source code of Robotcore, because the jar file is currently available in this repository by using an archive tool (7-zip, winrar). Adding compile dependencies is a straightforward process in most IDE's, but this may subtract from the intended "plug-'n-play" workflow.

Overall, I strongly feel that this will make the development process easier for all teams interested in using Java programming to control their robot.

Here is full list of changes (trivial or not) that have been submitted with this pull request:

  • The discussed functionality has been implemented in the new files DalvikCompiler and OpModeClassLoader. Both of these are in the opmode package, and have javadoc comments included for almost all members.
  • Accidentally removed FtcRobotController.iml. This was a mistake, and will need to be reverted before the app will compile. This mistake has been corrected.
  • Added the "dx.jar" Android library to the /libs/ folder, and registered the library in build.gradle.
  • Accidentally changed the indentation of FtcRobotControllerActivity to tabs. It appears a formatter was let loose on the code, and this can be just as easily solved with another formatter. Besides this, no substantial or functional changes have been made to the activity.
  • The original op modes that came packaged with the app have been moved from the opmodes package to the sampleops package. They are also no longer registered in the app, but can be re-registered easily and as needed.
  • The same formatter that tore apart the activity also got to the op modes. This can easily be fixed with a different formatter.

ZachOhara and others added 24 commits August 23, 2015 01:52
@ZachOhara
Update readme for Thunderbots
960ad9a
@ZachOhara
Adapt project to open easier
b07e0db
@ZachOhara
Remove default op modes
52f62f7
@ZachOhara
Add preliminary dynamic class loader
7e3f96a
@ZachOhara
Add Thunderbots-sdk as a library
099e9b2
@PranavMathur
Merge pull request #1 from ftctechnh/master
35960f5 
Update K9 bot disclaimer and Remove non-generic .pdf file names.
@ZachOhara
Finished rudimentary dynamic class loading
90b2cd4
@ZachOhara
Add the 'dx' dalvik compiler to the app
5243097
@ZachOhara
Merge branch 'dynamic-loading' of https://github.com/Thunderbots5604/…
1066aa9 
…Thunderbots-Robot-Controller
@ZachOhara
Add new gitignore
b7e4865
@PranavMathur
Remove .iml file
c6684a5
@ZachOhara
Renamed TBotsDXCompiler to DalvikCompiler
1b30af8
@ZachOhara
Rename TBotsDXCompiler to DalvikCompiler
761812d
@ZachOhara
Rename TBotsClassLoader to OpModeClassLoader
e114ac1
@ZachOhara
Add documentation to DalvikCompiler
dd17997
@ZachOhara
Add documentation for OpModeClassLoader
d5d7fc7
@ZachOhara
Merge remote-tracking branch 'ftctechnh/master'
03b9970 
Conflicts:
	.gitignore
@ZachOhara
Remove thunderbots-sdk.jar from libs folder
dcd4f66
@ZachOhara
Remove a comment from getPrivateFilesDir()
5b7f628
@ZachOhara
Restore some files to default
4c79bca
@ZachOhara
Re-add default op modes
7286761
@ZachOhara
Add copyright headers
67a53a0
@ZachOhara
Modify copyright headers
401f627
@ZachOhara
Revert "Remove .iml file"
3cb8fe4 
This reverts commit c6684a5.
@PranavMathur
Copy link

@JacobAMason @ftctechnh @tomeng70 Hey guys, have you considered merging this commit? It would help rookie FTC teams, and they should have the new software as soon as possible.

@JacobAMason
Copy link
Contributor

@PranavMathur I'm not actually part of this decision process, but to get a PR merged, it's going to really need to be in the direction that the designers want this to go. It might be best, in the meantime, for @ZachOhara to set up an easily cloneable branch that rookies could use. I haven't personally had the time to review this PR; the load time is a small concern, speaking as a former FTA, but it seems like a nice addition. It would be great if others could check this out and report back on the results.

@PranavMathur
Copy link

@JacobAMason We've run tests on the new and old systems, and the load time is negligible, especially compared to the time it takes in the current system to rebuild the entire app and download it onto the phone.

@ZachOhara
Copy link
Author

I wouldn't exactly say that it's negligible, but it is not likely to be
an issue. Additionally, there are ways to mitigate the load time, such as
caching files, or adding a button in the interface that only loads when the
user is ready for the delay.

@JacobAMason
Copy link
Contributor

@PranavMathur @ZachOhara Remember that the drivers will need to be able to restart the robot remotely from the Driver Control station. I haven't checked your code, but that reset should be taken into account. If at all possible, the jars should stay loaded across the reset, but I'm not sure how the reset affects the Robot Controller.

@ZachOhara
Copy link
Author

ZachOhara commented Sep 17, 2015 via email

@cmacfarl
Copy link
Collaborator

I think your best bet here is to simply maintain a fork
of the official FTC repository with your workflow changes.

I am NOT an official FIRST voice, but my guess is that
this will be legal, you just do so at your own risk. FTA's
would be under no obligation to help a team using an
unofficial fork assuming of course no cheating is going
on.

In general pull requests should be broadly applicable without
changing team workflow or FTC documentation, or
fix specific bugs. Since we don't have the sdk source the
latter is moot, and for the former this change puts quite a few
constraints on usage that I'd rather not see. I can't quite
tell if this is optional or not, but our team is going to make
heavy use of anonymous classes, so being forced into
a version of java that does not support this construct
would be a non-starter.

A better place to publicize this change is on the forums,
pointing to your fork. If people like it, they can either
clone your fork directly or patch your diffs into their own
clone/fork.

And a general courtesy best practices thing to remember is to never
push cleanup work onto another party through a pull
request. By which I'm referring to your style changes.

Craig

On Fri, Sep 11, 2015 at 11:25 PM, Zach Ohara notifications@github.com
wrote:

After only a little while working with Android Studio, I started to
realize how much faster my workflow could be if I didn't have to deal with
Android Studio. I wrote some software that will read jar files out of the
"/FIRST/" folder on the phone's SD card, and register those with the app.
This has a number of advantages, which I plan to explain all of.

First, here are the general steps as to how the app opens the jar files:

  1. Recursively search the /FIRST/ directory for files ending in ".jar".
  2. Use Android's "dx.jar" library to convert all the found jar files into
    a format that is readable by the Dalvik VM. Cache these converted jars in
    the app's private cache directory.
  3. Iterate over all classes found in all the jars. If any given class is
    instantiable and is a subclass of OpMode, it is added to a list of valid
    op modes.
  4. Inside FtcOpModeRegister.register(OpModeManager), all the op modes in
    the list are registered.

Advantages of this process:

  • Teams will not have to ever open Android Studio. Any Java IDE can
    be used. As a byproduct of this, teams will not have to install any Android
    SDK, or struggle with getting their Android Studio to compile successfully.
    These may be trivial things to those who are familiar with Android Studio,
    but I struggled with this before I knew what I was doing.
  • There will only ever need to be one .apk file for teams to install.
    This, in my (limited) experience, vastly accelerates the development
    process when writing robot code.
  • Teams will be able to use any Java IDE that they feel comfortable
    with, as long as they have a way to compile their code to a jar file.
    Programmers that are new to the Android platform, or even to Java itself,
    will have a much easier time developing code for the new FTC control system.

Disadvantages of this process:

  • Starting the app is very slow. From my initial tests, every jar file
    in the /FIRST/ directory adds about one second to the load time of the app.
    This slowdown is mostly due to the time it takes to convert the files from
    a standard jar format to a Dalvik-compatible format. Luckily, this
    difference is almost negligible if teams package their code in a small
    amount of jar files. Additionally, this may be further sped up if the app
    caches the Dalvik-compatible jars and reads directly from them.
  • Robot code must be written and compiled in Java 6. This is not a
    huge disadvantage, as Java 6 is almost identical to the current version
    (Java 8, as of writing this). Some fancy features of Java 7 and 8
    (anonymous classes, lambdas, etc.) are not available. The biggest downside
    of this is that teams will have to figure out how to compile their code
    using Java 6.
  • The Robotcore library will have to be manually added to the compile
    path of a team's chosen IDE(s). This does not require distributing the
    source code of Robotcore, because the jar file is currently available in
    this repository by using an archive tool (7-zip, winrar). Adding compile
    dependencies is a straightforward process in most IDE's, but this may
    subtract from the intended "plug-'n-play" workflow.

Overall, I strongly feel that this will make the development process
easier for all teams interested in using Java programming to control their
robot.

Here is full list of changes (trivial or not) that have been submitted
with this pull request:

  • The discussed functionality has been implemented in the new files
    DalvikCompiler and OpModeClassLoader. Both of these are in the opmode
    package, and have javadoc comments included for almost all members.
  • Removed FtcRobotController.iml. All iml files are now ignored
    through .gitignore. This was not something I did intentionally but it does
    not seem worthwhile to reverse this change if it is being ignored.
  • Added the "dx.jar" Android library to the /libs/ folder, and
    registered the library in build.gradle.
  • Accidentally changed the indentation of FtcRobotControllerActivity
    to tabs. It appears a formatter was let loose on the code, and this can be
    just as easily solved with another formatter. Besides this, no substantial
    or functional changes have been made to the activity.
  • The original op modes that came packaged with the app have been
    moved from the opmodes package to the sampleops package. They are also
    no longer registered in the app, but can be re-registered easily and as
    needed.
  • The same formatter that tore apart the activity also got to the op
    modes. This can easily be fixed with a different formatter.

You can view, comment on, or merge this pull request online at:

#18
Commit Summary

  • Update readme for Thunderbots
  • Adapt project to open easier
  • Remove default op modes
  • Add preliminary dynamic class loader
  • Add Thunderbots-sdk as a library
  • Merge pull request Default API version for compiling is set to 21 #1 from ftctechnh/master
  • Finished rudimentary dynamic class loading
  • Add the 'dx' dalvik compiler to the app
  • Merge branch 'dynamic-loading' of
    https://github.com/Thunderbots5604/Thunderbots-Robot-Controller
  • Add new gitignore
  • Remove .iml file
  • Renamed TBotsDXCompiler to DalvikCompiler
  • Rename TBotsDXCompiler to DalvikCompiler
  • Rename TBotsClassLoader to OpModeClassLoader
  • Add documentation to DalvikCompiler
  • Add documentation for OpModeClassLoader
  • Merge remote-tracking branch 'ftctechnh/master'
  • Remove thunderbots-sdk.jar from libs folder
  • Remove a comment from getPrivateFilesDir()
  • Restore some files to default
  • Re-add default op modes
  • Add copyright headers
  • Modify copyright headers

File Changes

Patch Links:

—
Reply to this email directly or view it on GitHub
#18.

@ftctechnh ftctechnh closed this May 27, 2016
@ghost ghost mentioned this pull request May 31, 2016
Closed
Peterohio pushed a commit to Peterohio/ftc_app that referenced this pull request Dec 14, 2017
@JeremyYao
Merge pull request ftctechnh#18 from JeremyYao/master
952d0ba 
11/3 Concept Lift
sahithi-thumuluri added a commit to 6150FTC/Main-19-20-FTC6150 that referenced this pull request Apr 4, 2019
@sahithi-thumuluri
Merge pull request ftctechnh#18 from 6150FTC/master
a9f9fbe 
Sahithi 1/2/18
sahithi-thumuluri pushed a commit to 6150FTC/Main-19-20-FTC6150 that referenced this pull request Apr 4, 2019
@JeremyYao
Merge pull request ftctechnh#18 from 6150FTC/master
b22afe4 
stall update
sahithi-thumuluri pushed a commit to 6150FTC/Main-19-20-FTC6150 that referenced this pull request Apr 4, 2019
@HarshiniSomisetty
Merge pull request ftctechnh#18 from 6150FTC/master
d44fb75 
FollowWall Changes
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Reviewers
No reviews
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.
5 participants
@ZachOhara @PranavMathur @JacobAMason @cmacfarl @ftctechnh