You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository was archived by the owner on May 6, 2021. It is now read-only.
Pain points of having the app separate from the library:
We have to maintain 2 projects
We have to provide a different APK every time
Huge possibility of incompatibility if people don't update do the latest APK when we release a new version of the library
Possible solutions:
Like LeakCanary: 2 library projects, one for debug and one for release. Release version is a no-op, while debug is the fully fledged project. In this case, the changes to the codebase are minimal, we just need to include the app in the library and add a no-op version of the library, with a shared interface between the 2, so that the code does not need to be changed when the release app is loaded
Merge everything in a single library and play with flavours: this means we have a common source folder that contains the common interface, than we leverage the debug and release flavours so that the code is only present in the debug version. In this case, it means providing all our dependencies as debug only, and make sure we don't rely on the library BuildConfig.DEBUG flag but on the external app.
Pain points of having the app separate from the library:
Possible solutions:
debugandreleaseflavours so that the code is only present in the debug version. In this case, it means providing all our dependencies as debug only, and make sure we don't rely on the libraryBuildConfig.DEBUGflag but on the external app.What do you think?