lateinit property context has not been initialized #5760
Comments
|
I tested with 4.0.0-beta.4 and the bug isn't happening |
|
Hi 👋 Thanks for sending this and apologies about the crash. I'm assuming this is happening during unit tests? The tldr; is that
In order to simplify the setup it uses A preliminary fix is here. It should fix your immediate issue. Until the next release, you can workaround by setting up a val noOpNetworkMonitor = object: NetworkMonitor {
override val isOnline: Boolean
get() = true
override suspend fun waitForNetwork() {}
override fun close() {}
}
val apolloClient = ApolloClient.Builder()
.serverUrl("https://...")
.networkMonitor(noOpNetworkMonitor)
.build()Edit: another workaround is to depend on I'm also wondering if it would make sense to make this behaviour opt-in instead. It's more setup work but at least it's explicit. Any thoughts? |
martinbonnin
changed the title
|
But in that case the network is available, it doesn't make sense that it crash. I don't need androidx.startup so I don't add it as dependency. The code isn't running in a test environment, it is running on a device with access to network. My application doesn't except the network to be available and I don't see the point to do more requests to get the same things that's not really environmental friendly... I would scrap that feature as your goal should be to be as efficient as possible Your fix worked with |
|
To be 100% clear, no extra request is being done by default. The retry mechanism I was mentioning is 100% opt-in and I expect most usages to be for subscriptions: val apolloClient = ApolloClient.Builder()
.retryOnError { it.operation is Subscription }
.serverUrl("...")
.build()It crashes in your case because I'd say being network state aware can be more efficient as it reduces latency and can also reduce extra calls to the networking hardware (no need to try a call if we know in advance it's going to fail). All in all, I'd keep the feature but agree with you the |
|
PR to make Let me know what you think! |
|
I still find annoying that this functionality is on the core of apollo, I would have put it on a separate module that users can add if they want Have you checked how the android connectivity manager knows that internet is available? |
Can you elaborate what the concerns are? Is it APK size? External dependencies? Something else?
I didn't dig there and TBH I expect the details to be pretty complicated. Answering the question of "do I have network connectivity?" is probably one of the most difficult questions in the universe 😅 |
|
My concerns is that feature is very dodgy and you probably don't want to have the apollo core to become dodgy Well last time I check the connectivity manager was doing a network request to google.com to check if internet is available. That means that if for whatever reason google.com isn't available well your app doesn't work... |
|
Hi! If by dodgy you mean not well defined, I agree detecting network connectivity is not an easy problem. But it's an important one, especially for realtime and subscriptions use cases and having one option is better than none. If by dodgy you mean there are privacy issues, I'm happy to revisit with more specifics and/or describe the tradeoff more explicitly in the docs.
To be clear, for this scenario to happen, the user would have to opt-in twice :
I'll add more language to the KDoc but overall I think this is OK. No additional dependency is added. If you're building an Android App, the I'll close this for now. If you or anyone else have more specifics (a link or article would be great) then please comment below and I'll reopen. |
Version
v4.0.0-beta.5
Summary
It started happening on v4.0.0-beta.5 previously, I was on v4.0.0-beta.2 without issues
Steps to reproduce the behavior
No response
Logs
The text was updated successfully, but these errors were encountered: