Feel Kotlin (and slightly Gradle) on the example of Posting-long-tweets (open source)
I have never been a fan of HelloWorld and tutorials. They usually solve problems that are solved well with this tool, but sharp angles and shortcomings are delicately managed. You can really touch a language or library only on a real application, writing a “business code”, and not “a service of a factory of services of factories of service models”. An example of such a simple application is in the video. Here we go?
Prerequisites for the task
I love to read books from my phone and I love to tweet quotes from these books. But since these books usually contain quotes longer than 140 characters, the situation was somewhat annoying. The problem could be solved in two ways:
send quotes in multiple tweets
tweet text with pictures.
It was the second way that seemed to me less awful. The result is an application used in a chain of actions: share text from any application -> get into our program -> share a picture in any application again ')
What can be learned from the resulting project
look at the pros Kotlin
look at the typical build script in gradle
drag off the function of calculating the font size to fit the text into the rectangle, receive the text shared from another application, the function of sharing the picture in other applications and other trifles.
Benefits Kotlin
Recent months, fame * Xamarin'u, I wrote under the mobile phones on .NET (C #). After it, returning to Android (where Java 7 reigns with limitations, if you want to write for Android 4.1+) is not that unpleasant, but the contrast is very noticeable. Sugar is not enough. Kotlin, however, is wildly pleased with the opportunity to write code concisely, the machine does a sickly part of the routine for you.
Need to declare just a POJO class with readonly fields? Easy.
public class Size(val width:Int,val height:Int);
Independently declare the type of variables? But why, if the compiler can output them for you!
val textPaint = TextPaint(Paint.ANTI_ALIAS_FLAG); var paint = Paint();
Moreover, var is a variable, and val is a final object, so that you do not accidentally replace it with another value. Also, the code allows reducing operators like with :
fun alertError(text:String){ val builder = AlertDialog.Builder(this); with(builder) { setTitle(R.string.error_title) setMessage(text) setPositiveButton(R.string.ok, { dialogInterface, button -> }) } builder.create().show(); }
Or the ability to stick variables inside a string without the format function or similar in meaning:
val cachePath = File(getExternalCacheDir(), "temp"); cachePath.mkdirs(); val fileName = "$cachePath/long_text_image.png";
Callback'i for clicks are also assigned quite shorter code:
buttonSend.setOnClickListener { val text = editText.getText().toString(); // ..... }
And as you probably already noticed their examples above, the “new” operator is also abolished.
I also liked the opportunity to declare functions without classes as an alternative to static methods, which, as I understood, do not exist in Kotlin.
package com.newbilius.longtextsharer import [...] public fun getMaxFontSizeOfMultilineText(text: String, maxSize: Size, maxTextSize: Int): Float { fun getHeightOfMultiLineText(text: String, textSize: Int, maxWidth: Int): Int { //[...] } var textSize = maxTextSize; while (getHeightOfMultiLineText(text, textSize, maxSize.width) > maxSize.height) textSize--; return textSize.toFloat(); }
And under Kotlin + Android, Kotlin has such a cool thing - Kotlin Android Extensions . It allows you to forget findViewById () as a bad dream and make the following feint with your ears:
An order of magnitude more convenient than annotations RoboGuice .
Perhaps the only thing that seemed strange to me was the format for early exit from CallBack:
buttonSend.setOnClickListener { val text = editText.getText().toString(); if (text.length()==0) { alertError(R.string.error_empty_text); return@setOnClickListener; // } //[...] }
Use Gradle
Today, assembling Android applications using Gradle is considered a standard. The truth is that it’s a bit annoying that Groovy’s underlying Gradle development is stopped (?) At the beginning of the year. Well, okay, let's be optimistic. The minimum application build script (in the debug and release builds) looks like this.
By the way, I highly recommend using proguard to build the release version - without it, I have a Kotlin application that weighed 5 times more than a similar Java application. After processing with proguard, the difference in size was 100 kilobytes or so. In the proguard-rules for the assembly had to add just one rule:
-dontwarnorg.w3c.dom.events.*
However, if you build the same script not from the console, but from IntelliJ IDEA, for example, you will come across a problem - in this case you don’t have a console to enter the password for the certificate. For this problem, there seems to be a solution - but it didn’t suit me, when I tried to use it, I received an error:
Error:(29, 0) Gradle: Failed to create component for'dialog' reason: java.awt.HeadlessException > java.awt.HeadlessException (no error message)
Perhaps you are more lucky and you will help me find a mistake? Versions of libraries, Java and IDE itself are the latest.
Local decisions and conclusions
I will not enumerate the features of the functions of calculating the font size for inscribing text in a rectangle or sharing an application - everything is in the source code of the described application on GitHub.
In general, as for me, on Kotlin the code is more concise and simple, so for my small projects I will continue to use it (as well as share the source code). If it seemed to you that I didn’t use any other cool (and relevant) features of Kotlin or Gradle in this application - I’m waiting for pull-requests and comments!
* fame is very limited, article listing kilotons of pitfalls on the way