Restructure the repo

[kirillt]

This repo will collect individual modules, each module should be possible to use on its own as a dependency.

• Top-level folders should be complete libraries with their own build config
• GitHub Actions workflows should be separated for separate components
• Same components could exist for different platform, e.g. filepicker-android and filepicker-ios (in future)

Approximate module structure should be something like this:

ark-components
|- data-link
|- data-link-android
|- data-link-ios
|- data-pdf
|- data-pdf-android
|- data-pdf-ios
|- data-images
|- data-images-android
|- data-images-ios
|- filepicker-android
|- tag-selector-android
|- tag-selector-tauri
|- score-widget-android
|- score-widget-tauri

Here, data-link and data-images are examples of future "data components". Such components will bring particular resource kinds, i.e. will allow handling files of certain type. They can denote a single file type like .link, or a group of file types like images:

• https://github.com/ARK-Builders/ARK-Shelf/issues/37
• https://github.com/ARK-Builders/ARK-Navigator/issues/249
• https://github.com/ARK-Builders/ARK-Globe/issues/10
• https://github.com/ARK-Builders/ARK-Navigator/issues/134

:warning: Dependent components considerations

It's not completely clear to me if we should be cautious about dependencies between components.

E.g. component B depends on component A:

• Can A and B be used in an app at the same time? Problems with versions could arise.. If usage of connected components poses some limitations, they must be clarified in README, e.g. if the user should inject only B.

• Would be more efficient to define GitHub Actions workflows in such a way that B and A run one after another, not separately since building B would mean building A again.

[tuancoltech]

@kirillt I would like to add some personal thoughts on your concern regarding : Dependent components considerations, as below:

Can A and B be used in an app at the same time? -> Yes.

Problems with versions could arise.. -> This happens almost all the time in every build system, and gradle build system is not an exception. The good news is we don't have to worry about that much when using gradle, since it was designed with a automatic version resolution. If the same dependency is found with more than one version in the build tree, by default, the highest version will be selected for the build execution (Unless we explicitly set the version to be selected). So, it's quite flexible here depending on what we need.

Would be more efficient to define GitHub Actions workflows in such a way that B and A run one after another, not separately since building B would mean building A again.

-> I don't see a problem with this (yet). Again, because this is gradle build system, if module A was built at least once, and its source code does not change, it won't be built again regardless of how many times it is included in other modules.