I haven't used this for multiplatform modules before so ymmv

This snapshot version handling is very weird with multiplatform modules, because it results into different versions for "the same" artifacts. So you can't use one version in

commonMain

, but need to use different versions for each artifact.

yea I imagine that'd be difficult to setup

Is there a plan for kotlin-multiplatform

moshi

?🙋‍♂️ https://github.com/square/moshi/issues/1252

you've found the plan. there is no real timeline, if that's what you're asking.

Converting Java Type to all KTypes?

Does Redwood provide a similar API as Compose UI which uses the Compose UI equivalent on Android, and emits Swift UI on iOS, or is it an entirely different API?

It's a bit complicated, but basically you are required to define the entire UI API yourself, usually by mapping out the requirements of your specific design system. It is absolutely NOT a general purpose system or a turn-key library that you can drop in and go. There is significant upfront work to build out a type safe schema for your design system from which things like the composable functions are generated.

Currently we do not use Compose UI. We use our existing android.widget-based views on Android and our existing UIKit views on iOS.

Interesting! So you define the schema in terms of design system components, or it's lower/higher level than that? Is the snapshot system used as part of your definition, or is that part generic?

You choose the level of abstraction. The library doesn't care. And it's probably what we've spent the most time debating. There's no one right answer. Snapshots work like normal. Other than using our composables it's otherwise nearly exactly the same as writing for Compose UI today.

For snapshots I meant in terms of how the state gets wired up to the android.widget/UIKit views

Is it possible to know if

MockWebServer

is

started

?

Hey, is there any possibility to use raw queries with SQLDelight? I want to use the

Copy from stdin

function to import many csv files.

Or can you create a query with

varargs

to prevent useless transactions?

insert:
INSERT INTO foo VALUES ?;

You can do raw queries by talking to the driver directly. You cannot use varags and should wrap multiple inserts in a transaction yourself.

If I want to add a custom SQL type to SQLDelight, I have to include the changes in sql-psi as well as in the runtime? I want to provide an UUID support for MySQL, mapping to ByteArray in runtime.

Correct, psi is the place for grammar changes and mapping it to a Kotlin type is SQLDelight

Is there a good cross platform way with SQLDelight to gracefully handle a failed migration? Like just wipe everything and start fresh

you could try/catch, query all tables, drop them, and then create fresh schema

if the db is file-based you could close it, delete the file, and re-open (forcing file creation and schema creation)

nothing turn-key though

Ok, I'll try that out. Thanks

After upgrading to Kotlin 1.6.0, I'm getting:

Caused by: java.lang.IllegalStateException: Could not parse metadata! This should only happen if you're using Kotlin <1.1.
	at com.squareup.moshi.kotlinpoet.metadata.KotlinPoetMetadata.readKotlinClassMetadata(KotlinPoetMetadata.kt:89)
	at com.squareup.moshi.kotlinpoet.metadata.KotlinPoetMetadata.toImmutableKmClass(KotlinPoetMetadata.kt:119)
	at com.squareup.moshi.kotlin.codegen.MoshiCachedClassInspector.toImmutableKmClass(MoshiCachedClassInspector.kt:37)
	at com.squareup.moshi.kotlin.codegen.MetadataKt.targetType(metadata.kt:139)
	at com.squareup.moshi.kotlin.codegen.JsonClassCodegenProcessor.adapterGenerator(JsonClassCodegenProcessor.kt:148)
	at com.squareup.moshi.kotlin.codegen.JsonClassCodegenProcessor.process(JsonClassCodegenProcessor.kt:114)
	at org.jetbrains.kotlin.kapt3.base.incremental.IncrementalProcessor.process(incrementalProcessors.kt:90)
	at org.jetbrains.kotlin.kapt3.base.ProcessorWrapper.process(annotationProcessing.kt:188)
	at jdk.compiler/com.sun.tools.javac.processing.JavacProcessingEnvironment.callProcessor(JavacProcessingEnvironment.java:980)

I'm using Moshi 1.12.0, is this a known issue?

Ok, I found this: https://github.com/square/moshi/issues/1368 ... but the only workaround is to compile Moshi ourselves? 🤕 😞

We haven’t updated KotlinPoet to 1.6 yet but we will, now that it’s released

And that will solve the problem @egorand? There's really nothing to do meanwhile but downgrade to 1.5.31? And is there an ETA for such a release? Thanks!

Haven’t looked into the problem yet, just looking at the stacktrace it seems that the metadata changed in a way that we can’t parse, so once we update to 1.6 we should be able to fix the issue. No ETA.

Oh well, I guess back to 1.5.31 for now then...

Snapshot versions of Moshi works, fix does not seems related to KotlinPoet so maybe a Moshi release will happen before.