Wish Improved Project Structure for Enhanced Portability

carlos7000

Well-Known Member
Licensed User
Longtime User
I would like to suggest the creation of two folders within the project structure: one called "Libraries" and another called "Additional Files". In the "Libraries" folder, B4A should automatically copy each library used in the project, while the "Additional Files" folder should contain all the necessary supplementary files, such as .jar files, required for successful compilation of the application.

This suggestion stems from personal experiences where I have encountered the need to access an application I developed months or even years ago. During that time, I may have switched computers or encountered other changes, resulting in missing files and inaccessible libraries when attempting to compile the project. This situation often leads to hours or even days spent searching for the necessary libraries, and in some cases, certain libraries cannot be found at all. Consequently, I am faced with the choice of starting a new project from scratch or losing a significant portion of the work already completed.

By incorporating these specific folders into the project structure, we can achieve greater portability and ease of use, ensuring that all required libraries and additional files are consistently available. This enhancement would help avoid setbacks and time wasted on situations like the one described above.



Note: I used this image in another suggestion, but they are separate suggestions.
 

Mashiane

Expert
Licensed User
Longtime User
Good point. For example when you develop an app for someone and have to distribute to them. Zipping it does not include the libraries used in the app, only assets and the source code. One has to then go out to the additional libraries, find them and then include them separately.

This process takes time. The libraries manager is already wise enough to know the Path of the lib used. Hopefully it can be possible to include "distributable" libraries with the project zip or include a file in the zip of where to download them.

 

Alexander Stolte

Expert
Licensed User
Longtime User
Just backup the lib folder in the cloud? Like DropBox, OneDrive or NextCloud?
 

Sandman

Expert
Licensed User
Longtime User
For whatever it's worth, this functionality could be somewhat solved by making a separate tool to include the required files in the exported file.
 

aeric

Expert
Licensed User
Longtime User
An alternative is to use Comment Links to include some files
 

carlos7000

Well-Known Member
Licensed User
Longtime User
Just backup the lib folder in the cloud? Like DropBox, OneDrive or NextCloud?

Yes, I use Dropbox. However, B4A has a problem. When I load an old project that has several missing libraries, it quickly displays a warning about the missing libraries, but I barely have time to read a few lines. Then, I have to search for those libraries in the backup and install them. After doing that, B4A shows me a large number of variables with issues because some libraries are still missing. Trying to find which library corresponds to each variable, without remembering their names among dozens of libraries, is a real headache. The only solution is to copy all the libraries, but the downside is that there are many that I no longer use and I don't want them to appear in B4A. If the project had a copy of the libraries, it would save a lot of time.
 

carlos7000

Well-Known Member
Licensed User
Longtime User
For whatever it's worth, this functionality could be somewhat solved by making a separate tool to include the required files in the exported file.
Yes, of course, an external application could do it. However, wouldn't it be better if B4A automatically copied the libraries to the project folder? Furthermore, that external application would have to search variable by variable, object by object, etc., and create a list of their different types. The question is, how can I search for those types in the .jar files of the libraries? They are compiled files, so I would have to decompile them. B4A already knows which type of variable corresponds to which library. It's much easier for B4A to do it.
 

carlos7000

Well-Known Member
Licensed User
Longtime User
It would be absurd to have copies of libraries in every project!
If you change your PC, you just have to add the additional libraries (which you will have saved in a backup file).
If we consider the number of files in B4A (excluding additional libraries), there are only 151 files and they occupy just 6.9 megabytes of space. Having a folder in the projectthat contains the necessary libraries offers more advantages than drawbacks.

 

carlos7000

Well-Known Member
Licensed User
Longtime User
+ not all libraries are freely distributable. ABMaterial and BANano are such libraries.
In this suggestion, the objective is not to share or distribute the libraries. The objective is to ensure that the project can be resumed at any time without encountering surprises when changing computers or other devices, and to prevent the project from being unable to update due to one or more missing libraries or additional files for some reason. Additionally, some projects use older versions of a library, while others use a more recent version of the same library. This implies that every time you work on one project or another, if both libraries have the same name, you have to switch them to work on a specific project. I recently encountered this issue with a project that uses one of the early versions of the CustomListView library and another project that uses xCustomListview. I tried updating the old program, but changing hundreds of lines has been a major problem, causing frequent program crashes, etc. Since the application is quite large, we have chosen not to update it with that library. Another application I have is experiencing issues with a function that is used to project GPS points. As a side note, that function requires coordinates, a bearing, and a distance. We were planning to update the library, but the function that performs this task is not present in the Gps, FusedLocationProvider, or LocationManager libraries. What happened to that library and what is its name?
 

Filippo

Expert
Licensed User
Longtime User
I hope this functionality will be implemented, it would be really helpful.
But there should be the possibility to update the files and the library.
 

alwaysbusy

Expert
Licensed User
Longtime User
In this suggestion, the objective is not to share or distribute the libraries.
I do not have any problems with your original request. I completely agree why you made the request. But your request was quickly expanded to:

For example when you develop an app for someone and have to distribute to them.
This was the reason for my statement. My license does not allow that.
 

Andrew (Digitwell)

Well-Known Member
Licensed User
Longtime User
When I load an old project that has several missing libraries, it quickly displays a warning about the missing libraries, but I barely have time to read a few lines.
In the latest version of the IDE, these messages are also output to the log window.

There is another issue to overcome, the IDE uses the global "additional libraries" folder to search for libraries which are not part of the standard install. This could be solved by allowing multiple paths in this field and having a search order, local additional libraries, then shared additional libraries.

I would vote for the "package" option which would copy the files from the global additional libraries folder to a local folder for archiving purposes.
 

carlos7000

Well-Known Member
Licensed User
Longtime User
I do not have any problems with your original request. I completely agree why you made the request. But your request was quickly expanded to:


This was the reason for my statement. My license does not allow that.

Most of the time, when we send a project to a collaborator or a forum seeking help, we have to send additional libraries or files. There have been occasions when I've encountered a problem and someone would say, 'The code is not sufficient. Share the project.' Then they would say, 'I couldn't test your project. I need the additional libraries to help you.' I only have two options: either not sending them and continue struggling for days or weeks, or sending them.

I understand their point, but I believe that the pros outweigh the cons. Not implementing this feature doesn't prevent those who wish to share the libraries they acquired from doing so. They simply have to copy and send them.
 

Filippo

Expert
Licensed User
Longtime User
This was the reason for my statement. My license does not allow that.
Just because your licensing does not allow this functionality, it should not be implemented?
I don't use your license and I don't share my projects with anyone.
I need this functionality for archiving, because as it is, most of the time you can't recompile an archived project, because many libraries change.

I hope Erel makes the right decision.
 

carlos7000

Well-Known Member
Licensed User
Longtime User

That's right. I believe that most of us don't share the libraries we have acquired. Personally, I don't think implementing this feature will change that. If someone wants to distribute the libraries they have acquired, they don't need to wait for this function to be implemented. They can do it right away
 

alwaysbusy

Expert
Licensed User
Longtime User
It is clear now that some of you do not care for the work that library makers on this forum make, the support they give or any fair play licensing system. Cool...

If someone wants to distribute the libraries they have acquired, they don't need to wait for this function to be implemented. They can do it right away

It is not because you CAN do something that you SHOULD, that is not how the law works.

I've experienced cases where my free BANano library (but with this restriction in its license) was suddenly available on github as part of another payable library. I had to give the authors a slap on the wrist and they elegantly solved it by removing it and just putting a link to the original download place on this forum which was alright for me.

At the very least as a library maker I should have the ability of his library being excluded from such a system. Since you both don't use my libraries, that shouldn't be a problem for you. That would at least prevent the more novice developer of breaking any license unwillingly. In this scenario, those who do copy and distribute manually are mostly well aware they are doing something fishy and are just a$$holes (pardon my french ).

I need this functionality for archiving, because as it is, most of the time you can't recompile an archived project, because many libraries change.

Again, for personal archiving I understand your case (somewhat, see further). What I talk about is of people selling source code on this forum and distributing some restricted libraries with it. This distinction is essential to understand my point.

But even in the case it would be implemented, it doesn't even solve the problem! You have an archived project, what do you do then? Overwrite your existing 'last' updates of the libraries so you can compile your old project? Probably make a copy first of the 'updated' ones so you can put them back later for your newer projects? Seems like a lot of manual labor too. Or even worse. Someone downloads a 5 year old project from this forum to check something out and overwrites his updated libraries. Hope he has a backup somewhere...

Users should always work with the latest libraries and fix the problems that may arise because of a newer version. If they don't, other problems will come up that are now fixed in the newer versions. And the only way to make sure of that is by having one central place where you can download them. As a dev, I always document where I got my libs from, be it for B4X, Java or any other one I use in a project. Seems like common sense to me. And I agree that this 'central' point could be better in B4X. We now have the google document Erel made where library makers can put in the info for the latest updates and it is a good start. The IDE even shows you if your library is outdated. Another good addition. But I do feel this could be even better.

B4X is build in such a way you can easily keep copies of the whole environment next to each other, although my previous statement of always using the latest versions stands.

I 'm under the impression most B4X library makers do a pretty good job of making their libraries backward compatible. And if it breaks, they probably have a very good reason because Google, Apple or any other vendor has depreciated something so you shouldn't use that old one anyway.

Maybe a compromise could be that, when exporting a project, a list with links to the download place on the forum of all the libraries used in the project is included? This info is available in Erels Google document and it would assure you are using the latest versions. Even a 'quick' download 'all new or newer' versions in the library manager could be nice.

Alwaysbusy
 

Filippo

Expert
Licensed User
Longtime User
I'm sorry, but that would be a lazy compromise.
I understand your problem, but you can't avoid someone abusing your license policy, even without this new functionality.

I have some libraries that I use in several projects.
Now it happens that I have to change a library for one project.
A few months later I have to implement changes in another project and I don't think that the library has changed.
If I am lucky I notice the error before I upload the app to the store, if not I have a problem.
With this functionality I could solve the problem at once.

But as already written, I hope that Erel will make the right decision.
 

alwaysbusy

Expert
Licensed User
Longtime User
A few months later I have to implement changes in another project and I don't think that the library has changed.
So a couple of weeks later, you start a new project and you forgot you used an old one. If you're lucky you notice it right away. If not you have a problem. So you created a new problem and your suggestion would not change a thing. Always use the latest versions is the only good solution.
 
Cookies are required to use this site. You must accept them to continue using the site. Learn more…