Or is that just a matter of using blocking APIs of Retrofit (as opposed to

suspend

functions I currently have)?

Thanks, using

Call

and

execute()

instead of coroutines on my inner request fixed the issue.

#Molecule #Paging-compose Hello people, I promised myself to explore Molecule, but never had a chance. I’m integrating Paging in my Compose project, and what I hate most is the fact that your paged items cannot be part of the State, as you need to collect the paged Flow from Compose I was wondering if Molecule can solve this, as I imagine I could do the following:

class MyViewModel {

  val state = launchModulecule {
    val lazyPagingItems = pagedFlow.collectAsLazyPagingItems()
    MyState(
      items = lazyPagingItems,
      stuff = someStuff
    )
  }
}

Is this correct?

It's not obvious to me why that doesn't work. Have you got a minimal reproducible example to checkout?

[KotlinPoet] Is it possible to add explicit wildstar imports to a generated file? I'm working with c imports and have no way to distinguish where a known type comes from, but I know that one of the given packages will have it.

I got a requirement to be able to retry a failed 500 network call up to 5 times (with a 5 second delay). I know that a network interceptor will be my friend here, but is the retry count something that I should just try to persist somewhere, or is there someway to know that I'm retrying the same request without having to create some sort of singleton or something? It also seems like okhttp might retry on my behalf anyway. Is there a way to disable that so I can follow my retry specs directly?

Is there any support in SQLDelight for writing cross-db queries? i.e. ATTACH a second database, and then write a query that references a table there? I've tried to test it but the compilation immediately fails with

No table found with name

which would imply this is not supported

Unfortunately, this is not yet supported, see https://github.com/cashapp/sqldelight/issues/3761 and requires full qualified table names.

I see, thanks! Out of curiosity is support for this planned?

Is layoutlib updated according to any schedule in Paparazzi, or is it need based? Looks like an updated layoutlib will be needed to support androidx.core 10 (currently in RC) https://github.com/cashapp/paparazzi/issues/706

Hello. For some time i wanted to migrate from Room to SqlDelight, but unfortunately i cannot do a full migration because the db is too large. Is there any recommended pathway to partial migrations over time?

#SqlDelight #SqlLite3-35 #Type Hello people. I have the following View:

CREATE VIEW IF NOT EXISTS screenplay AS
    SELECT
        movie.tmdbId AS movieTmdbId,
        NULL AS tvShowTmdbId,
        ...
    FROM movie
    UNION ALL
    SELECT
        NULL AS movieTmdbId,
        tvShow.tmdbId AS tvShowTmdbId,
        ...
    FROM tvShow;

where

movieTmdbId

and

tvShowTmdbId

are of types

sealed interface ScreenplayTmdbId 
value class MovieTmdbId : ScreenplayTmdbId
value class TvShowTmdbId: ScreenplayTmdbId

I would like to query a single row by id. It would be awesome if SqlDelight could infer the super-type

ScreenplayTmdbId

, but I see that’s not happening, as the following resolves

tmdbId

as String

WHERE IFNULL(movieTmdbId, tvShowTmdbId) == :tmdbId;

I tried then to separate into two separate queries, but, somehow, the first of the following queries compiles, while the second one doesn’t

findByMovieId:
    SELECT
        movieTmdbId,
        tvShowTmdbId,
        ...
    FROM screenplay
    WHERE movieTmdbId == :tmdbId;

findByTvShowId:
    SELECT
        movieTmdbId,
        tvShowTmdbId,
        ...
    FROM screenplay
    WHERE tvShowTmdbId == :tmdbId;

Caused by: java.lang.IllegalArgumentException: Cannot bind unknown types or null

I’m pretty sure I’m doing something wrong

Does the multiplatform okio support encryption at all?

Okio multiplatform does not support encryption. Things like compression and encryption rely on JDK APIs. The only thing tangentially related that is supported is hashing.

I’ve got signing code in Zipline that might be helpful if you’re looking for a sample: https://github.com/cashapp/zipline/blob/trunk/zipline-loader/src/nativeMain/kotlin/app/cash/zipline/loader/internal/EcdsaP256.kt

I’m using cashapp/copper to observe content provider changes. I noticed that it’s taking about ~10 seconds for App B to observe a change occurring in App A. This is a little OT, it’s not a Copper issue, but rather a content provider one - and I think it maybe relates to the API level.. I’ll get stuck with a :not-kotlin: if I ask anywhere else 😓 But I figured someone who wrote Copper might be familiar with the Content Provider APIs

I assume this is Android throttling wakeups to avoid a thundering herd problem. There have been a lot of changes here in the last 5 years.

We use it to observe the contact database and the code has basically been unchanged since... like 7 years ago? maybe more?

We also are not sensitive to latency. We don't know (or care) whether an update is instant or happens a minute later.

Interestingly, a content observer in the same process observes changes immediately. I don’t really have any concept of how content changes are actually passed between processes by the system

And this isn’t a super important issue, latency here isn’t a big deal. Just curious about it. It’s consistently about 10 seconds to notice a change

Oh, and good point! I didn’t realise how long Copper has been around 😅

It was part of SQLBrite before. It got spun out when we archived the SQLBrite project.

Oh right. Yeah I used to use SqlBrite back in the day. And now SqlDelight

if you scroll through the developer changes section of the Android releases of the last 5 years I bet you can find something about cross-process notifications being throttled

No worries, thanks!

I quickly got tired of trying to find an answer in the docs, so I asked ChatGPT:

Content observers, which allow apps to listen for changes in data in a content provider, are also affected by the changes in Android’s background processing restrictions.

Starting with Android 9 (API level 28), the system limits the frequency at which content observers receive notifications about changes in data. Specifically, content observers are now subject to the same background processing restrictions as other types of services and apps.

I’m just answering my own question here in case anyone else is interested. But, I’m guessing part of the problem, is I’m leaving the observer app (App B), to make a change in the producer app (App A). So the change is made while App B is in the background. Then I return to App B, and it takes ~10 seconds. Maybe if App B was in the foreground when the change occurred, the delay would be smaller. In any case, if I need a more immediate answer, I could just execute the query in

onResume()

or something.

try split screen? at least to test your theory