https://kotlinlang.org logo
#confetti
Title
# confetti
y

yschimke

11/20/2023, 8:12 AM
@mbonnin I wanted some advice on how to wire up Apollo ExecutionContext and use them internally.
Basically I want to ensure we do the right things on Wear, based on the request and network types.
So make images optional (Coil), or only perform an API request if it's the first request (not a refresh) or we have Bluetooth connection
I don't think I can do this currently with Apollo
I have all the OkHttp plumbing in place to choose the right network, and whether to fail it immediately.
But I need to choose an approach for Apollo
1. Just avoid making the call based on the network and cache state, and hope it will use the network. This unfortunately muddies up the app code, and probably means this code on Wear differs from mobile.
2. Find out how to get some indication of the Cache status, or current Fetch policy, at the OkHttp layer? Seems too much logic needs to be built into Apollo
3. Have a way to pass ExecutionContext through to OkHttp Request. Then set this when making the call.
m

mbonnin

11/20/2023, 9:15 AM
Indeed the
ExecutionContext
isn't passed to the
HttpEngine
. We've had this issue previously and workarounded with HTTP headers that we would filter out before sending them
y

yschimke

11/20/2023, 9:16 AM
Good idea
m

mbonnin

11/20/2023, 9:17 AM
Let me know how that works, I'll also tinker with passing the
ExecutionContext
all the way through, that might come in handy
y

yschimke

11/20/2023, 9:18 AM
The aim is to express the difference between, user clicking login or bookmark which should wake up network
And optimistically refreshing cached content just in case which shouldnt
m

mbonnin

11/20/2023, 9:19 AM
What if refreshing cached content and that reaches OkHttp? That would be an error, right?
(I guess I'm still trying to figure out what's wrong with your 1. solution above)
y

yschimke

11/20/2023, 9:21 AM
Network situation may change in between
m

mbonnin

11/20/2023, 9:22 AM
I think I got it • Login => Bookmarks => NetworkOnly • Refreshing Cache Content => CacheAndNetwork (but not wake up network)
y

yschimke

11/20/2023, 9:22 AM
I'd like a solution that can guarantee a setting like "use LTE"
👍 1
Yep
m

mbonnin

11/20/2023, 9:23 AM
Makes sense 👍
y

yschimke

11/20/2023, 9:28 AM
Does the cache status get computer anywhere? Or I should split the CacheAndNetwork into separate calls?
m

mbonnin

11/20/2023, 9:44 AM
You mean is the network call aware of a previous cache attempt (and whether it's a cache hit)? I don't think that's the case
I'll also tinker with passing the
ExecutionContext
all the way through,
This is what I came up with. Let me know what you think https://github.com/apollographql/apollo-kotlin/pull/5383
y

yschimke

11/20/2023, 11:06 PM
Yeah, I think so. Would need to try. Is there an alpha phase where it's usable but not fixed permanently?
m

mbonnin

11/20/2023, 11:07 PM
It's published to SNAPSHOTs after the merge
y

yschimke

11/20/2023, 11:07 PM
API wise, I guess I'd wonder about extending Vs some extension point where the default is an identity impl.
But that's your call. This looks like what I need
m

mbonnin

11/20/2023, 11:10 PM
I contemplated
DefaultHttpEngine(callFactory, configure: (apollographql.Request, okhttp3.Request.Builder) -> Unit)
for a while but was a bit afraid this would be limited and felt a bit out of place
👍 1
I'll merge so you can try the SNAPSHOTs. The whole v4 is still beta as well so we can still change things
👍 1
y

yschimke

11/21/2023, 6:09 AM
nit: Once the snapshot is available it should resolve itself. But copying code it appears UploadsHttpBody is ApolloInternal
m

mbonnin

11/21/2023, 9:02 AM
I've relaunched the deploy, it worked this time. Re: UploadsHttpBody, I'd rather keep it ApolloInternal for now. GraphQL uploads have never been specified and have possible security issues so they'll probably become deprecated at some point
👍 1