We are a company with 10+ apps all using 10+ internal SDKs, all coded back at the glorious time of the kotlin-android-extensions gradle plugin. We heavily rely on both #Parcelize and synthetic binding (all our views are coded with it). With the newer versions of Kotlin, this plugin is now deprecated in favor of kotlin-parcelize for #Parcelize and View Binding as a replacement for synthetic binding.
We tried to upgrade our Kotlin version from 1.4.10 to 1.6.0 while still using the kotlin-android-extensions plugin. We suddenly had a #Parcelize error reported here, fixed in Kotlin 1.5.0. Except that the fix is not in Kotlin itself, it is in the kotlin-parcelize plugin. And of course as they deprecated kotlin-android-extensions, the later doesn't contain the fix. So in short, in order to fix the issue we have to use kotlin-parcelize.
Knowing that kotlin-parcelize can't be used along kotlin-android-extensions (build error), and that switching all our views from synthetic to view binding will be a hell of a work that will take a tremendous amount of time, what can be done here ? We really want to keep using synthetic binding while being able to upgrade Kotlin to its latest versions.
What looks like the obvious choice is that you need to move from synthetic views as soon as possible although it might not be possible due to lack of resources.
Old-school approach
A solution to get around the Parcelable problem is to figure out the classes that are not properly parcelized and serialize them in an old-school fashion.
Serializing to JSON
I suggest you take a look at the kotlinx-serialization package it's quite handy to read from and write to JSON.
For those that don't work you can provide the following parcelable implementation which would be generic and work all around the codebase:
Ensure that your classes are annotated with #Serializable important that such annotation comes from kotlinx.serialization package and not the java one.
With this generic function you can write any #Serializable object into a parcel.
inline fun <reified T> writeToParcel(out: Parcel, data: T) {
val jsonString = Json.encodeToString(data)
out.writeInt(jsonString.length)
out.writeByteArray(jsonString.toByteArray())
}
And with this other one you should be able to deserialize such object
inline fun <reified T> readFromParcel(input: Parcel): T {
val size = input.readInt()
val bytes = ByteArray(size) { input.readByte() }
val jsonString = bytes.toString()
return Json.decodeFromString<T>(jsonString)
}
You can make them extension function from Parcel to write even less code.
This should get you around the classes that are problematic for the Parcelize extension; it's not as fast as a proper Parcelable implementation but hey, it works.
Side notes
Note that the code has written directly as an answer of this post and hence untested and some parts might need adaptation. And of course, check out the kotlinx.serialization documentation to see how to create the Json encoder and decoder (it's fairly simple)
Related
As a beginner to Android app development, I am finding code examples that do not identify whether they are written in Java or Kotlin. Even StackOverflow questions frequently omit the language tag.
Is there an easy "tell" in the code where you can immediately see which language is used? For example, I can distinguish C and C++ very quickly from certain elements of the syntax, header use, and library functions.
Are there any quick and "obvious" ways to distinguish Java from Kotlin? I want to be exploring Kotlin and not adding to my (immense) confusion by studying irrelevant code.
some obvious traits for kotlin:
as already mentioned the most obvious is semicolons, although you can
add them and they will just be ignored
variables marked with question marks (nullability) val foo:String? and the usage of val/var/lateinit
class Foo : Something() <-- this is inheritance, there's no extends
or implements
if files are involved, kotlin files end with .kt
any reference to companion object
personally for me the biggest indicator:
fun :) function declaration :
fun foo(): String
If the code has used "val", "var" keywords then 99% it is Kotlin.
Kotlin Keywords and operators. https://kotlinlang.org/docs/keyword-reference.html
Java Language Keywords. https://docs.oracle.com/javase/tutorial/java/nutsandbolts/_keywords.html
Most likely kotlin:
val
var
fun
nameX: TypeX
nameX : TypeX?
object:
open class
when
#
:
sealed
!!
->
"$name or ${name}"
etc
Most likely java:
; semicolon
TypeX nameX
void
extends
implements
public class
instanceof
etc
Java has mandatory semicolons ';' while Kotlin doesn't. The types in Java are int, string, char, etc while in Kotlin they are capitalized(String, Int, Long, Char), also Kotlin can infer the type of a variable most of the time ;)
i found this article helpful
as guys told kotlin is a language Is introduced by null safety and without any smicolons force
and you can find some key in syntax like
**[fun,as,let,also,apply,val,var,lateinit,...]**
So, which one is better and should you use it? The answer to that question depends on your needs. If you’re looking for a language with solid support from Google, then Kotlin may be the best choice, as Android Studio 3 now supports Kotlin development. However, if you need speed or want an open-source project with more flexibility (especially in terms of third-party libraries), Java might be the right option for you.
refer to this article
If the file end with .kt, it is Kotlin.
This is with implementation 'org.json:json:20180813'
So I have a User class that allows itself to be translated to a json string for persistence:
data class User(override val name:String, override val creds:ICredentials) : IUser, isEncodable<IUser>{
override val isLoggedIn by lazy { creds is Credentials.Valid }
override fun encode():String{
val credsEncoding = creds.encode()
return JSONStringer().withObject { it
.key("type").value(this::class.java.name)
.key("name").value(name)
.key("creds").value(credsEncoding)
}.toString()
}
}
where withObject is an extension function:
fun JSONWriter.withObject(content:(JSONWriter)->JSONWriter) = content(`object`() as JSONWriter).endObject()
This seems to compile and work perfectly fine.
However, AndroidStudio marks it red and claims
Unresolved reference
None of the following candidates is applicable because of receiver type mismatch
public fun JSONWriter.withObject(content:(JSONWriter)->JSONWriter):JSONWriter! defined in [...]`
If I try to "cheat" and write it as
(JSONStringer() as JSONWriter).withObject { it
...
}
the error becomes a warning that
This cast can never succeed.
But apparently, it does.
Why is that? And how do I get rid of this "error"?
This is with implementation 'org.json:json:20180813'
That's unlikely to work well.
Why is that?
For the past 11 years, Android has a copy of org.json classes in the Android SDK. This includes JSONStringer. You can't have two classes with the same fully-qualified name, and the firmware always wins. Your copy of the conflicting class will not be used, with the firmware one used instead. And the firmware's API has not changed much in those past 11 years.
And how do I get rid of this "error"?
Remove implementation 'org.json:json:20180813'. Either:
Use the Android SDK's built-in org.json classes, or
Use the Android SDK's JsonReader and JsonWriter classes, or
Use a different JSON parser (e.g., Gson, Jackson, Moshi)
I use kotlinx.serialization on Kotlin native project, I a defined Super class for my models and all of the models extends from it.
I defined a function to called toJSON() for serialize variables and fields inside model that all of class models have it.
#Serializable
open class Model {
fun toJSON(): String = JSON.stringify(this);
}
And I created a subclass
class Me : Model() {
var name:String = "Jack";
}
but when I invoke JSON.stringify(this), IDE get a Warning to me:
This declaration is experimental and its usage must be marked with '#kotlinx.serialization.ImplicitReflectionSerializer' or '#UseExperimental(kotlinx.serialization.ImplicitReflectionSerializer::class)'
I paid attention and I used #ImplicitReflectionSerializer annotation while not worked.
Where is my problem?
This is discussed here. It's the particular overload you're using which is still experimental. So your options are either to use the other overload (which takes in a serializer) or to use one of the annotations mentioned in the error message. If you look at the answer to the question I linked (and the comments following it), you'll see it talks about using #UseExperimental and where it should be used.
In my Kotlin Multiplatform project, I'm trying to access Kotlin types defined in kotlin-stdlib from Swift.
TL;DR: StdLib types/methods seem not to result in header definitions, I'd like a solution that doesn't involve writing lots of boilerplate code
My scenario
I have an interface defined in Kotlin ...
interface MyKotlinInterface {
fun run() : Sequence<String>
}
... and implemented this interface in Swift ...
class MySwiftClass : MyKotlinInterface {
func run() -> KotlinSequence {
// return sequenceOf("foo")
}
}
... there I'm trying to create a Sequence but there are no methods from the kotlin.sequences package available (e.g. generateSequence).
Is it actually possible to access Kotlin framework types or methods beyond what I define in my code -- if yes, how? Furthermore, how can this be achieved without writing boilerplate code?
Further details
Having a look into the generated Objective-C header file, I see definitions for my class (obviously) and basic Kotlin types. What's missing is basically everything from the standard library functionality (I care for everything Sequence-related).
My build.gradle.kts looks like:
plugins {
kotlin("multiplatform") version "1.3.0"
}
kotlin {
targets { /* ... */ }
sourceSets {
getByName("commonMain") {
dependencies {
api("org.jetbrains.kotlin:kotlin-stdlib-common")
}
}
// ...
getByName("iosMain") {
dependencies {
api("org.jetbrains.kotlin:kotlin-stdlib")
}
}
}
}
Having the kotlin-stdlib defined as a dependency for the iOS target, I would expect those to become actually available from Swift.
Minimal working example
https://github.com/panzerfahrer/so-mwe-kotlin-mpp-swift
Current solution approach
The only solution I came up with, is writing the desired function for the iOS target:
fun <T : kotlin.Any> generateSequence(nextFunction: () -> T?): kotlin.sequences.Sequence<T> = kotlin.sequences.generateSequence(nextFunction)
This works ok-ish but is highly unsatisfying as it requires lots of boilerplate code. Additionally, extension functions cannot be made available this way and would require more boilerplate code or even rewriting parts of the standard library.
Desired solution
I like to avoid writing boilerplate code as much as possible. What I actually only care about, is to have (in my case) Sequence fully accessible from Swift. My feeling is, it would be sufficient to make the compiler generate selected or all header definitions for the standard library functionality.
Do you really need lazy computation (aka Sequence) in your Kotlin code?
If no, I would recommend using List<T> instead (and it maps to Swift directly).
For Sequence implementation, a workaround could be to export a factory function from your Kotlin library, e.g. you may declare a function like
fun <T : kotlin.Any> generateSequence(nextFunction: () -> T?)
= kotlin.sequences.generateSequence(nextFunction)
You may select any other factory function for Sequence, that matches your use-case.
In general, there are too many functions in the Kotlin standard library. Exporting them all to Swift will create too many useless symbols in the binary and increase the compilation time.
I'm trying to understand how to use inline modifier correctly. I understand general case, when we inlining lambda to prevent excess allocation, as described in docs.
I was inspecting kotlin stdlib and found in _Strings.kt the following piece of code:
#kotlin.internal.InlineOnly
public inline fun CharSequence.elementAtOrNull(index: Int): Char? {
return this.getOrNull(index)
}
What's the reasoning behind using inline here?
This particular function and a few others in kotlin-stdlib are marked as #InlineOnly so that they are not present in the actual stdlib class files and are only available for the Kotlin compiler to inline them. The goal that is achieved in this way is reducing the methods count in the artifacts, which matters for Android.
Apart from that, using inline functions without lambdas is useful for reifying type parameters.
There is still overhead, no matter how minor, that can be avoided.
A similar discussion on Inline Extension Properties.
A post on Kotlin Extensions which gets down into the bytecode effects
I would say that is related to efficiency. Instead of calling functions elementAtOrNull and thus, getOrNull this one is directly called.