More flexibility in native library loading #37
+116
−49
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
As described in #36 , I'm looking to make the Devolay class more flexible so that I can control how the native libraries are loaded with the end game of getting my app to work/approved when deployed on the app store. With that in mind, there are two conceptual changes with this PR:
Allow developers to use the non-integrated Maven package
The
Devolaystatic initializer has been changed to only extract the integrated natives (if present). Without this change the integrated maven dependency must be used. The key issue is line32- this will always throw unless you are using the integrated maven package because the non-integrated one doesn't have the natives. Because the static initializer throws (and you can't catch those exceptions), theDevolayclass cannot be loaded, and therefore, cannot be used to do anything else (like attempting to load the natives from somewhere else).Allow developers to load the Devolay / NDI natives from any path
The above change is a requirement for this one - you can't load the natives from somewhere else if the
Devolayclass never loaded. However, now that the static initializer only extracts the natives (and crucially doesn't throw), we now have the ability to allow a developer to specify the natives paths using a newloadLibrariesmethod. In my specific use-case, to be approved by Apple to deploy on the App Store, the natives must be in a certain location in the app bundle and cannot be dynamically extracted from a jar file. To achieve this, I need to place the natives in the correct place in my app bundle and then tellDevolayto load them from that location.While there are quite a few changes here, I've tried to ensure as much backward compatibility as possible. Developers who never called the
loadLibraries()method will continue to experience the same behavior since it's called from every otherDevolayclass constructor. Developers who use the integrated Maven package shouldn't have to change anything, the static initializer extracts the natives as it did before and theloadLibraries()method uses the extracted paths to load the natives, again, as it did before.