Add a way to access http requests in app

[djrausch]

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

I am developing an Android TV app and use Chucker to view requests. Because TV doesn't have split screen, we have to fully switch activities for view the list.

💡 Describe the solution you'd like

There are a few possible solutions for this:

• A view provided for use in app
• Expose the TransactionListFragment for use in app
• Expose a livedata/flow of HttpTransactionTuple from RepositoryProvider

📄 Additional context

A key use case for us would be on our video player fragments. We use ExoPlayer with OkHttp (same instance used for rest of app). We sometimes need to verify headers, params, etc for playback. Currently, we have a button on the remote launch the Chucker activity, but it would be much nicer to have inline.

🙋 Do you want to develop this feature yourself?

• Yes
• No
  Absolutely, wanted to get some feedback on the best way(s) to implement this

[cortinico]

Expose a livedata/flow of HttpTransactionTuple from RepositoryProvider

Seems like the cleaner approach to me.

Also it's probably related to #91 #305
Maybe we can shape your solution around #305 and craft something that provides the same capability to both features.

I have to say that I'm not overly excited by the idea of exposing Chucker internals outside of Chucker as this will increase our API surface.
On the other side, this sounds like a potential use case also for other apps.

[djrausch]

LiveData or flow would be much cleaner and allow for more customization by the end user. I don't think there are flows anywhere yet in Chucker, so we could start with LiveData and add flows in the future if needed.

I took a look at #305 and that seems to follow the general idea, but rather than a file, it's to the parent app.

Agreed on API surface. I am thinking through the best way to do this in order to expose the least amount as possible.

I was thinking something like

Chucker.getTransactionList().observe(....)

And it would return a list of either HttpTransaction or HttpTransactionTuple
Once I have some work done on this I will open a PR for feedback!

Thanks @cortinico!

[cortinico]

I don't think there are flows anywhere yet in Chucker, so we could start with LiveData and add flows in the future if needed.

Nope we don't have flow at the moment. I'd go for LiveData at the moment.

Agreed on API surface. I am thinking through the best way to do this in order to expose the least amount as possible.

++

Looping in also @vbuberen as he did the majority of the LiveData rework.

[vbuberen]

As of today I am against implementing such feature in a form of exposing some LiveData or whatever from Chucker internals. With such changes we will seriously limit ourselves as a maintainers due to having to follow the public API contract.
For example, if someone implements something to expose HttpTransaction now we are getting issues with #259 because we already exposed old non-redesigned model.

Also, I believe that for now Chucker should stay the inspector on its own with its data being inside (as it is now) not the provider for some other libs/apps. Despite joining the project pretty recently compared to other core maintainers I feel that Chucker still has to find its proper architecture and approaches to be solid and extendable.

Finally, I believe that this feature request is something that I meant in #329 under 1st class support, because there are no other users asking for that and because it requires some serious rework for any of suggested cases.

[cortinico]

As of today I am against implementing such feature in a form of exposing some
LiveData or whatever from Chucker internals. With such changes we will
seriously limit ourselves as a maintainers due to having to follow the public
API contract.

As I said, I'm also really hesitant on this side. I don't want to waste your time @djrausch so if you can submit a PR it's definitely a plus as we have some discussion material. On the other hand, we could also decide to don't expose this data at all.

As a side note: Chuck used to have a ContentProvider that was removed in #29 due to lack of valid use cases. Now we do have a valid use case + potential user. So I'd love to hear from the community if there is interest in having a mechanisms to expose the library stored database (being it via LiveData or through other system/approaches).

[djrausch]

@vbuberen I think those are all valid points. I am trying to think of a way to expose a bare minimum level of data. I agree that having to keep the API contract can be limiting, but I believe we can find ways around that.

@cortinico I will work on a PR, or document the basic ideas, and share that here.

Random idea I just had, what about exposing a FragmentDialog? This would solve the exposing API issue as well as the API contract as the user still wouldn't have access to the underlying API.

Thanks for all the feedback guys!

[cortinico]

Random idea I just had, what about exposing a FragmentDialog?

Maybe I'm biased on this, but exposing a FragmentDialog feels like opening the pandora box to me. Like once we offer a non structured way to access the data, someone will necessarily ask for a more powerful API to do some filtering or querying of that data.

So to me having a FragmentDialog would solve your specific scenario, but it's not really a general purpose solution (at least from my point of view).

[djrausch]

I agree that it's not general purpose, but it would solve the concerns about the API surface. And yeah, then you'd have someone like me come along and want more data from it 😆

I think the only solution here is having some sort of intermediary class that is exposed. This way the internals can change however you'd like, but convert it back to the public class. If this is something you guys would be interested in, I can begin work on that. If this is something you don't want to do, I understand, and I will just maintain a fork for us to use.

[vbuberen]

Thanks for you suggestions, but for now it is not something that we are interested in. Who knows, maybe we will change our minds soon, but we will definitely ping you.

Also, feel free to suggest other stuff or share what you were able to achieve in your fork. It might be that we are just missing the opportunity and the beauty of things which could be done for this feature request 😉

[djrausch]

Sounds good! Thanks!