An insightful ebook published by ThoughWorks. Deserves a perusal!
Download PDF here.
In our recent Android App development, we developed many static utility functions, which needs a Context as the argument:
public static void func1(Context context, …)
public static void func2(Context context, …)
public static void func3(Context context, …)
public static void funcN(Context context, …)
This is very cumbersome. We would like to refactor these utility functions into functions without the context argument/ A natural idea to pass in the application context at the very beginning, e.g. Application.onCreate() function, but not in all cases, can we use the application context. For instance, when you create a dialog or toast window, we need to use Activity as the context. So here comes the function that works:
Visit this gist to get the source code.
If there is only one sentence to describe Kotlin, it would be: “Kotlin is great”!
You will not appreciate the beauty of it if you do not suffer from the repetitive, boilerplate coding in java. Let’s see an example first.
Consider you have two classes, as shown below, they do the same thing, interchangeable, exactly the same in terms of functionality, which one do you choose? Left or right one?
The left one is java implementation, and the right, Kotlin.
This is a real example that I encountered in developing an Android App. The App tries to get the new questions on StackOverflow site: Open the link below in your browser to see how you can get the json from StackExchange API:
You will be presented a similar json as below:
In order to display a list of such questions in Android views, I need to deserialize this json string to a POJO (Plain Old Java Object) representation. To avoid hands dirty, we can go to http://pojo.sodhanalibrary.com/ and paste the json string to get the POJO class:
In Android, version name and version code serve for different purposes, as is found in Android documentation here:
An internal version number. This number is used only to determine whether one version is more recent than another, with higher numbers indicating more recent versions. This is not the version number shown to users; that number is set by the versionName attribute. The value must be set as an integer, such as “100”. You can define it however you want, as long as each successive version has a higher number. […]
The version name shown to users. This attribute can be set as a raw string or as a reference to a string resource. The string has no other purpose than to be displayed to users. The versionCode attribute holds the significant version number used internally.
In practice, it is often the case that the version name simply maps version code in specific ways, e.g.
2016 (version code) –> v220.127.116.11 (version name)