No, on the PC side, I was wondering if it would be possible to do something similar on android
Check out this:
I am learning B4A and I would like to understand more about Reflector and JavaObject. As far as I understand so far, the following code using Reflector: Sub VideoFrameAtR(dir As String, f As String, ms As Long) As Bitmap Dim r As Reflector Dim obj As Object Dim bmp As Bitmap...
Even in .net, I tend to just “set” a reference to the external .dll, and at compile time that .dll is included.
The only use case where I do runtime loading of .dlls?
Well, when building COM objects for use with office/Access and VBA?
Well, these days so many corporate computers are locked down. So, I’m not allowed to “register” my COM objects without elevated rights.
So, in this case I built a “tiny” .net loader. So, now my VBA can load + consume .net code (classes) or code modules, and I don’t have to register the .net .dll’s as COM objects anymore. I only have to copy the .dll’s to the target computer – no installer or elevated rights required.
However, if I was not using VBA, then I really can’t think of a reason to load .dll’s at runtime vs simply referencing them in the Visual Studio project.
Much the same applies to B4A.
B4A has “nice” support for external libraries.
Remember, you have a “library” folder. In that folder you can toss in the “jars” and you off to the races. (Assuming they have the xml and the interface defined).
And you can create instances of java objects as per the above link.
Quite sure in some cases code is loaded at runtime. The jdbc drivers to my knowledge do this. So, you could include the MySQL driver, one for SQL server, and in code you can “specify” which driver to use. So, this might be a valid example of a use case.
So, there are two issues here:
1)
I want to consume some external code libraries.
B4A has provisions for this. In fact we drop in external jar libraries into our “library” folder all the time.
2)
The other issue?
I want to load some code at runtime because of security restrictions, or some other reason.
However, the two goals are “different”.
And assuming you COULD load at runtime? The interface to such code would have to be defined ahead of time. (Like what occurs for library code jars).
In other words, assuming a runtime loading ability? It will NOT get you off the hook as requiring a correct interface to that code.
All I am saying is don’t assume that if a runtime load option existed, it would eliminate the need for an interface that works with B4A to exist.
So runtime loading will not go past jail and allow you to skip this interface part, nor would it make things less work for you the developer (you still need the interface defined).
In .net? AS noted, I see little reason or advantage to “load” at runtime as opposed to just “referring” the external .dll as part of the project.
I can’t think of a pressing use case even in .net to load .dll’s. (Sans my above exception). You know, the great battle that rages on between IT locking down computers, and us poor developers cooking up endless way to get around locked down computers to run our software! It is a great battle of epic proportions – and one that rages on!! (app-v anyone???).
If I was working with just .net? You don’t need to register those external assemblies. You can use “x-copy” deployment (a simple copy of the .dll’s along with your project will suffice – you don’t even need an installer for this. And you don’t need runtime loading of the dll’s via the reflection libraries to do this. Its rare that "loading" vs a simple reference to the .dll in the project will help you.
So, I think context here is important.
Are you just hoping and wishing to consume library code, even java ones? Well, you can do that with B4A. Runtime loading if available will not help, nor will such an “option” reduce the developer workload, nor eliminate the need for the interface.
I could ask what the goal here is?
The issue of loading at runtime is really a different issue and goal of just needing to use external code.
So use of external code = yes.
Loading it at runtime = no, but then again, you don't need this option for any real use case I can think of.
Regards,
Albert D. Kallal
Edmonton, Alberta Canada