152: Should I Rewrite My App? with Jeroen Mols


Download

After you’ve been working on an app for sometime, the most common quandry one runs into is the need to rewrite the app. We’ve all been there, there’s technical debt, we’ve improved our understanding, the tools have become better, we’ve become better. So should you go back and just rewrite the whole app? Jeroen walks us through his thinking.

Shownotes

Resources

Sponsors πŸ™

Contact

151: Evolving Android architectures (Part 2)

In this episode, we continue our discussion from episode 148 on evolving android architectures. We collected some of the questions from the community and try to answer them.

Download episode directly

Shownotes

Sponsors πŸ™

Contact

150: Learning Kotlin – Returns, Jumps & Labels

Shownotes

Download

Code

data class Customer(val isPlatinum: Boolean)

fun main() {

    val customer = Customer(false)

    println("Number of points customer has: ${calculatePoints(customer)}")

    // Break out of the loop once we're over 25
    for (i in 1..100) {
        if (i > 25) {
            break
        } else {
            println(i)
        }
    }


    // Skip all even numbers
    for (i in 1..100) {
        if (i % 2 == 0) {
            continue
        } else {
            println(i)
        }
    }


    // Break out of the outer loop (which breaks out of the inner too) using a label
    donn@ for (i in 1..100) {
        for (j in 100..200) {
            if (j > 150) break@donn // This will break out of the inner loop and outer loop
            else println("i: $i, j: $j")
        }
    }

    // Continue processing the next outer loop value when a condition is met.
    donn@ for (i in 1..100) {
        for (j in 100..200) {
            if (j > 150) continue@donn // This will break out of the inner loop and outer loop
            else println("i: $i, j: $j")
        }
    }

    // returns with label
    example1()
    example2()

    println("I'm done processing!")
}

fun calculatePoints(customer: Customer): Int {
    if (customer.isPlatinum) {
        return 100000
    } else {
        return 10
    }
}


fun example1() {
    listOf(1, 2, 3, 4, 5, 6, 7, 8, 9).forEach {
        if (it > 7) {
            return
        } else {
            println(it)
        }
    }
    println("This wont print :( because return exited the bar() function")
}

fun example2() {
    listOf(1, 2, 3, 4, 5, 6, 7, 8, 9).forEach bin@ {
        if (it > 7) {
            return@bin
        } else {
            println(it)
        }
    }
    println("This will print! :) return exited the forEach!")
}

Sponsors πŸ™

  • Nevercode

    • Nevercode is taking Flutter revolution extremely serious and is prepared to offer kick-ass CI/CD for Flutter projects with codemagic.io. Check it out and get started at https://codemagic.io/
  • Sentry.io

    • Sentry tells you about errors in your code before your customers have a chance to encounter them. Check them out at: https://sentry.io/for/android/

Contact

149: Learning Kotlin: inline classes and Type driven design

In this quick fragment, Kaushik talks about the new Kotlin 1.3 experimental feature “inline classes” and how it helps with Type driven design.

Download

Shownotes

Type driven design resources

Kotlin KEEP

vs typealias

Sponsors πŸ™

Contact

148: Evolving Android architectures (Part 1)

In this episode, Donn and Kaushik talk about the state of android architectures and how they’ve stared to evolve. Kaushik recently worked on a project of coming up with an evolved version of an MVVM architecture, very similar to what the Android community now calls MVI.

Special request: if you have follow up questions or clarifications or things you’d like to see specifically with respect to this dicussion, hit us up on the Discord #fragmented-podcast channel with your thoughts and we’ll make sure to address them in future parts!

Download

Shownotes

Salient features of the pattern:

I. Screens are driven by a single ViewModel

II. Screens listen to a single Observable exposed from the ViewModel

III. Events are sent into the VM through a single function processInputs

IV. Break(ing) the Chain VI. Testing strategy

Inspiration

Sponsors πŸ™

Contact