They are organized as Gradle projects containing Gradle modules. When you create an Android library in the Android Studio, it puts the library as another module into the same app project.Īndroid app projects are usually built with Gradle. We will adopt a modification of the second approach because it’s natural to the Android Studio. But, besides other well-known drawbacks of the monorepo approach, it’s the best practice to place all code components inside one project directory - yet the ‘commonlib’ can’t be inside the same directory with ‘app1’ and ‘app2’ at the same time But with two or more apps it would be an obvious code duplication and therefore not an option.įinally, there’s the “monorepo” approach: put all code - (‘app1’, ‘app2’, and ‘commonlib’) into the same Git repository and manage it together. With just one app that would have worked. If the changes do not work as intended, one has to repeat.Īnother approach would be to put the ‘commonlib’, code into the same repository and project as ‘app1’ or ‘app2’. and, finally, build and re-run the app to see what’s different now.obtain the updated artifact from the ‘app1’ or ‘app2’ project,.build and upload changes to the Maven (often this is done by CI and involves runnings tests),.This approach makes it difficult to quickly test changes in the library code: to do that one has to The configuration will allow one to work on the library sources together with both apps.Ī common approach would be to put the common library to the Maven and to use it as a binary dependency for each of the apps. This post describes a way to organize sources of 2 Android apps (‘ app1’ and ‘ app2’) using the same common library (‘ commonlib’). Did you know, that monorepo is not the only way to handle this?
for network protocols or UI animation), and both teams need access to it. However, they are might be using the same shared libraries (e.g. Imagine that you are developing a taxi service like Uber, with two separate apps (one for passengers, another for drivers).
0 kommentar(er)
