DEV Community: Vishnu Haridas

Native or Cross Platform: What's Best for Your Next App? (external)

Vishnu Haridas — Wed, 08 Feb 2023 16:17:03 +0000

See the original blog post in QBurst blog.

Whether to opt for native development or cross-platform is a question as old as the major mobile platforms themselves. Yet it continues to vex clients on the verge of their next app project even in 2023.

“Shall we use cross platform or native development?”
“I heard that React Native costs less, so can we use it?”
“Why Airbnb moved to native development lately?”

I hear a lot of such questions from clients all the time. They are always confused which technology to choose to build their next app. They hear a lot that cross platform is cheaper, but confused why still many people are opting for native development.

I am exploring the options from the experience that I had in the last decade working on both native and cross platform tools to build mobile apps. This will help you to make a decision whether to choose cross platform or native development to build your next mobile app. Read the blog post here.

What is the "Bus Factor" of Your Project?

Vishnu Haridas — Sat, 04 Sep 2021 18:44:23 +0000

(Also posted in my personal blog. Cover photo by Haidan on Unsplash)

I came across the term “bus factor” a couple of years ago, and since then I always keep an eye on the bus factor of the projects or other mission-critical things in my life. I always try to keep the bus factor more than one whenever possible.

Wait, wait, what’s a “bus factor”?

From Wikipedia, the bus factor is a measurement of the risk resulting from information and capabilities not being shared among team members, derived from the phrase "in case they get hit by a bus."

The term “hit by bus” could be any event that causes a person to disappear unexpectedly — from a medical emergency to an internet blackout.

For example, imagine Alice is a very critical member of a project. Alice is the only person who knows the really important information of the project like account passwords, customer contact details, etc., that no other project members are aware of. The bus factor of this project is 1. If Alice suddenly disappears one day, the project will get stopped because of the lack of critical information required to run the project.

Meanwhile if Bob also knew the said information, the bus factor would have been 2. In this case, even if Alice disappears suddenly, the project can continue with Bob (of course, now bringing the bus factor back to 1 because Alice is now gone).

So, never make the bus factor 1. The higher the bus factor, the lower the risk.

Here is a couple of examples from my life.

When working on software projects

I always ask the developers to keep a shared sheet with all the credentials and other important information consolidated in it. This will include:

Account details and passwords of tools, services, or websites used.
Special instructions to build and deploy the project.
Checklists and any other important information related to that project.

So if the person who regularly builds and deploys the project disappears suddenly (either due to an emergency, or an internet blackout during the delivery time slot) someone else can refer the documents and continue working on the delivery of the project.

A very recent experience

Very recently, there was a medical emergency in my family and I had to raise a good amount of money in a very short period. I contacted my friend, and he told me that he will arrange and send the money the next day.

I quickly realized that the bus factor is just one, and can’t really depend on a single person for the money in such a critical situation. I contacted several other friends, and four more friends agreed to send the money if required. Now the bus factor is improved to 5.

Unexpectedly on the next day, the first friend got into an emergency situation where his car stopped working in the middle of the traffic, had to tow it to the service station, and his whole day got ruined. He was totally unable to arrange the money on time.

Luckily my bus factor was 5, so I had 4 more persons remaining. Finally the money was arranged and everything went smoothly.

Had I kept my bus factor to just 1 in this case, I would have been doomed that day!

Another experience from a friend

One of my friends kept all her children’s tons of childhood photos in an external hard disk. One day the hard disk fell down and gigabytes of memory got destroyed instantly! The bus factor was just 1 here — if the hard disk is gone, everything is gone. If she kept another backup in a DVD, another hard disk, or uploaded to Google Photos, she could improve the bus factor many times and reduce the risk of losing all her precious memories.

So, let me ask once again. What’s your bus factor?

The `finally` Block in `try-catch-finally` Executes Always

Vishnu Haridas — Wed, 23 Sep 2020 17:41:51 +0000

This article shows Javascript examples. I tried this in Javascript, Java, and Kotlin. A more Kotlin-centric approach in my personal blog.

Recently I was exploring some source code and came across a code that implements a Mutex.

Here's what it looks like (from kotlinx-couroutines-core)

    lock(owner)
    try {
        return action()
    } finally {
        unlock(owner)
    }

I was wondering how they are going to release the mutex lock within the finally block once the return action() inside the try block is executed.

I never wrote a finally block before, so this got me a little confused.

A search revealed that many people have come across this situation. There's a question in StackOverflow which has around ~2.4k upvotes and bookmarked ~500 times.

It is true. The finally block gets executed always, except some unforeseen situations like the process getting killed, which is mentioned in the accepted answer in the StackOverflow question.

I looked up in the MDN documentation and found this:

"Note that the finally-block executes regardless of whether an exception is thrown. Also, if an exception is thrown, the statements in the finally-block execute even if no catch-block handles the exception."

Let's try out a `try` block!

So I created a small JSBin snippet to test that:

function tryExample(){
  try{
    return "Returned from try{}";
  } finally {
    console.log("Inside finally{}");
  }
}

console.log(tryExample());

This code will print:

Inside finally{}
Returned from try{}

One more thing, if the `finally` returns something, then the `return` within the `try` block won't work.

When I posted this on LinkedIn, my colleague Afsal pointed out another interesting thing -- if we return from the finally block, then the return statement within the try block won't execute.

That was another discovery.

I created another JSBin snippet to test that:

function finallyReturnsExample(){
    try{
        return "Returned from try{}"
    } finally {
        console.log("Inside finally{}")
        return "Returned from finally{}"
    }
}

console.log(finallyReturnsExample());

The output will be:

Inside finally{}
Returned from finally{}

So a new lesson learned - the finally block always executes (except for a few conditions) and if a finally block returns, the try/catch won't return.

Kotlin: What are your favorite extension functions that you authored?

Vishnu Haridas — Tue, 01 Jan 2019 20:04:17 +0000

Also published on my blog here: https://iamvishnu.com/posts/kotlin-extension-functions

Kotlin has this nice feature called "Extension Functions" — adding new functionality to an existing class, without inheritance or writing lots of boilerplate code. Extension functions and extension properties are allowed in Kotlin.

Here is an example Extension for the Float class by adding a new function called asDollars() to print that float number as a currency value:

fun Float?.asDollars() = "USD%.2f".format(this ?: 0.0F)

Now anywhere in code I can write:

val money = 42.0F
println( money.asDollars() ) // will print "USD42.00"

Note: An extension function doesn't really modify the existing class. Instead, the receiver object is passed as the first parameter during compile time. For more, read: Extension functions are resolved statically.

Here are some of my own Extensions that I use across many projects in Android:

1. Some AlertDialogs

fun Context.showAlertDialog(
    title: String,
    message: String,
    ok: Pair<String,()->Unit>,
    cancel: Pair<String,()->Unit>? = null){

    val builder = AlertDialog.Builder(this)
        .setTitle(title)
        .setMessage(message)
        .setCancelable(false)
        .setPositiveButton(ok.first) { _,_ -> ok.second() }

    cancel?.let{
        builder.setNegativeButton(it.first) { _, _ -> it.second() }
    }

    builder.create().show()
}

fun Context.showConfirmDialog(
    title: String,
    message: String,
    ok: Pair<String,()->Unit>,
    cancel: Pair<String,()->Unit>? = null
) = showAlertDialog(title, message, ok, cancel)

fun Context.showErrorDialog(message: String, action: () -> Unit){
    showAlertDialog(
        title = "Error",
        message = message,
        ok = "OK" to action
    )
}

Usage on Activity (or Fragments):

fun onResume(){
    showAlertDialog(
        title = "Welcome",
        message = "Hello, welcome to the show! Do you want to proceed?",
        ok = "Yes" to { nextScreen() },
        cancel = "No" to { finish() }
    )

    // showing an error
    showError("No internet connection. Please try later") { finish() }
}

2. A Simple Click Listener

inline fun View.onClick(crossinline f: ()-> Unit) = this.setOnClickListener { f() }

Usage:

btnNext.onClick { nextScreen() }

3. Some `EditText` validations

fun isValidText(s: String?) = s!=null && !s.isEmpty()
fun isValidEmail(s: String?) = isValidText(s) &&  android.util.Patterns.EMAIL_ADDRESS.matcher(s).matches()

fun EditText.trimmedText() = this.text?.trim().toString()
fun EditText.isValidText() = isValidText(this.trimmedText())
fun EditText.isValidEmail() = isValidEmail(this.trimmedText())