wanna send a PR?

I can try!

I've got a couple of other PRs floating around but I'd like to contribute after those are done.

How can I store the SQLDelight database in an iOS app group? I would like to use the database from an iOS app extension. An app extension cannot access the files of the “normal” app so you need to use app groups. I cannot find a way to configure this in SQLDelight. Is this possible?

Not familiar with app groups but can you get a filepath to one?

There should be an option on the NativeSqliteDriver for specifying a filepath

Yes, I can get a file URL for the app group so I could use that. Just found out about

basePath

which looks like the way to go. Appreciate your help!

Could there be an SQLDelight pre-release for Kotlin 1.3.70 eap, please? I am trying to compile it myself and its dependencies, but I am having some issues getting SQLiter compiled on my Mac.

do our dependencies with native have eap releases? we'd be blocked on them

Unfortunately not

yeah this situation is painful for everyone

its going to be painful until the portable lib format

i dont think it makes sense to do anything about it right now

Hi! I just upgraded to Moshi 1.9.2 and I have the following data class:

@JsonClass(generateAdapter = true)
data class ApplicationGroup(
    val id: Int,
    val header: String,
    val subHeader: String = ""
)

but I'm getting this error:

java.lang.NoSuchMethodException: parameter type is null
        at java.lang.Class.getConstructor(Class.java:526)
        at java.lang.Class.getDeclaredConstructor(Class.java:510)
        at com.....ApplicationGroupJsonAdapter.fromJson(ApplicationGroupJsonAdapter.kt:62)
        at com.....ApplicationGroupJsonAdapter.fromJson(ApplicationGroupJsonAdapter.kt:19)
        at com.squareup.moshi.u.b.fromJson(NullSafeJsonAdapter.java:40)
        at com.squareup.moshi.d.fromJson(CollectionJsonAdapter.java:76)
        at com.squareup.moshi.d$b.fromJson(CollectionJsonAdapter.java:53)
        at com.squareup.moshi.u.b.fromJson(NullSafeJsonAdapter.java:40)
        at com.squareup.moshi.f$c.fromJson(JsonAdapter.java:197)

what could be causing this?

yeah Moshi needs a release

Talking about moshi anything blocking https://github.com/square/moshi/pull/1080 ?

no, it just needs review

Hello. I would like to create a converter for retrofit, something that handles 'Response.EMPTY' for cases when the server returns 204

at the moment, it's crashing with: 'kotlin.KotlinNullPointerException: Response from com..xx was null but response body type was declared as non-null'

does any1 point me out to the right direction please?

This call is giving me that error

suspend fun someApiCall(): Unit

Converters are not called for 204 or 205

There is an issue tracking the behavior and to provide converter hooks

ok. thanks you for the info:P Is there any quick workaround i could use, besides Response<Unit> ?

You could write an interceptor to change the status back to 200

Don't mean to get this conversation started again as it seems like null values overriding default values in Kotlin has pretty much been decided that Moshi will stick with that behavior, but is there any chance to get a config/builder option to opt out of that behavior? Pretty much this ticket https://github.com/square/moshi/issues/843 I've got a huge project that is migrating from gson to moshi and this is now becoming an issue, but we don't really want to update like 100+ response models so we're looking for an answer that's a much lower surface area. The potential solution provided by Zac seemed promising, but we didn't want to annotate every object so we removed that requirement and I posted this question https://stackoverflow.com/questions/60377758/moshi-factory-to-ignore-null-values-and-use-kotlin-default-value-when-deserializ and it all worked pretty smoothly until we noticed that with that adapter, our Numbers in Json became doubles (makes sense) but then our adapter down the line converted some cases to a string, and so we ended up with time stamps that looked like "1.5836742E12" instead of "1583674200000". So this takes me back to the original question... is there any chance to get a config/builder option to opt out of the "nulls will override default value" behavior?

You could write an adapter that skips nulls for everything, no annotation

That's what I "tried" writing here: Adapter that filters nulls for everything. It just modified Zacs answer in the github link above: https://stackoverflow.com/questions/60377758/moshi-factory-to-ignore-null-values-and-use-kotlin-default-value-when-deserializ

class DefaultIfNullFactory : JsonAdapter.Factory {
    override fun create(type: Type, annotations: MutableSet<out Annotation>,
                        moshi: Moshi): JsonAdapter<*>? {
        val delegate = moshi.nextAdapter<Any>(this, type, annotations)
        return object : JsonAdapter<Any>() {
            override fun fromJson(reader: JsonReader): Any? {
                    val blob1 = reader.readJsonValue()
                try {
                    val blob = blob1 as Map<String, Any?>
                    val noNulls = blob.filterValues { it != null }
                    return delegate.fromJsonValue(noNulls)
                } catch (e: Exception) {
                    return delegate.fromJsonValue(blob1)
                }
            }
            override fun toJson(writer: JsonWriter, value: Any?) {
                return delegate.toJson(writer, value)
            }
        }
    }
}

Which actually seems to work great (not a fan of the try statement), but it still has that interesting issue where while it filters out nulls, it turns Json numbers in Java doubles, and so when

1583674200000

comes in over the wire, my data class has

timestamp: String

and so the end result is "1.5836742E12" instead of "1583674200000". So it "appears" that it doesn't work. Unless there's some other way to filter nulls besides Zacs advice of reading jsonValue as map, filter nulls, pass it along the chain.

you can't always assume the json value is a map

aside from that i would have to experiment with it, but nothing should prevent it from working