it's unlikely someone is generating body-less code anyway

Foo : Foo()

is generated as long as the body doesn’t have a self-reference to

Foo

doesn’t need to be body-less

anyway, kudos. I was already mentally preparing for filing an issue or two. 🙂

👍

Has anyone experienced any issues with Retrofit while using the rxjava2 adapter and moshi converter? I have a service that returns an observable of a type

fun list(): Observable<Account>

and I’m using the okhttp mock server to return

[{ <account 1> }, { <account 2> }]

and get a

JsonDataException

when executing my tests

com.squareup.moshi.JsonDataException: Expected BEGIN_OBJECT but was BEGIN_ARRAY

looks correct. you are returning an array of account

but the observable is of type account

should it be

Observable<List<Account>>

?

Except I’m not trying to observe the list, I’m wanting to observe each account 😞 Am I missing a core rx detail perhaps?

I could try that and convert it from the list if needed 🤔

fun list(): Observable<List<Account>>
...
val accounts: Observable<Account> = service.list().flatMap { Observable.fromIterable(it) }

You can use flatMapIterable(it -> it)

Is my overall issue that I’m trying to use the rxjava2 call adapter to give me

Observable<Account>

which is interpreted as a single

Account

rather than a stream of multiple

Account

?

Yes. Retrofit deals in entire response types

Ahh, good to know! TIL my problem wasn’t a lack of rx knowledge, well this time 🙂

Since I’m work on an SDK library, it’ll probably be best for me to drop the rx anyways

do kotlinpoet and javapoet have builders for method call arguments? haven’t found any

In KotlinPoet you can collect them as CodeBlocks in a list and then do joinToCode

Probably my favorite extension function for Retrofit that I use in almost every project

internal inline fun <reified T : Any> Retrofit.create(): T = create(T::class.java)

retrofit.create<EmployeesService>()

Is there a reason why you shouldn’t make a Moshi adapter for

Any

?

You mean in the Kotlin artifact? Seems almost trivial to delegate to an Object adapter, and that's not an ideal scenario (not a usage to encourage)...

But if you need it, you could make a @FromJson adapter that takes in a JsonAdapter<Object>. Am mobile, but hopefully that makes sense.

Or do you mean why shouldn't you use an Object adapter in general?

(Because it requires looking up the adapter for the runtime type every time you serialize and just makes you a map when deserializing.)

Is Moshi supposed to ignore `@NotNull`/`@Nullable` annotations when it’s creating an object instance?

data class Created(val id: Int)

adapter.fromJson("{}").toString() // Created(id = null)

use the KotlinJsonAdapter, and that'll correctly fail to deserialize.

Awesome! I’ll go take a look 🙂 thanks

Or Kotshi

btw, lazyweb: will Kotshi handle all the type woes? i haven't looked at it.

like List<String?> vs List<String> etc.