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!)

[erawhctim]

@cortinico any interest/movement on solving this? Would you consider an external PR to address this?

I'd be interested in tackling it, but it's unclear to me what the best path forward is: do we modularize things and let consumers depend on a UI-less artifact (and ship their own UI), do we try and remove MDC as a dependency in the current module structure, or something else entirely? Would appreciate any thoughts you have!

[cortinico]

any interest/movement on solving this? Would you consider an external PR to address this?

I think it would be great to have this solved, but I currently don't have the time to invest on this. I'm more than happy to receive a PR that implements this.

Perhaps first would be ideal to have a diagram of how you envision the codebase to be modularized