I'm using a u2020 like "debug drawer" and I want to add a button to "disable caching". Where would be the best place to do that? Options I'm considering: 1. Interceptor you can enable/disable that will remove the "If-none-match" header from a request (we are using Etags for caching) 2. Just a button that'll clear all cache in cache directory 3. Use

Request.Builder()\ .cacheControl(new CacheControl.Builder().noCache().build())\

but I'm not sure how to best incorp that with retrofit

3 is pretty much the same as 1. You could also do it as a Call.Factory wrapper that added noCache to the request but interceptor is probably easier.

I would go the interceptor route and don't think it particularly matters mechanism you choose. I don't like 2 because it's not disabling caching it's clearing all currently cached items. If that's what you wanted you should rename the button or have a separate one.

Thanks. And I'm assuming that a application interceptor would be the correct choice for approach 1, right? I agree. Writing an interceptor seems to be fairly easy in this case.

I’m seeing

Unresolved reference: okio

Unresolved reference: FileSystem

in a project using okio. The file it points to consists only of the following

import okio.FileSystem

actual val fs: FileSystem = FileSystem.SYSTEM

This works fine for linuxX64, but fails for macosArm64. Is macosArm64 not supported by okio 3.0.0?

It is supported since 3.0.0.

Another Anvil issue. It generated a ComponentImpl for my

@MergeSubcomponent

which has few

@Overrides

from contributed ComponentInterfaces, in stub

.java

files there's an error that this overrides nothing. And in the end-user kotlin code I see an IDE error. But it compiles. I guess this is due to some kotlin plugin magic?

In the build folder

AppComponentAnvilModule.kt

is there but it's just an empty file... but there are files under the

hint

folder...

Update: I found the issue 😅 - https://github.com/square/leakcanary/issues/2280 I updated both MapBox and LeakCanary and started getting this crash on R8 builds: Sorry used old version of retrace and MapBox stuff was squished into the stacktrace. I'm assuming I should just file this on LeakCanary?

Fatal Exception: java.lang.NullPointerException
       at curtains.internal.WindowCallbackWrapper$Companion.getJetpackWrapped(WindowCallbackWrapper.java:112)
       at curtains.internal.WindowCallbackWrapper$Companion.unwrap(WindowCallbackWrapper.java:154)
       at curtains.WindowsKt.getWrappedCallback(Windows.kt:233)
       at leakcanary.RootViewWatcher$listener$1.onRootViewAdded(RootViewWatcher.kt:46)
       at curtains.OnRootViewAddedListener$DefaultImpls.onRootViewsChanged(OnRootViewAddedListener.java:38)
       at leakcanary.RootViewWatcher$listener$1.onRootViewsChanged(RootViewWatcher.kt:43)
       at curtains.internal.RootViewsSpy$delegatingViewList$1.add(RootViewsSpy.java:25)
       at curtains.internal.RootViewsSpy$delegatingViewList$1.add(RootViewsSpy.java:23)
       at curtains.internal.RootViewsSpy$delegatingViewList$1.add$bridge(RootViewsSpy.java:0)
       at android.view.WindowManagerGlobal.addView(WindowManagerGlobal.java:393)
       at android.view.WindowManagerImpl.addView(WindowManagerImpl.java:133)
       at android.app.ActivityThread.handleResumeActivity(ActivityThread.java:4843)
       at android.app.servertransaction.ResumeActivityItem.execute(ResumeActivityItem.java:54)
       at android.app.servertransaction.ActivityTransactionItem.execute(ActivityTransactionItem.java:45)
       at android.app.servertransaction.TransactionExecutor.executeLifecycleState(TransactionExecutor.java:176)
       at android.app.servertransaction.TransactionExecutor.execute(TransactionExecutor.java:97)
       at android.app.ActivityThread$H.handleMessage(ActivityThread.java:2210)
       at android.os.Handler.dispatchMessage(Handler.java:106)
       at android.os.Looper.loopOnce(Looper.java:201)
       at android.os.Looper.loop(Looper.java:288)
       at android.app.ActivityThread.main(ActivityThread.java:7839)
       at java.lang.reflect.Method.invoke(Method.java)
       at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:548)
       at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:1003)

Is this a LeakCanary or MapBox issue?

I’m having issues with the licensee lookup. Could someone take a look what the correct behavior for a library would be to specify it’s license? https://github.com/airbnb/lottie-android/pull/2028#discussion_r817720923 @gpeal thinks this should be supported

commented!

Just a general question about retrofit + coroutine cancellation. I'm basically building a search form where we debounce as the user types by 250ms then we search.

init {
  viewModelScope.launch {
    myState.queryText.debounce(250).collectLatest {
        search(it)
    }
  }
}

private suspend fun search(term: String) {
    val result = service.searchApiCall(term)
...

I'm trying to manually verify that service.searchApiCall is actually cancelled. I'm looking at the requests through charles proxy but it doesn't seem to cancel there. I'm assuming that a cancellation on retrofit can't actually cancel the in flight request right? My networking inexperience is kinda failing me here, but would appreciate any pointers to make sure that Im cancelling correctly.

Cancelation is wired through to OkHttp

I would have to try it. Plus if it's HTTP/2 the response may complete before the server sees the cancel frame for that stream

Use an EventListener on OkHttpClient, it will show if calls are overlapping and also the cancellation in a callFailed event.

From my investigation it looks as though the network call will still complete round trip, come back to the client with a response, but it seems like since it is cancelled properly with my code above. I think okhttp just drops the response.

I think that's likely based on latencies and response sizes. The cancel is sent as a frame, its not a socket disconnect. As Jake says, the server may have sent all the response before it sees the cancel.

You can also enable http2 frame logging https://github.com/square/okhttp/blob/805470e1e6c082ce498211ffbde6d9fe5176302c/docs/contribute/debug_logging.md

With SQLDelight is there an obvious way to update a query result when a table not in the query changes? For instance, if you have a select on table_a that selects rows from table_b in the mapper to generate data like

TableA(id: String, children: List<TableB>)

One option is to have a useless subquery that depends on table B in the select on table A.

I remember (I think at droidcon montreal?) that someone asked jake a question about picasso and image caching, and jake said something along the lines of "image caching should be done by the http client". Does that still hold true today? What prompts me asking is because coil (the image loader) release notes say "You should not use OkHttp's

Cache

with Coil 2.0..."

yes and no

yes, because HTTP caching is ubiquitous and a standard and reimplementing it means you're going to get something wrong and OkHttp has had like 10 years to get it right and if you're already shipping OkHttp's disk cache you might as well use it

but also no, because the only correct cache header to send for images is

immutable

which means you don't gain much from the full HTTP caching spec

i would answer the same today as i did then

Coil has a flag to force that immutable mode.

But the changelog gives some more detail that is relevant. "You should not use OkHttp's Cache with Coil 2.0 as the cache can be corrupted if a thread is interrupted while writing to it."

OkHttp definitely has some bugs when you use interrupts. The safest thing is not to use them.

Coil 2.0 still respects cache headers the same as 1.x. I agree with Jake that ideally OkHttp should own caching, however we need direct file access as some of Android's decoders require `File`s or buffering the whole file into memory which isn't safe (looking at you

ImageDecoder

and

MediaMetadataRetriever

👀). Also there were feature requests to have direct access to the image data on disk.

I might be interpreting jakes message incorrectly. "the only correct cache header to send for images is

immutable

" and "seems like they're simply ignoring HTTP cache headers entirely and assuming everything can be cached forever. not sure that's a smart idea." seem at odds with each other? Or are you basically saying jake that images should be immutable, but its not a good idea (for an image loading library) to assume that every image will be?

for what its worth. after jakes and jesses talks from multiple droidcons. we basically use thumbor and "good enough caching™️" with

Cache-Control: max-age=31536000

So I think using coil 2.0 won't really do any harm. but yeah. ive always tried to leave caching to the http client and just thought this was an interesting callout that coil was moving away from it.