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.
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.
I've been following this article and I'm unsure what the #Stable annotation does. I have seen this documentation but I need an example to better understand.
#Stable is an Annotation that will tell the compiler that it's value will not change and return exactly the same value. This should only be applied to functions or values that are static the whole time.
The main reason why this is used is simple:
Increased performance -> compiler will be faster because you tell him how to handle it.
You can return always the same value, that can't be changed.
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)
The Reified Type parameters support run-time access to types passed to functions. I understand that this can be useful in certain scenarios to avoid reflection.
But there are examples of creating extension functions with reified type parameters which simply wrap T::class.java syntax in a method like below.
inline fun <reified T > Context.systemService() =
ContextCompat.getSystemService(this,T::class.java)
The kotlin reference mentions for the below usage the call-site is not pretty. Why is the following usage discouraged?
ContextCompat.getSystemService(this, NotificationManager::class.java)
Instead we can now write it like this :
systemService<NotificationManager>()
Are there any other benefits in such a scenario except that the code looks cleaner?
Note: the example is from I/O' 18
This is entirely up to personal opinion, as both functions will do the same thing.
People will tend to consider the reified Kotlin extension method more idiomatic because it makes use of advanced language feature to provide simpler syntax than what you'd otherwise have to use. Doesn't mean you absolutely have to use it - decide if you like it for yourself.
It´s a good idea to use kotlin extensions all over the code?
I miss a lot the extensions from iOS, but this is a good way to use those kind of things in android?
Refering to http://antonioleiva.com/kotlin-android-extension-functions/
Is there a better solution for this?
To expand a little bit more on Andrey Breslav's answer a bit, Kotlin extension functions do compile down to static java methods, so most general purpose extension functions carry no overhead. But there is one edge case you need to look out for that Jake Wharton calls out in the first few min of this talk at Google IO.
That is when you pass in higher order functions (lambdas), as a parameter to the extension function like so:
fun View.doSomething(block: () -> Unit) {
//do something
}
This code would take a performance hit because lambda's under the hood have to create an anonymous class under the hood which can eat up methods and cause class loading. This is a very simple fix by adding the inline keyword to the function which will essentially inline your code into all of this call sites functions so you will not take a performance hit each time the extension function is called.
inline fun View.doSomething(block: () -> Unit) {
//do something
}
Extension functions in Kotlin are compiled to normal Java methods. For example, when you define a function in your package it turns into a static method in a Java class. There's no overhead compared to simply calling a static utility