CoroutineCallAdapterFactory

is not a thing

Take a look at how the polymorphic adapter is implemented in the repo

Thanks! It's a bit longer than what I had before... but I guess it's probably better. I still wonder if there might not be a use case for a Factory on what I mentioned before...

Hi - I’ve run into this issue with SQLDelight: https://github.com/square/sqldelight/issues/1260 and I’m a bit confused about how to work around it to get the code to be added to the

commonMain

module instead of the

iosMain

module. Does anyone more details on how I can get that to work?

In Moshi, is

KotlinJsonAdapterFactory

needed for Kotlin CodeGen, or is it only used for reflection mode?

So, I can refactor that sample and just pull it out. @Ellen Shapiro, safely ignore that and just pull the list directly into Swift, but you’ll want to figure out a concurrency plan for real apps, obviously. That will likely involve freezing, although the data itself may not need to be.

Is there any problem with this Moshi Adapter, it doesn't seem like Moshi is using it at all...

class IdAdapter {
	private val logger = KotlinLogging.logger {}

	@FromJson
	@OdooIdentityId
	fun fromJson(value: Any): Int? = when (value) {
		is Boolean -> null
		is Double -> value.toString().toInt()
		is Int -> value
		is ArrayList<*> -> checkArrayValue(value.first()!!)
		else -> throw IllegalStateException("Non-object-non-boolean value for @OdooIdentityId field $value")
	}

	@ToJson
	fun toJson(@OdooIdentityId value: Int?): String = TODO()

	private fun checkArrayValue(value: Any): Int? = when(value) {
		is Boolean -> null
		is Double -> value.toInt()
		is Int -> value
		else -> error("Invalid Odoo identity $value")
	}
}

I like the idea of it generating code based on queries - are there other libraries that do that?

Yes. There's an Rx extension

I mean like \xxxx unicode codepoints for all non-ascii characters... in old Android devices, it seems like SharedPreferences can't take those chars, so I need my api (using Moshi) to send these as escaped strings.

If you run into anything I can try to help out here

Can anyone shed some light on why the `asFlow`extension for SQLDelite is written using a channel? I understand how it works, but I feel like I'm missing the reasoning for why we need a channel.

fun <T : Any> Query<T>.asFlow(): Flow<Query<T>> = flow {
  val channel = Channel<Unit>(CONFLATED)
  val listener = object : Query.Listener {
    override fun queryResultsChanged() {
      channel.offer(Unit)
    }
  }
  addListener(listener)
  try {
    emit(this@asFlow)
    for (item in channel) {
      emit(this@asFlow)
    }
  } finally {
    removeListener(listener)
  }
}


// why do we need the Channel?
fun <T : Any> Query.asFlow(): Flow<Query<T>> = flow {
  val listener = object : Query.Listener {
    override fun queryResultsChanges() {
      emit(this@asFlow)
    }
  }

  addListener(listener)
  try {
    emit(this@asFlow)
  } finally {
    removeListener(listener)
  }
}

So, I’m writing an Android app in Kotlin currently using Room for SQLite. At some point in the future I want to use as much of the Kotlin code as possible in an iOS version. So I’m considering migrating from Room to SQLDelight. Is this a no-brainer? Is there any reason why I should stick with Room for now (perhaps wait and see how the landscape changes in the next 6 months) or is it a case of sooner-the-better? #room

What's the difference between java and javaObjectType on KClass? I need to use this type for getting Moshi's converter, is there any preference? Like

moshi.adapter<Any>(type.javaObjectType)

.

if the provided Moshi PG or R8 configuration file isn't working, probably report on the GH issue tracker

did you turn that flag off

it depends on what you're using the data for. SQLDelight is purposely trying to incentivize not doing SELECT * everywhere and especially not SELECT * FROM x JOIN y If you really need all the columns from both tables for every single row, then definitely do a single query. If you're just trying to get table types back from sqldelight ( 😞 ) then use 2 separate queries

Hi! Can anyone help me an diagnose sqldeligt issue? I have

CREATE VIEW series_full AS
SELECT series.id, series.name
FROM series
JOIN series_category ON series_category.id = series.id
ORDER BY rowid ASC;

find_one_by_id:
SELECT *
FROM series_full
WHERE id = ?;

I get an exception:

SQLiteException: no such table: series_full (code 1): , while compiling: SELECT * FROM series_full  WHERE id = ?1

Is there any reason why Kotshi is still being managed even though Moshi already has Kotlin Codegen? If so, shouldn't they just be merged or something?

In SQLDelight, what is the best way to use PRAGMA in multiplatform project? Extending

SqlDrive.Schema

and manually execute PRAGMA statement in

create

function? I found this issue(https://github.com/square/sqldelight/issues/1241 ), but it does not cover multiplatform.

With Retrofit 2.6.0, I still get

kotlin.KotlinNullPointerException: Response from xxx was null but response body type was declared as non-null

, including after moving to

suspend fun

. What may cause

Unit

to be improperly handled even though it's advertised as supported?

not sure where else to report: the sqldelight idea plugin seems to be giving me trouble: https://gist.github.com/NikkyAI/14ac1a5cee780561c0270f98e68db1e3

@jw Can I specify

BufferedSource

as a return type of retrofit interface function?

I've been experimenting SQLDelight's new FlowExtensions in Kotlin/Native, and it turned out not working as

offer

is called directly inside frozen

Query.Listener

.

If that doesn't work try src/main/sqldelight

@hmole

call.execute()

is bad idea, it make request non cancellable, better to use call.await() without any additional async wrappers. And if someone really want to share threads between coroutine dispatchers and OkHttp it’s better to write some custom OkHttp dispatcher, but not sure that it worth it

things like

runBlocking and ThreadContextElement

work correctly with it

runBlocking will work correctly. Not 100% sure how ThreadContextElement works, but as I understand it also should work, this is the whole point of this context

2.7 will require Java 8 which means we can use a default method on converters to handle this case

May I draw some attention to this? I just migrated a lot of code to suspend functions and now my app crashes randomly with

UndeclaredThrowableException

https://github.com/square/retrofit/issues/3128