New feature: modules groups and more

[Erel]

Sure. One of the main purposes of the feature discussed above is to allow you to easily share modules between different projects and different platforms.

 

[Sandman]

This is great, and I can see from the topic that it's about Modules. But I wanted to ask if Libraries would also be included somehow? See this Wish as an example:

Add a project specific libraries folder

 

[Erel]

But I wanted to ask if Libraries would also be included somehow?

Not in this update.

About your request, I understand where it comes from however I'm not sure whether the issues that it will cause (multiple copies of the same libraries with different versions) are worth it.
You can see how Google (Android) has moved from simple jar files to central repositories.

 

[alwaysbusy]

@Sandman To somehow solve the problem of knowing which version I used of a library, I make a copy of the jar and xml and include the version number in it:

e.g.

ABMaterial3.75.jar
ABMaterial3.75.xml
ABMaterial4.00.jar
ABMaterial4.00.xml

So in my project I get this (notice there are two ABMaterials in there, and 4.00 is used in this project, 3.75 not):

 

[Sandman]

(I feel this should be its own thread, didn't mean to really hijack this one. Let me know if you want me to delete this post and create a brand new thread instead.)

About your request, I understand where it comes from however I'm not sure whether the issues that it will cause (multiple copies of the same libraries with different versions) are worth it.

Yeah, I can see that point.

But please weigh in the benefit of knowing that each pull of a project gets the correct libraries at the same time. That's worth quite a lot for us who use git, mercurial or something like that, and really really appreciate reproducible builds.

As for the potential issues that you say, perhaps this simply could be solved by using the (in my very humble opinion) under-utilized "warning list" (don't know correct name) in the Logs tab? It seems possible to simply add a

Library conflict: Serial (Version 2.15 in Shared Libraries, Version 2.21 in Project Libraries)

You can see how Google (Android) has moved from simple jar files to central repositories.

Sorry, no, I can't. Perhaps because I'm a bit new to this whole develop-for-Android-thing and lack history background?

 

[Misterbates]

... however I'm not sure whether the issues that it will cause (multiple copies of the same libraries with different versions) are worth it ....

Just an observation that the new module linking feature could lead to "multiple copies of the same modules with different versions" ... I'd second Sandman's request and would love to be able to store libraries in a project folder such that git could store/restore them as needed.

 

[Erel]

Just an observation that the new module linking feature could lead to "multiple copies of the same modules with different versions"

It actually makes it much easier to share modules between projects instead of copying them.

BTW, I'm not against adding support for project specific libraries. Still need to think about it.

 

[Misterbates]

It actually makes it much easier to share modules between projects instead of copying them.

Agree

BTW, I'm not against adding support for project specific libraries. Still need to think about it.

Thanks! I see organising modules (so they can be shared between projects) and organising libraries (so they can be shared between projects) as aspects of the same underlying need - to be able to build a deliverable from a number of components in a way that supports reuse, version control etc.

 

[Cableguy]

Something just popped into my mind...
Imagine you created an app using this "linking modules" feature... And you delivered or published the finished product..
A few months later you upgrade or change the linked module in a way that the previous apps that used the "older" version break...
How do you prevent that?
Will this new feature come with a "prepare project for distribution" option, that would copy all the liked files to the project so that upgrading a linked module would cause no break in the code if we needed to make changes...

 

[Erel]

It is your responsibility as a developer to:
1. Decide which modules should be shared and which shouldn't.
2. Think about other projects when you modify a shared module.

The other side of this argument, is that if you copy modules then any bug fix or improvement should be manually applied to all copies.
As I lately started writing cross platform modules based on XUI library, I can tell you that it is very difficult to add each change to each of the three projects.

The IDE helps you in several ways:

1. You can see in the modules tree which modules are located in a different folder:

2. You can always build a zip file with all modules using Export as zip. This can be useful if you want to keep a specific build.
3. The IDE monitors the modules files (of the currently open project) and automatically reloads modified modules, with an option to undo the changes. This is useful when the same module is open in multiple projects.

 

[Erel]

Example of sharing xCustomListView class between B4A, B4J and B4i. It also shows that when you modify the class in one IDE (and save it) the changes are updated in the other IDEs:

 

[LWGShane]

It also shows that when you modify the class in one IDE (and save it) the changes are updated in the other IDEs

Praise Erel

 

[Roycefer]

Erel, if you're still taking requests for the Modules tab, here are some old but still valid ideas: https://b4x.com/android/forum/threads/modules-tab-upgrades.57547/