I tried:

companion object : JsonAdapter.Factory {
		override fun create(type: Type, annotations: MutableSet<out Annotation>, moshi: Moshi): JsonAdapter<*>? =
				PaymentResultAdapter(PaymentResult_SuccessJsonAdapter(moshi))
	}
}

But then I need to implement JsonAdapter...

There's better ways to do all of this. You shouldn't be using a regex to pull out a value for a key.

I'm mobile though so I can't type it all out

So I should really be using JsonReader/Writer? Maybe you could just point me to the right direction? Thanks for all the trouble 😊!

I've used JsonReader before, but to avoid consuming the json (in case I need Moshi to parse the Success) I'd have to have a copy of the buffer to consume @jw ? Or am I missing some other feature here?

You can use

peek()

to not consume

vaguely related to my earlier question: Is there a reason on Android

executeAsList

seems to be returning things synchronously vs needing to add completion closures in this data wrapper for iOS: https://github.com/square/sqldelight/blob/master/sample/common/src/iosMain/kotlin/com/example/sqldelight/hockey/ui/PlayerData.kt

Yeah that code looks weird. I mean it's still synchronous in both cases, but i'm not sure why that pattern is being used

@kpgalligan? ¯\_(ツ)_/¯

My guess is something something Freezing given my experience working on native stuff the last few weeks, but that’s just a guess 🍧

Can you expand on the question? Are you asking about updateNotifier? I’ll assume that’s the question and expand…

I had originally gotten a bit too excited about “common code” in the sample and pushed the common code higher into the UI. After the first PR, I pulled that structure largely out but some of that persists in the iOS side.

PlayerCell interface, etc

Remembering what I was thinking. Was also thinking we should hook up a listener to the DB, but all plans just kind of stopped at “it works”. You can simply pull the list from the query to swift and dump all of that.

However, the sample makes no attempt at getting off the main thread, and for native, none of this is related to freezing.

Just FYI

The completion closure was a pattern copied from other samples to tell the UI to refresh, basically, which would’ve meant listening to the db, which we’re not.

If I need to convert to objects a Okio 2 source using Moshi, but if there's an error, I'd like to be able to log it... this is what I have (but it looks like

peek

is not really made for this...:

override suspend fun convertForReceive(context: PipelineContext<ApplicationReceiveRequest, ApplicationCall>): Any? = withContext(
		<http://Dispatchers.IO|Dispatchers.IO>) {
		val request = context.subject
		val channel = request.value as? ByteReadChannel ?: return@withContext null
		val reader = channel.toInputStream().source().buffer()
		val buffer2 = reader.peek()
		val type = request.type

		return@withContext moshi.adapter<Any>(type.java).runCatching {
			fromJson(reader)
		}.onFailure {
			logger.error(it) { "Error converting request body <${type.simpleName}>: ${buffer2.readUtf8()}" }
		}.getOrThrow()
	}

(From Ktor ContentNegotiation)...

What's the best construct to use for this purpose?

you have them backwards

you need to read from the peek and then consume from the original in the error message

you also probably should consume the original source if the peek is successfully read

right now you're trying to use peek as a look-behind buffer and it's actually a look-ahead source

It felt a bit funny to peek for the json transformation, and then consume the original for the error just-in-case the transformation didn't work... if it did work, I'd have to consume both the original AND have peeked at the copy 🙈.

That's why I wondered if there's maybe a better construct for this...

not really if you want to read twice while still streaming

I just need to aggregate the current string read before Moshi's parsing crashed (and maybe a little bit more), to be able to have a good error report without flooding my server logs.

A bit like the HashSink's no?

They also do processing during the main reading of the buffer, and give a result afterwards.