Kotlin Meteor: findViewById dead as Dinosaurs

findViewById(int) is an essential and ubiquitous method call that plods in your Activities, Views, Fragments and Adapters. It sometimes goes out of control but can be tamed with projects like Butter Knife, InjectView or Android Annotations. Being verbose and slow, the results should be cached when used frequently and hence the ViewHolder pattern.

Sometimes, the number of lines of code could be as little as a Compsognathus or could grow large and wild like a T-Rex. Check it out for yourself.

Regular Code

private EditText mEmailEditText;
private EditText mPasswordEditText;
private EditText mConfirmPasswordEditText;
private Spinner  mAgeSpinner;
private Spinner  mCountrySpinner;
private Spinner  mStateOrProvinceSpinner;
private CheckBox mIAgreeCheckBox;
private Button   mRegisterButton;

protected void onCreate(Bundle savedInstanceState) {

    mEmailEditText = (EditText) findViewById(R.id.emailEditText);
    mPasswordEditText = (EditText) findViewById(R.id.passwordEditText);
    mConfirmPasswordEditText = (EditText) findViewById(R.id.confirmPasswordEditText);
    mAgeSpinner = (Spinner) findViewById(R.id.ageSpinner);
    mCountrySpinner = (Spinner) findViewById(R.id.countrySpinner);
    mStateOrProvinceSpinner = (Spinner) findViewById(R.id.stateOrProvinceSpinner);
    mIAgreeCheckBox = (CheckBox) findViewById(R.id.iAgreeCheckBox);
    mRegisterButton = (Button) findViewById(R.id.registerButton);

All my hard work can be explained in a simple sentence – obtain references to my views. The problem is mitigated when using a view binding library, but you still need visible field declarations.

Butter Knife

EditText mEmailEditText;

EditText mPasswordEditText;

EditText mConfirmPasswordEditText;

Spinner  mAgeSpinner;

Spinner  mCountrySpinner;

Spinner  mStateOrProvinceSpinner;

CheckBox mIAgreeCheckBox;

Button mRegisterButton;

protected void onCreate(Bundle savedInstanceState) {


Better, but still not subtle. This is the farthest Java can take you. Kotlin as a language itself could only take you so far.

Edit: Butter Knife doesn’t stop here. It has several other features like listener injections, view lists, resource binding, nullifying view references, etc., If you are still using Java for development, it is your best bet.

With the not so advertised Kotlin Android Extensions by JetBrains, your code will look like this,

Kotlin Android Extensions

import kotlinx.android.synthetic.activity_register.*

override fun onCreate(savedInstanceState: Bundle?) {

Is that all? Yeah, that’s all of it ūüėČ and I am sober. CHECK. Notice the import statement.

import kotlinx.android.synthetic.<layout>.*

This statement imports all the widgets in the specified layout as properties. These view properties are named after their XML IDs and can be accessed directly. For instance, if you want to set a click listener for the register button. You can do,

registerButton.setOnClickListener(this) // R.id.registerButton

Next Steps

Check out the Getting Started guide to get started with Kotlin for Android Development and the Kotlin Android Extensions post to reap the above mentioned benefits. I like where this is going, what are your thoughts?

How I wrote my first iOS app while learning Kotlin for Android Development

Ever since I read Jake Wharton’s tweet, I’ve been¬†spending a¬†considerable amount of time with Kotlin¬†for Android development. I’m very impressed with the language. It is concise, elegant, easy to pick up, has excellent tooling support and¬†bundles several language features that Java currently lacks. I was even able to deliver a Kotlin presentation (scheduled for an hour, but would have easily gone for 3 hours if it wasn’t for the rumbling stomachs) during the Madras JUG launch event¬†on 31st January (3 days after Jake’s tweet).

Yesterday, a sudden thought of¬†Swift¬†struck me like a thunderbolt (figuratively) when I was about to leave for lunch.¬†I did take a peek at the language when¬†it was first released last year and it¬†had a resemblance to other “modern” programming languages. Most importantly, it looked a lot more amicable than its predecessor – Objective-C. I recollected my iOS devs in my dev shop raving about the number of Swift libraries that went live on GitHub on the same day when the language was announced.

Before leaving for lunch, I did my usual – just this one and Googled for “swift quick start” and landed on Ray Wenderlich’s website.¬†At the first glance, Swift looked very familiar. If you were to¬†see¬†both the languages at some place that didn’t provide any context (IDE / APIs / conventions), you¬†might accidently¬†mistake one for the other. Following are my observations.


Optional in both the languages.

Variable Declaration

Kotlin & Swift

var atomicNumber = 8          // Inferred type
var atomicNumber: Int = 8     // Explicit type declaration

Immutable Variables


val pi = 3.14159265359


let pi = 3.14159265359

Difference: Swift uses the let keyword for immutable variables.

Optionals / Nullables

Kotlin & Swift

var middleName: String? = "X."

Object Instantiation

Kotlin & Swift

var person = Person()



fun isDealOk(marketPrice: Double, yourOffering: Double): Boolean {
    return retailerPrice <= yourOffering


func isDealOk(marketPrice: Double, yourOffering: Double) -> Bool {
    return retailerPrice <= yourOffering

Difference: Swift uses func keyword for function declarations and the return type is preceded by the -> token.

Function Calls


isDealOk(199.0, 149.99)


isDealOk(199.0, yourOffering: 149.99)

Difference: Swift requires you to include the parameter name (from the second parameter onwards), when you have more than one parameter in a function.

Function Overriding


override fun heal() {
    health += level * healingFactor


override func heal() {
    health += level * healingFactor

Difference: Notice the func keyword in Swift.

String Templates


var name = "Kotlin"
println("Hello, ${name}")   // You can also use $name


var name = "Swift"
println("Hello, \(name)")

Difference: Swift uses the \() syntax for string templating.

Type Checks and Casting

Kotlin & Swift

var isZombie = civilian is Zombie      // Check
var ironMan = tonyStark as IronMan     // Cast



var delay: Long = 1000L
    get() {
        // Return value from the backing field

    set(value) {
        // Set value to the backing field


var delay: Long {
    get() {
        // Return a computed value from a different
        // instance property

    set(value) {
        // Set value to a different instance property

Difference: Properties in Kotlin and computed properties in Swift serve different purposes. They look syntactically similar, but have slightly different use cases.



class Martian {
    var name: String = "Z1000"

    constructor(name: String) {
        this.name = name


class Martian {
    var name: String = "Z1000"

    init(name: String) {
        self.name = name

Difference: Kotlin has the concept of primary and secondary constructors. Primary constructors are declared in the class header. The above example uses a secondary constructor that was introduced in the M11 release. Notice the use of constructor in Kotlin and init in Swift. Kotlin also has the init keyword, but it is used for initializer blocks.



class Mutant : Human(), Flyable {    // Super class + Trait


class Mutant : Human, Flyable {    // Super class + Protocol

Traits & Protocols


trait Flyable {
    var maxSpeed: Float

    fun fly()
    fun land(): Boolean


protocol Flyable {
    var maxSpeed: Float { get set }

    func fly()
    func land() -> Bool

Difference: Swift requires you to specify accessor methods for properties using the get and set keywords. The major difference is – trait methods in Kotlin can have implementations, but Swift doesn’t allow method bodies.



enum class Choice {


enum Choice {

Difference: Absence of the class keyword, presence of case keyword and enum values are separated by commas.

I haven’t looked into other Swift features like generics, closures, extensions that have equivalents in Kotlin. I’ll update this post when I do.

So, what did I build?

I built the classic Rock-Paper-Scissors application on iOS using Swift. You pick one, the phone picks one and then we show the outcome. It’s a rather simple application. Here is the screenshot for your viewing pleasure (it’s not that pleasurable though :P)

Rock Paper Scissors iOS App in Swift


Languages and platforms are entirely different things. Just because someone can work in Java doesn’t mean that he’d be equally good in a dozen of frameworks or language-based platforms that are available in the wild. Play framework, Hadoop, Elastic Search, and Android are all based on Java but require a different set of skills.

One advantage for a Kotlin developer when working with Swift is syntax. Just that. After that, there’s a whole bunch of APIs that you have to master in order to work with Swift on iOS. Then the IDE and toolchain, followed by differences in the UI/UX model, error messages, 3rd party libraries, dependency management and build systems, etc.,

It could be surprisingly difficult to accomplish simple things. I hit a bunker in Swift while creating the app. I wasn’t able to generate a random number within a given range! How cool is that? This is a no-brainer in Java/Kotlin.


val randomIndex = Random().nextInt(CHOICES.length)
val phoneChoice = CHOICES[randomIndex]


let randomIndex = Int(arc4random_uniform(UInt32(CHOICES.count)))
let phoneChoice = CHOICES[randomIndex]

It took me over 15 minutes to figure this out.

Final Words

If you are an Android developer and are looking for productivity and power, you should be learning Kotlin already. With your newly acquired Kotlin skills, it should be encouraging and easy enough to pick up some Swift and iOS skills along the way.

Thank you for reading. Don’t forget to share this post in any of your social media circles if you found it interesting.

(Reddit re-post) Validation in Android – Why I ‘scratched my itch’ and how it saves our time

Original post on Reddit.

I have been working on Android since 2009. I never gave much thought about validation until I did this enterprise application for one of my clients. The application had a dozen of forms with all kinds of validations, starting from required fields, regular expressions to server validations. Validation became a pain in the neck and it was so annoying.

I tried googling for validation frameworks and there were a few which gave a jump start. However, they were insufficient for complex validations or forced me to use their own EditText widgets. Being desperate and frustrated I began authoring this library about 3 AM one day and in the next 3 hours ended up with something that was easy to use.

I posted it on GitHub (Yeah, licensed under Apache 2.0) and after receiving a suggestion from a developer on StackOverflow, I added annotations. Here are some of the examples that will clearly show you the difference when using traditional validation techniques and when using the Android Saripaar UI validation library.

Traditional – Required Field

String username = userNameEditText.getText().toString();
int usernameLength = username.length();
if (usernameLength == 0) {
    // Notify the user that username is required.
} else if (usernameLength > 3) {
    // Notify the user that username is too short.

Saripaar – Required Field

@Required(order = 1, messageResId = R.string.username_required)
@TextRule(order = 2, minLength = 3, message = "Too short :(")
private EditText usernameEditText;

Saripaar – Email (Optional or Valid)

@Email(order = 1, messageResId = R.string.email_invalid)
private EditText emailEditText;

Saripaar – Email (Required and Valid)

@Required(order = 1, messageResId = R.string.email_required)
@Email(order = 1, messageResId = R.string.email_invalid)
private EditText emailEditText;

This is how concise your code could get when you use Saripaar and these examples just showcase the tip of the iceberg.

You can validate IP addresses, regular expressions, numbers, etc., Some of the salient features that improve productivity when you use Android Saripaar are,

  • Annotation support
  • Custom Rules
  • Complex Rules (And, Or, Composite And, Composite Or, etc.,)
  • Asynchronous validation (You don’t have to worry about threading and AsyncTasks.,)
  • Rule only validation (If you are validating against a database or a network connection.,)

We use this extensively for our projects at Mobs & Geeks and have achieved significant productivity in most of the projects.

Saripaar does a remarkable job of offloading the validation logic from your business logic thereby allowing to save a lot of time testing your code.

If you are someone who hates dependencies and has trouble with validations, give it a try. The source is available for download from the Android Saripaar GitHub page.

Live by the rules baby! At least a few ;)

I have personally detested writing boilerplate code. And this has urged me to write libraries for Android like the Simple Section Adapter and a few others¬†in the past. This time, it’s the validation that has caused me distress during development. Why does validation have to be painful? This question resulted in the birth of a new validation library¬†for Android.

Here in this blog, I introduce you Android Saripaar – A rule-based validation library.

Thinking Validation (existing scenario)

Let’s take¬†an example, I have a user registration screen with a three EditText widgets and a Button.

  1. Username (EditText)
  2. Password (EditText)
  3. Confirm Password (EditText)
  4. Register (Button)

Now clicking on the “Register” button has to do the following:

  1. Check if the Username is available (i.e. unique).
  2. Check if the text in the Password and the Confirm Password are equal.
  3. If 1 and 2 succeeds, then register a new user account.
  4. If 1 or 2 fails, then notify the user with appropriate feedback (Dialog / Toast / Animation)

Current Approach

One of the straightforward approaches to solving the above-mentioned problem would be to write an AsyncTask that would make a request to the remote server and check if the Username is unique and in theAsyncTask.postExecute(Result) callback, check if the Password and Confirm Password fields are equal and if all goes well, send another request to the remote server and create a new user account.

Short Comings

  1. Too much intrusive, tangled (this is one of the important reasons for authoring Saripaar) and boilerplate code.
  2. Design for asynchronous validation (When situation calls for it).
  3. Aesthetics, why not put all validation constraints in one place?

Saripaar Advantages

  1. Rule-based – Saripaar is full of rules, whenever you want to validate a field, you write a rule. The library comes with a set of rules that you can use out of the box. In case you have your own situation or a component to take care of, you can simply extend the Rule class and write your own rule.
  2. Synchronous is Asynchronous – When you have to do an asynchronous validation like a network operation or querying your¬†magnanimous¬†SQLite database you don’t have to think of threading / AsyncTask, Saripaar does it all for you.
  3. Callbacks – Receive callbacks if your validation is successful, when a rule fails or even if your validation is cancelled.


No programming article is complete without an example. Following is a glimpse of Saripaar’s usage. You can find the project on¬†GitHub, there is no user guide as of now, however, the source code is completely documented and is at your disposal. The following snippet should give you an idea of its ease of use. I have planned a wiki for the project. So when that is done, it will be a comprehensive guide for beginners.

// Validator & listener
validator = new Validator();

// Create a new rule
Rule usernameRule = new Rule<EditTex>("Username is taken :(") {

    public boolean isValid<EditText>(EditText editText) {
        // All your synchronous HTTP request, parsing, etc.,
        return isUnique;

validator.put(userNameEditText, uniqueUsernameRule);
        Rules.eq("Passwords don\'t match", pwdEditText));

To begin validation, call the Validator.validateAsync() method from your event handler, usually the¬†View.OnClickListener and handle the appropriate callbacks – preValidation(), onSuccess(), onFailure(View failedView, Rule failedRule) and onValidationCancelled().Feel free to post your queries as comments, I’ll be happy to answer.