2026 05 13 13 06 18

Technological concepts / architecture discussed

Kotlin coroutines + dispatchers

• The speaker’s goal is to refactor data-source functions so that all reads from the data sources are executed on the correct Dispatcher.
• They propose using a dependent function pattern to ensure dispatcher selection is applied consistently.
• They emphasize researching what “Dispatcher” and withContext / context mean, and applying them based on the task.

Refactoring duplicated withContext code using the Template Method pattern

• The codebase currently has repeated blocks like withContext across many data-source methods.
• Proposed approach:
  • Create a base/abstract data source (the “template”) that contains the repeated execution logic.
  • Concrete data-source operations provide only the varying work block (“block” / dependent function).

Higher-order functions + generic return types

• A new higher-order function is designed to:
  • Accept a dispatcher (mentioned as defaulting to a dispatcher suitable for data source work, including references like “Dispatchers.IO” and terms that appear to be coroutine-related).
  • Accept a code block to run.
  • Execute the block inside withContext.
  • Return a generic type T (or potentially Result<T>, depending on the exact typing).
• The refactor aims to reduce each repository/data-source method to a single-line call.

Result-wrapping / runCatching

• The speaker discusses using runCatching in a “functional style” to safely handle exceptions.
• The approach returns a Result-based type rather than throwing directly.

---

Errors / troubleshooting explained

Type mismatch confusion

• A Kotlin compiler issue arises when:
  • one function returns Result<...>, but
  • the caller expects the plain generic type T (or vice versa).
• They reason about how nested runCatching + withContext layers affect the resulting type:
  • one layer may produce Result<R>,
  • while the caller expects R (or T).

Suspend vs non-suspend (coroutine scope)

• An error occurs from calling suspend functions from the wrong context.
• Key rule clarified:
  • the lambda passed to the higher-order function must be suspendable,
  • and the lambda must run within the coroutine scope provided by withContext.

Default dispatcher and correct parameter order

• Confusion occurs about parameter ordering (e.g., whether dispatcher comes first, then the block).
• The speaker also verifies what the function “thinks” the dispatcher is (again mentioning Dispatchers.IO in the subtitle).

---

Access control / visibility changes

Preventing repository layers from calling internal helpers

• Because the execution template helper is intended to be used only internally by the data source, the speaker wants restricted visibility.
• They attempt to make the template execution function protected/private so it can’t be called from repositories.
• Kotlin nuance:
  • interfaces don’t support protected the same way,
  • so they restructure the template as an abstract class to enable protected members.

---

Important design outcome

Replace per-method duplication with:

1. An abstract/base data source containing the shared coroutine + runCatching execution wrapper.
2. Each concrete method supplies only a suspend block describing the fetch/operation.
3. The wrapper runs with the correct dispatcher using withContext and returns a generic Result-based output.
4. Use abstract class + protected/private visibility to enforce correct usage boundaries.

---

Main speakers / sources

• Unnamed speaker (instructor/engineer teaching a Kotlin refactor)
• Mentions:
  • “Malik”, “Dima”, “Yara” (participants/questions/confirmation)
  • “Mr. Malik” (referenced by name)