I have written Android apps developed by the company in Java so far, but with the official support of Android Studio 3.0 release = Kotlin at the end of October, I decided to use Kotlin to implement the new development part. Also, the existing implementation part is being rewritten little by little as needed (also for practice).
So, I haven't used it for a month yet, but I will write about what I felt when I wrote Kotlin.
.kt file, it will convert it. There is no need to write it again, but this is what I will mention.
Compared to Swift, which is also used when writing native apps, I was worried that I had to write while paying attention to the occurrence of slimy, but this has been resolved. Of course, you can avoid it by checking Null or using ʻOptional.ofNullable` in Java, but it's good to have a world where Nullable and NotNull are clearly separated.
I like to use the Elvis operator to write Swift's guard.
sample.kt
val str: String = optionalStr ?: return
When dealing with a project in which Java and Kotlin are mixed, there are of course cases where Java code is called from Kotlin. In such a case, if you add annotations on the Java side, the optional restrictions in Kotlin will come into effect.
For example, suppose you have the following code on the Java side.
AppUtil.java
public class AppUtil {
public static String getVersion() {
return "1.0";
}
}
When called from Kotlin side, the return value of ʻAppUtil.getVersion ()will beString!, And it will be in a state where both String and String? are allowed. If you inadvertently enter even null, you will return to the Nullpo era. This will lose its character, so add the @NonNull or @Nullableannotation to the method on the Java side. The IDE will now infer that the return type isString or String? `.
You can create new methods and properties in an existing class. When I was writing in Java, it was inconvenient to not have this compared to Swift. (To achieve this, there were quite a few static methods of classes like HogeUtil)
Extension.kt
fun Button.disableTouch() {
alpha = 0.5f
isEnabled = false
}
The above is an example of adding a method to ʻandroid.widget.Button`.
My favorite static methods and properties don't exist in Kotlin. For example, how to express a factory method like public static HogeFragment newInstance (...) {...} that I usually wrote in the fragment file is to use Companion Object as one of the solutions. There is a hand.
HogeFragment.kt
class HogeFragment : Fragment() {
companion object {
fun newInstance(...): HogeFragment {
...
}
}
}
HogeFragment.Companion.newInstance (...) when calling from Java, which is a bit clunky. If you want to call HogeFragment.newInstance (...) as you did in Java, annotate the method with @ JvmStatic. HogeFragment.kt
companion object {
@JvmStatic
fun newInstance(...): HogeFragment {
...
}
}
On the other hand, as a method of expressing static methods (poor things), there is also a way to use top-level functions of files.
HogeFragment.kt
fun topLevelFun(...) {
...
}
class HogeFragment : Fragment() {
...
}
I was wondering if the former method (the one that uses Companion Object) is basically good because it can be called in the same way as in Java and there is no need to worry about name collisions. However, I recently read the following blogs, etc., and learned somehow with an image of how to use them properly.
companion object vs. top-level - hydrakecat’s blog
The same applies to static variables, and there are two ways to declare properties in Companion Object and one at the top level. (For the former, you can call it in the same way as in Java by adding @JvmField)
So, I haven't started using it yet, but I wrote a little about what I felt when I wrote Kotlin.
In addition to what I've written above, I'm also happy that it's similar in writing to Swift and the amount of code is reduced compared to Java. I think it may be used on the server side.
We are looking for friends to write Kotlin, Swift, Rails and Python together in Atrae! https://www.green-japan.com/company/172
Recommended Posts