Separate data & UI modules

[erawhctim]

⚠️ Is your feature request related to a problem? Please describe

My request was revealed as I ran into the same problem as #801 (but ultimately not related to a problem, just an enhancement request)

💡 Describe the solution you'd like

It'd be great if Chucker could isolate its UI into a standalone artifact, separate from the "core" Chucker dependency, so clients could optionally use Chucker's built-in UI or build their own. I would say this problem is somewhat related to #801 and #579.

In its current form, the main chucker artifact requires consumers to be on the same versions of the Android/Jetpack libraries that the Chucker UI relies on (and pulling in those transitive dependencies, when not on the same versions, can cause unintended side effects).

📊 Describe alternatives you've considered

• Upgrading all my app's dependencies to match the versions that Chucker uses
• Trying to isolate the Chucker dependency into its own module to somehow circumvent the transitive dependency issue (I'm not smart enough in Gradle to figure this one out 😅)

📄 Additional context

🙋 Do you want to develop this feature yourself?

• Yes
• No

[cortinico]

In its current form, the main chucker artifact requires consumers to be on the same versions of the Android/Jetpack libraries that the Chucker UI relies on (and pulling in those transitive dependencies, when not on the same versions, can cause unintended side effects).

Agree. I think the underlying problem is more that we import libraries which ends up affecting the Debug Classpath (e.g. Material Design Components). If we would have no dependencies on external libraries we depend on, we won't have this problem.

[erawhctim]

If we would have no dependencies on external libraries we depend on, we won't have this problem.

Definitely agree. Modularizing the app seems like an easier path forward than removing dependencies (but maybe the opposite is true!)