https://kotlinlang.org logo
#apollo-kotlin
Title
# apollo-kotlin
s

Stylianos Gakis

08/22/2022, 8:57 PM
Interested to hear how you’d suggest improving the case where I’m relying on
watch()
for some query and how I’d handle error cases within it, more in thread 🧵
So at a screen, I was simply doing
.watch()
on a Query in order to update the UI. This came with the problem where if there is no internet, and nothing is cached, and I did not pass
fetchThrows = true
, the watch would simply not return anything and since no value would even come it’d be stuck loading and no information on the no internet access error would surface on the UI. Then I thought of adding
fetchThrows = true
to error on the first fetch if it fails (and not
refetchThrows = true
since at that point I can rely on the cache) so that I show the error screen to help them understand that something went wrong instead of showing an infinite loading screen. Now this comes with the problem that since the watch threw, the flow is cancelled and I’d then need something to re-start this watch on a retry button click or something like that. But then I need some functionality to do this retrying the watch from start again, which is what I’ve done now and it works. But I’m thinking, am I missing something better I could be doing here with the .watch APIs? Something I’m misusing by some chance?
b

bod

08/23/2022, 8:50 AM
have you tried playing with the "other"
watch
? The one that takes a
D?
and a
retryWhen
lambda
this could allow you to decorrelate querying and watching
(a bit more meta: we're thinking of not throwing in Flows in a future version of the lib, and instead expose an exception in
ApolloResponse
which would simplify this usecase - more info in this issue)
s

Stylianos Gakis

08/29/2022, 7:39 AM
Sorry for the late reply, got caught up with other stuff, and no I haven’t quite played with the other
watch
signature since I don’t think I quite get it tbh. I guess how it’d work is that instead I’d do a normal query, get that result and do what I want with the error case, and in case of a successful response I then take that data and feed it into the
.watch
data
parameter? I read that issue and yeah sounds interesting to see what approach you’ll go with after all. I’ll keep an eye on it to make sure I am up to date with this decision 😅
18 Views