As per https://medium.com/square-corner-blog/square-open-source-loves-kotlin-c57c21710a17 please add support for kotlin.Unit type so consumers don't have to return Call<Void> in Kotlin code. Cheers!
This is really easy. Can do.
Only downside is we have to check for kotlin.Unit using its qualified name. This means if you use ProGuard or jarjar to rewrite the Kotlin stdlib it won't work.
The alternative to that is a separate dependency and explicit converter you have to install.
Dammit, didn't account for rewrites.
Can we slap more things together to a Kotlin artifact to make it worthwhile?
Hmm like what?
On Fri, May 12, 2017 at 4:35 PM Eugen Pechanec notifications@github.com
wrote:
Dammit, didn't account for rewrites.
Can we slap more things together to a Kotlin artifact to make it
worthwhile?—
You are receiving this because you commented.Reply to this email directly, view it on GitHub
https://github.com/square/retrofit/issues/2329#issuecomment-301179712,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAEEEYijkW5_aBRid3Ixq2rQ-u2F4Rddks5r5MKhgaJpZM4NZriw
.
Phew...
retrofit.create<MyService>() instead of retrofit.create<MyService>(MyService::class.java)
that's all I could find right now. I guess other candidates for extension functions could be worth exploring.
Yep, good one. I'll think about it more.
On Fri, May 12, 2017 at 4:45 PM Eugen Pechanec notifications@github.com
wrote:
Phew...
retrofit.create
() instead of
retrofit.create(MyService::class.java) that's all I could find right now. I guess other candidates for extension
functions could be worth exploring.—
You are receiving this because you commented.Reply to this email directly, view it on GitHub
https://github.com/square/retrofit/issues/2329#issuecomment-301181724,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAEEEWKkSWmCBH-Key30Ir9YoKL-Nkrhks5r5MTLgaJpZM4NZriw
.
Will it be compiled to Void in the classfile?
No it stays as Unit. Unlike Void which can only be null, Unit can only be
Unit.INSTANCE.
On Fri, May 12, 2017, 8:50 PM Jesse Wilson notifications@github.com wrote:
Will it be compiled to Void in the classfile?
—
You are receiving this because you commented.Reply to this email directly, view it on GitHub
https://github.com/square/retrofit/issues/2329#issuecomment-301214777,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAEEEWyEN109FatdZrRM2HGJOiCDtYE1ks5r5P5zgaJpZM4NZriw
.
Nothing? can be null but that's counterintuitive to use.
BTW this is trivial to add yourself if you don't want to wait for official support:
object UnitConverterFactory : Converter.Factory() {
override fun responseBodyConverter(type: Type, annotations: Array<out Annotation>,
retrofit: Retrofit): Converter<ResponseBody, *>? {
return if (type == Unit::class.java) UnitConverter else null
}
private object UnitConverter : Converter<ResponseBody, Unit> {
override fun convert(value: ResponseBody) {
value.close()
}
}
}
@JakeWharton About the proguad comment, it looks like Class.forName calls might work: https://www.guardsquare.com/en/proguard/faq:
Does ProGuard handle Class.forName calls?
Yes. ProGuard automatically handles constructs like Class.forName("SomeClass") and SomeClass.class. The referenced classes are preserved in the shrinking phase, and the string arguments are properly replaced in the obfuscation phase.With variable string arguments, it's generally not possible to determine their possible values. They might be read from a configuration file, for instance. However, ProGuard will note a number of constructs like" "(SomeClass)Class.forName(variable).newInstance()". These might be an indication that the class or interface SomeClass and/or its implementations may need to be preserved. The developer can adapt his configuration accordingly.
Could we leverage Class.forName in retrofit2.Utils.getRawType? Source of Unit here: https://github.com/JetBrains/kotlin/blob/master/core/builtins/src/kotlin/Unit.kt.
If coroutines ever hits 1.0 we could eat https://github.com/gildor/kotlin-coroutines-retrofit into a Kotlin module.
Actually we probably want to expose Deferred<T> in addition to awaiting a Call<T>.
Most helpful comment
BTW this is trivial to add yourself if you don't want to wait for official support: