Hey @jw. How soon is sqldelight Kotlin 1.0 coming out?

probably not for a while

@alec would know

TOMORROW

Naw idk

You can use snapshots if you're curious though it works fine it's just undocumented

Full release with readme and sample etc won't be for a bit though

with any luck I'll be able to update SDK Search to use it and we can point people at that for something to copy

I could do like an alpha release or something sdksearch isn't using snapshots

I tried snapshot, Plugin configuration crashes with error "SourceSet with name 'main' not found."

file an issue with more info?

Will do some time later

if youre using the android gradle plugin make sure you're using the android version: https://oss.sonatype.org/content/repositories/snapshots/com/squareup/sqldelight/android-gradle-plugin/

Inside of a JsonAdapter in moshi, if I peek and find an object, will performing a

reader.nextString()

give me the whole object as a string? I’m trying to split

[{...}, {...}, {...}]

into a list of JSON object strings

listOf("{...}", "{...}", "{...}")

It won't, no. That method only works if peek returns string

Dang, sounds like I’ll have to create a custom iterator that takes the buffered source and reads each object off of it

You could file a feature request. Someone filed for writing arbitrary JSON but not reading

What are you doing?

Reading raw JSON: https://github.com/square/moshi/issues/318

@jw I’m doing an exercise where I’m writing a RPC router that uses moshi and I’m trying to figure out how to add seemless batch

[{ ... req1 ... }, { ... req2 ... }]

and non-batch

{ ... single req ... }

support as defined in the jsonrpc.org 2.0 spec

cool!

I have use case that make

Unit

support useful in Moshi, anyone up for a code review of my adapter?

@bdawg.io uploaded a file: UnitAdapter

Looks fine, we have similar for Gson Similar case with Retrofit: https://github.com/square/retrofit/issues/2329 Maybe for your case your JSON-RPC lib should handle it instead

I watched a talk by jw awhile back about how using the rx

onError

to handle network errors was bad practice. I’m trying to convert one of my calls that is modeled this way, but I’m finding that I lose a little bit of the functionality I relied on in handling network errors the other way. old way:

someService.someCall()
    .subscribe({ response -> 
      //positive response things
    }, { e -> 
      when(e) {
        is HttpException -> //do something
        is UnknownHostException -> //do something else
    }

new way:

someService.someCall()
    .subscribe({ response ->
      if(response.isSuccessful()){
        //positive response things
      } else {
        //can no longer check exception types here
      }
    },{ e ->
      //handle really bad stuff here
    })

Is there something I’m missing in order to keep the same kind of functionality from the old way in the new way?

So far, I found this snippet, but it doesn't seem to be saving any files... I guess I'm not clear enough on Okio usage yet..

A file was commented on

A file was commented on

@gildor Thanks for the comments, I guess I could wrap the reads in

produce

on a custom thread pool like you said. I'm currently using your extension function for

await

of the request. I'm not to clear on how to implement the parts, should I make multiple requests with a Range header concurrently, if so, what is reasonable amount. Also, would source reads and sink writes benefit from concurrency and using coroutine channels?