I might be just missing something but I don't see a way to log network traffic with Apollo multiplat...

# apollo-kotlin

[Filip Wiesner]

I might be just missing something but I don't see a way to log network traffic with Apollo multiplatform. It's pretty easy with access to OkHttp interceptor but I don't think I am able to do that from common code.

[mbonnin]

Yea, not much. Is this for debug or something else?

[mbonnin]

You can use expect /`actual` if needed . The JVM ApolloHttpNetworkTransport takes a OkHttpClient so you can use interceptors there. And on iOS, it takes a DataTaskFactory where you can intercept requests if needed

[Filip Wiesner]

Yeah, for debug. I am used to using Flipper with OkHttp.

You mean making my own NetworkTransport copying the Apollo code and adding my interceptor? Or what do you mean by "_use expect /`actual` if needed_".

[mbonnin]

You could have a

expect CustomNetworkTransport

that delegates to ApolloHttpNetworkTransport

[mbonnin]

It's going to be more boiler plate but it should work

[mbonnin]

Also, is there's something like Flipper on iOS? Or are you looking at replacing Flipper with stdout ?

[Filip Wiesner]

I am not iOS dev so I am not sure 😅 I think there is Atlantis for iOS but I don't know anything about it.

[mbonnin]

If you're in JVM code, there's a ApolloHttpNetworkTransport constructor that takes a CallFactory : https://github.com/apollographql/apollo-android/blob/49d4768dc381f51acc38256d28a9d[…]apollographql/apollo/network/http/ApolloHttpNetworkTransport.kt

[mbonnin]

OkHttpClient implements Call.Factory so you can customize the OkHttpClient before creating the ApolloHttpClient before passing it to the ApolloClient

[mbonnin]

Something like

val client = ApolloClient(
  networkTransport = ApolloHttpNetworkTransport(
    serverUrl = "https://",
    headers = Headers.of(emptyMap()),
    httpCallFactory = OkHttpClient.Builder()
         .addInterceptor(...)
         .build() 
  )
)

[mbonnin]

Of course that doesn't work on ios

[Filip Wiesner]

I see what you mean. I'll just have to bend it a bit to make it work. Thanks a lot 👌

One more unrelated question when I am talking to you. Would you consider adding tvOS target? From what I've seen you would "only" need tvOS added to Okio lib (there is already issue for it) and than it's just adding the build target.

[mbonnin]

Yep, it's most likely "just" one target to add 🤞

[mbonnin]

Feel free to open an issue so we can track this

[Filip Wiesner]

Yeah, we (with a colleague) wanted to make issue when the Okio is ready but I can do it now if you want to. We need it now so we've forked it and made it work and it's not hard (so far.. 😅 ). Only the Okio is the problem so we needed to fork it too.

[mbonnin]

Yep, dependencies all the way down 😅

[mbonnin]

Opening an issue is always good, maybe someone else will need it and having the context and the link to the okio issue will help

[Filip Wiesner]

Sure, I'll create it now. Thanks again 👍 I am glad I discovered that you have this Slack channel.

[mbonnin]

Sure thing! Thanks for looking into tvos !

[Filip Wiesner]

The issue: https://github.com/apollographql/apollo-android/issues/3101

[mbonnin]

A separate issue about logging for MPP if you want to subscribe: https://github.com/apollographql/apollo-android/issues/3107

[Filip Wiesner]

Nice, thank you 🙌

[Filip Wiesner]

The Okio issue has been closed and tvOS target added. Can we expect Apollo to add tvOS target now as well?
@mbonnin

[Filip Wiesner]

Ooops, I see you already know about this and and liked the tvOS pull request. Sorry for the ping

[mbonnin]

@Filip Wiesner the problem is we need a released okio with tvos before we can release apollo

[Filip Wiesner]

Yeah, sorry. I messaged too fast 😄 It's in master branch and now we just have to wait

[mbonnin]

Yep, everything has to propagate one after the other