iOS Question How to handle duplicate b4xlib dependencies in compiled native libraries?

[b4x-de]

I want to create native libraries that will eventually be used in the same app.

However, the following problem arises when native library A loads b4xlib B and native library C also loads b4xlib B. Then, in the app that uses only the two native libraries A and C, I get an error message during compilation stating that the contents of b4xlib B are defined twice. As a result, the app cannot be compiled.

This happens more quickly than you might think, for example, when libraries A and C simply want to read and write XML using map2xml or xml2map.

XUI Views.b4xlib is particularly challenging. It is used by many other components, such as PreoptimizedCLV.b4xlib, SimpleMediaManager.b4xlib, B4XBitmapEffects.b4xlib, and many others. If these B4xlibs are located in different native libraries, they cannot be used together in the same app.

Even in a clearly structured architecture, problems arise when the view layer uses SimpleMediaManager.b4xlib (which depends on iHttpUtils2.b4xlib) and the actual network communication via HTTP takes place in a lower layer. In that case, these two layers cannot be compiled as native libraries because both would import iHttpUtils2.b4xlib and therefore they cannot be used together in the same app.

Are there strategies for dealing with such situations?

(Since I don't have any ideas for a solution, I simply think that internal libraries should no longer be deployed as b4xlibs in the future, but only as native libraries. That would alleviate the problem somewhat.)

Currently, it is a major challenge to structure the architecture of a large app into horizontal layers or vertical components using native libraries, because in both cases there can be issues with B4xlibs being imported multiple times.

If you would like to know why I need native libraries on local builder and don’t simply work with b4xlibs, please read here:

Hosted Builder reports Error: ** BUILD INTERRUPTED ** on a large B4i project

Hi, I have a large B4i project that is built with the hosted builder. The build is interrupted near the end, but I cannot find a real compiler or linker error in the log. The final error is only: Error: ** BUILD INTERRUPTED ** The generated Xcode build is very large. The log contains 508...

www.b4x.com

Hosted B4i Builder extremely slow after confirming install on device

Hi all, I’d like to ask whether anyone else is currently experiencing very slow behavior with the Hosted B4i Builder, specifically after the install confirmation dialog. In my case, the build itself completes normally and without unusual delays. After that, I get the dialog asking whether I...

www.b4x.com

 

[hatzisn]

I faced something similar (not exactly) in B4J. I was using in a project a library I created which was using XLUtils which was using jPOI which depends on a java jar library. The lib I had created I had also compiled it to a native b4j library. It merged the dexes and resulted in a totally working library. Then using @tchart 's B4J Scanner I found out that the java jar library that jPOI used had a vulnerability. I changed this java jar library and changed also the XML of jPOI to point the "depends on" to the new non vulnerable library. I compiled again my project but B4JScanner was still reporting the old java jar library. I figured out that my library had merged the dexes according to the previous settings of jPOI. So recompiling my library it solved the issue.

What I want to say is that maybe a solution to your problem might be to not convert the classes to native libraries which obviously merge the libraries that are referenced but to convert them in b4xlibs that call them dynamically.

 

[Erel]

Native libraries shouldn't reference b4xlibs. This is an inherent limitation related to the way b4xlibs work.
B4xlibs can reference other b4xlibs and there is no problem with having "duplicate" b4xlibs. They are ignored.

I understand your need to split the project, however you will need to try and organize it in a way that the native libraries do not depend on b4xlibs.

 

[b4x-de]

[...] organize it in a way that the native libraries do not depend on b4xlibs.

I understand the argument that the problem caused by using b4xlibs in native libraries can be solved by not using b4xlibs in native libraries. However, I would like to point out that even internal libraries are provided as b4xlibs.

When programming native libraries, I would have to do without the following: B4XCollections, B4XDrawer, B4XFormatter, B4XTable, BCTextEngine, BCToast, iHttpUtils2, KeyValueStore, MediaChooser, PreoptimizedCLV, SimpleMediaManager, Xml2Map, and XUI Views.

And, of course, unfortunately, this also means we can’t use contributions from community authors who have relied on the b4xlibs in their own work or provide their own work as b4xlib.

Programming without b4xlibs is a very serious limitation.

That is why I would like to make two suggestions on how the problem could be solved differently:
1. Internal libraries could be provided only as native libraries, which would make their use straightforward.
2. A new optional attribute #LibraryUseNamespace: [false, true] could be used during native library compilation to specify the namespace for the included classes, thereby preventing conflicts with classes of the same name from other libraries.

I know this isn’t a solution to hatzisn’s problem (@hatzisn), which arose from a specific situation. His situation is similar to the one that motivated tchart’s recent post (https://www.b4x.com/android/forum/threads/b4j-scanner-sbom-vulnerability-scanner.170912/). Both posts demonstrate that managing dependencies in libraries in B4X is a challenging issue when it comes to professional software development. I therefore earnestly ask that we work together to find a solution to this, even if it means changing (and hopefully improving) the way libraries have worked in b4x up to now.

 

[Erel]

The way forward is with b4xlibs. They have many advantages over native libraries, especially for cross platform libraries such as the one listed above.
There are edge cases where native libraries are still needed, but these are the exceptions.

Note that with some work, you can build platform specific native libraries from those b4xlibs. Might be a good solution for your use case (and will also reduce compilation time).

 

[hatzisn]

I know this isn’t a solution to hatzisn’s problem (@hatzisn), which arose from a specific situation. His situation is similar to the one that motivated tchart’s recent post (https://www.b4x.com/android/forum/threads/b4j-scanner-sbom-vulnerability-scanner.170912/). Both posts demonstrate that managing dependencies in libraries in B4X is a challenging issue when it comes to professional software development. I therefore earnestly ask that we work together to find a solution to this, even if it means changing (and hopefully improving) the way libraries have worked in b4x up to now.

The perfect solution in my problem would be to convert my lib to b4xlib and place it in B4J's additional libraries. I re-compiled my library to a native lib in order to get the job done quickly because I didn't create it from the start as a b4xlib, but in the future if I forget the dependencies and add both my lib and XLUtils in a project or jPOI I will face the same situation you did. That is why it is simpler and SAFER to create b4xlibs and reference them.

Here is a link for a B4XTemplate that makes B4X Lib creation a piece of cake.