AI is Lying to You (And How to Stop It)

Fri, 30 Jan 2026 00:00:00 +0000

Sometimes you don’t need an AI to be nice and agreeable and change its opinion with every new detail you share. You need it to tell you you’re overthinking something stupid.

This prompt turns off the politeness filter and forces the AI to roast your ideas, challenge your assumptions, and give you the straightforward answer you would get from an experienced mentor who has zero patience for bullshit and genuinely wants you to stop wasting time and succeed faster.

⚠️ WARNING: responses will be blunt, direct, and occasionally profane. Don’t use this if you are sensitive to harsh feedback.

# Brutal Honesty Mode

I need you to cut through politeness and give me brutally honest feedback.

## Your Task

1. **Challenge my assumptions** - Don't just agree with what I say
2. **Roast my ideas** - Point out when I'm overthinking, being precious, or chasing aesthetics over function
3. **Call out missing context** - If I'm not giving you critical information, tell me I'm wasting our time
4. **Push back on my constraints** - Question whether I actually need what I'm asking for
5. **Provide the boring/obvious answer** - Even if I said I don't want boring, tell me when boring is correct
6. **Use strong language** - Be direct, colorful, even profane if it drives the point home
7. **After roasting, give the actually good answer** - Not what makes me feel clever, but what actually works

## What I Don't Want

- Polite validation of my ideas
- "That's great!" followed by minor suggestions
- Hedging with "it depends" or "both could work"
- Treating my preferences as hard requirements
- Changing your opinion based on my reactions

## What I Do Want

- "This is stupid because..."
- "You're overthinking this, just do X"
- "Stop trying to be clever and..."
- Clear hierarchy: "This is best, this is okay, this is nonsense"
- Brutal prioritization of what actually matters vs. what's just ego

## Output Format

1. **Roast my idea/approach** (be specific about why it's flawed)
2. **Identify the real problem** (what I should actually be solving)
3. **Give the objectively better solution** (even if boring/obvious)
4. **Explain why it's superior** (function over form, results over feelings)
5. **Final recommendation** (one clear answer, no waffling)

**Remember:** I can handle harsh feedback. I'd rather feel stupid now than waste time on something stupid later.

Act like someone who's seen this mistake 100 times, has zero patience for bullshit, and genuinely wants me to succeed by not fucking around.

Just paste it at the end of your conversation, once you and the AI have agreed on what you are working on to switch into tough-love mode for raw, honest feedback. You won’t be disapointed.

p.s. ✌️ If you need support for your team or product, feel free to contact me via email. Let’s discuss your project.

Unplugged DI - DI.Y Basics

Sun, 06 Oct 2024 00:00:00 +0000

Intoduction

It all began with impatience. As I started a new project, I dreaded the prospect of selecting and configuring a dependency injection (DI) framework yet another time. Eager to dive straight into implementing the app, I decided to forgo the framework entirely. Here’s how that decision played out.

Why?

In the past, I’ve worked with various DI frameworks (Dagger, Hilt and Koin) and even created Magnet DI library 🙈, featuring automatic scoping detection and runtime scope inspection. However, I was never completely satisfied with any of them. Here are the key drawbacks observed:

Complexity. Steep learning curve, new abstraction to learn, configuration overhead, sometimes tedious resolution of build issues. Debugging generated code is often challenging.
Build time. Code generation adds overhead, particularly in multi-module projects, increasing the overall build time.
Startup time. Initializing the object graph and resolving dependencies can lead to slower startup times
Memory usage. The ease of singletons declaration lead to overuse, causing objects to stay in memory longer than intended.

What’s instead?

My ideal DI framework, if one were to exist, would have the following attributes:

Minimal to no learning curve. No extensive documentation or APIs to learn.
Simple mental model. It’s always obvious where and how to add or locate dependencies.
Build-time safety. No reflection and runtime magic, ensuring safety during compilation.
Explicit dependencies. No providers, no bindings, or other magical annotations.
Testability. Dependencies are easy to replace for testing purposes.

Ambitious? No doubts. With these thoughts in mind, and recalling this excellent post from the past (the topic is not new, after all), let’s dive in.

Mental model

The first step is to clearly outline the structure of our application. We need to identify its components and understand how they interact with one another. This will help us manage the dependencies effectively.

Modules

Modern apps often face challenges with increasing complexity. To manage this, developers usually break their applications into functional modules. These aren’t the same as project or Gradle modules, but rather abstract groups of related functionality. These functional modules can either be placed in separate Gradle modules or organized within different packages of the same Gradle module.

For example, consider an RSS reader app. The “RSS reader” module, which handles the main business logic, would rely on a “network” module for fetching RSS feeds and a “database” module for storing them locally. In this setup, the “RSS reader” module depends on both the “network” and “database” modules.

Contract

Up to this point, functional modules have been informal groupings of related functionality. But what if we formalize this natural separation and turn it into a contract? We can define a module interface for each group. This interface will serve as a contract between modules, outlining the functions a module offers to others.

Here’s how this could work in our RSS reader app:

interface NetworkModule {
    val httpClient: HttpClient // (1)
}

interface DatabaseModule {
    val database: Database // (2)
}

interface RssReaderModule {
    interface FetchRss {
        suspend operator fun invoke(url: String)
    }

    fun fetchRss(): FetchRss // (3)
}

For those familiar with DI frameworks, these interfaces might already look familiar. Let me clarify the contract we’ve created:

The val-properties declare functionality a module provides. The “network” module provides an instance of HttpClient (1) and the “database” module provides a database instance (2). Lifespan of the instances is the same as the lifespan of their modules.
The FetchRss interface declared inside the “RSS reader” module is here just for demo purposes. It can be declared somewhere in the module, not necessarily inside the module interface.
The fetchRss() function (3) is a factory function. Each time the function is called, it creates a transient instance of the FetchRss type. Transient means here that its lifespan isn’t bound to the lifespan of the module and is controlled by the consumer of the instance.

You may have noticed the absence of the “create” prefix in the factory method. This is intentional. Since all functions within a module interface are factory methods, omitting the prefix keeps the interface cleaner and more readable, making it easier to use.

Dependencies

Now that the contracts are defined, it’s time to implement them. This will reveal all dependencies between modules by making them explicit.

Module implementation primarily involves creating the necessary instances — there’s no business logic here. The only logic allowed should be related to instance creation and lifecycle management, such as lazy instantiation for caching. To keep things simple and reduce file clutter, the implementation is placed as an inner type within the module interface itself.

interface NetworkModule {
    val httpClient: HttpClient

    class Default : NetworkModule { // (1)
        override val httpClient: HttpClient by lazy ...
    }
}

interface DatabaseModule {
    val database: Database

    class Default : DatabaseModule { // (2)
        override val database: Database by lazy ...
    }
}

interface RssReaderModule {
    fun fetchRss(): FetchRss

    class Default( // (3)
        private val networkModule: NetworkModule,
        private val databaseModule: DatabaseModule,
    ) : RssReaderModule {
        override fun fetchRss(): FetchRss ...
    }
}

Using the by lazy construct allows for the lazy initialization of modules, which can improve startup time. If needed, the val-properties can be initialized immediately.

The constructors of the “network” (1) and “database” (2) modules don’t take any parameters, meaning they have no external dependencies, and all objects they create are self-contained within their respective modules.
The constructor of the “RSS reader” (3) module, however, accepts instances of the “network” and “database” modules, indicating its dependency on these two modules. This is how dependencies between modules are declared.

It’s important to note that a module should only depend on other modules, not on specific instances provided by them. This serves two key purposes:

It keeps the constructor clean, readable, and maintainable;
It establishes two layers of dependency management: higher-layer dependencies between modules, and lower-layer dependencies between instances.

The lower-layer dependencies are only permitted within their respective higher-layer inter-module dependencies.

This approach is extremely helpful for understanding and managing the overall structure of the application. By focusing on the higher-layer first, you already know what dependencies your instances do or don’t have. Additionally, with moderate effort, this setup allows for easy code analysis and the visualization of module dependencies in a diagram.

Dependency Injection

We’ve reached the fun part — actual dependency injection. Let’s implement the FetchRss interface and inject the HttpClient and Database dependencies.

class DefaultFetchRss( // (1)
    private val httpClient: HttpClient,
    private val database: Database,
) : FetchRss {
    override suspend fun invoke(url: String) {
        val rss = httpClient.get(url)
        database.upsert(rss)
    }
}

interface RssReaderModule {
    fun fetchRss(): FetchRss

    class Default(
        private val networkModule: NetworkModule,
        private val databaseModule: DatabaseModule,
    ) : RssReaderModule {

        override fun fetchRss(): FetchRss =
            DefaultFetchRss( // (2)
                httpClient = networkModule.httpClient,
                database = databaseModule.database,
            )
    }
}

There’s nothing complicated here; the process is straightforward. The implementation’s constructor (1) takes HttpClient and Database instances as parameters. The fetchRss() factory method (2) retrieves these dependencies from their respective modules and passes them to the constructor. That’s all.

Any other instance will be injected in exactly the same way. The only difference is where the instance is sourced from.

Field injection and method injection are neither supported nor recommended. Field injection breaks encapsulation, while method injection relies on lateinit, which can lead to runtime failures. The only proper way to inject instances is through the constructor.

If you encounter a circular dependency, the first solution is to add another module interface to break the circle. If that’s not feasible, you can use a provider function as a parameter, such as val httpClient: () -> HttpClient.

Launch it!

Now it’s time to bring everything together and call the FetchRss function from our app. Speaking of which, let’s create an “application” module that holds all the other modules. This will serve as our “assemblage point”, as Don Juan would say.

interface AppModule {
    val rssReaderModule: RssReaderModule

    class Default : AppModule {
        override val rssReaderModule: RssReaderModule by lazy {
            RssReaderModule.Default(
                networkModule = networkModule,
                databaseModule = databaseModule,
            )
        }

        // private modules

        private val networkModule: NetworkModule by lazy {
            NetworkModule.Default()
        }

        private val databaseModule: DatabaseModule by lazy {
            DatabaseModule.Default()
        }
    }
}

Using the module hierarchy we’ve built is as simple as this:

fun main() {
    val appModule = AppModule.Default()
    val fetchRss = appModule.rssReaderModule.fetchRss()

    runBlocking {
        fetchRss("https://www.halfbit.de/index.xml")
    }
}

Wrap up

There’s much more to explore about this approach, but I’ll save that for another time. Thank you for making it this far — you’re awesome! I truly appreciate your time and hope you found something valuable. This concludes part I — stay tuned for more and happy coding 🖖

Upcoming topics:

Injection for Android: App, Activity, Fragment, Service, ContentProvider etc.
Injection for Multiplatform: platform-specific implementations
Module initialization
Naming and organization of module interfaces
Writing test modules
Functions for providing in maps and lists

p.s. ✌️ If you need support for your team or product, feel free to contact me via email. Let’s discuss your project.

External Events in Knot

Tue, 07 Jul 2020 00:00:00 +0000

Introduction

In this post you will learn how to observe and handle external Events in Knot. If you are new to Knot library, it would make sense to get to know its basic concepts before you continue reading.

💦 Event Source

Each knot instance has the ability to subscribe for external events and turn them into changes for further processing in the reducer. This feature is useful for observing changes in database, user location updates or other external triggers.

Events can be delivered to Knot using an instance of the Observable type, which I will refer to as an event source from here on. Events-section is the place where the knot instance subscribes to the event sources and maps events into changes.

val userLocation: Observable<Location>

knot<State, Change, Action> {
    events {
        source {
            userLocation.map { Change.UpdateLocation(it.lat, it.lng) }
        }
    }
    changes {
        reduce { change ->
            when(change) {
                Change.UpdateLocation -> handle...
            }
        }
    }
}

In the code snippet above each Location event is turned into an Change.UpdateLocation. Knot takes the change and delivers it to the reducer, where the actual event-handling logic resides.

Lifecycle

A knot instance subscribes to its event sources right after the instance is created and stays subscribed to the event sources until the instance is disposed. If a CompositeKnot is used, the knot instance subscribes to its event sources right after compose() method was called.

In this respect, the knot instance and its event sources share the same lifecycle.

Initialization Events

The fact that events sources are subscribed when their knot instance is created can be used for emitting a one-time initialization event.

In the code snippet below, the Change.Initialize is emitted just once, right after the knot instance is created. Reducer can implement whatever initialization logic is needed like loading initial data, for example.

knot<State, Change, Action> {
    events {
        source {
            Observable.just(Change.Initialize)
        }
    }
    changes {
        reduce { change ->
            when(change) {
                Change.Initialize -> initialize...
            }
        }
    }
}

🧊 Cold Event Source

A continuous subscription described above can be expensive when it is applied to a resource- or power-critical event source.

For example, a continuous subscription to the user location event source on mobile devices can increase power consumption. If we have a view, which is bound to the knot instance with such subscription, and the view becomes invisible, then the knot instance will continue receiving user location updates and ⚡️consuming power in background.

We have to fix this. Our knot instance should

unsubscribe from the event source when the view becomes invisible
and re-subscribe when the view becomes visible.

Fortunately, Knot supports this kind of scenarios. It has a special event source called coldSource 🥶 which subscribes to the underlying observable when the first observer of knot.state subscribes and unsubscribed from the underlying observable when the last observer of knot.state unsubscribes. It is somehow similar to how RefCount operator works.

Let’s make the user location’s observer example power consumption aware. We just need to replace source 💦 with coldSource 🧊 and keep the rest of the implementation unchanged.

knot<State, Change, Action> {
  events {
--  source {
++  coldSource {
            userLocation.map { Change.UpdateLocation(it.lat, it.lng) }
        }
    }
}

Now, when the view becomes invisible and unsubscribes from the State, the knot instance will unsubscribe from the user location event source as well. When the view becomes visible again and subscribes to the State, the knot instance will re-subscribe to the event source anew.

Here are some of the scenarios where usage of coldSource is rather desirable:

observe user location
observe database changes
observe Firebase changes.

Refresh Events

Similar to how we provided Observable.just() to source for emitting initialization events, we can provide it to coldSource for emitting so-called refresh events. As you already know, those events will be emitted each time the first observer subscribes to the State.

knot<State, Change, Action> {
    events {
        couldSource {
            Observable.just(Change.Refresh)
        }
    }
    changes {
        reduce { change ->
            when(change) {
                Change.Refresh -> refresh...
            }
        }
    }
}

We can use this event for fetching fresh data from the server and update the view each time the user switches to our app and the view becomes visible.

Wrap-up

I hope you find external Events in Knot useful and this post gives you an idea of when and how to use them in you apps. Have fun and happy coding! ✌️

Async Actions in Knot

Tue, 16 Jun 2020 00:00:00 +0000

Introduction

In this post you will learn how to perform and cancel asynchronous Actions in Knot. If you are new to Knot library, it would make sense to get to know its basic concepts before continue reading.

Adding Actions

Asynchronous Actions in Knot are used for performing asynchronous tasks like making network calls or accessing a database.

The process of adding an action consists of three steps:

declaring the action type;
scheduling the action in the reduce-section;
performing the action in the perform-section.

Here is the code snippet, in which we declare, schedule and perform a Load action.

sealed class Action {
    object Load : Action()
}

knot<State, Change, Action> {
    changes {
        reduce { change ->
            when(change) {
                Change.Load -> State.Loading + Action.Load
            }
        }
    }
    actions {
        perform<Action.Load> {
            // omitted for brevity
        }
    }
}

Scheduling happens in the reducer - when returning a new state from the reducer, we just add the action to the state using plus operator. Knot will do the rest and provide the action to the corresponding perform-section.

Performing Actions

Perform-section contains the code responsible for performing the asynchronous action and delivering the result back to the reducer.

It is a good practice to extract the actual implementation of a asynchronous task from the knot declaration and store it in a separate file. This keeps knot declaration clean. Here is how we can do it for the Load action.

interface LoadItemsAction {
    operator fun invoke(): Single<Data>
    data class Data(val items: List<String>)
}

class DefaultLoadItemsAction(
    private val repository: ItemsRepository
    private val ioScheduler: Scheduler = Schedulers.io()
) : LoadItemsAction {
    override fun invoke(): Single<Data> =
        repository.loadItems()
            .map { it.toData() }
            .subscribeOn(ioScheduler)
}

Now we can call the implemented Load action and map the result of the action into Changes. This is needed for delivering the results back to the reducer, where we can update the state.

perform<Action.Load> {
    flatMapSingle {
        loadItems()
            .map { Change.Load.Success(it.payload) }
            .onErrorReturn { Change.Load.Failure }
    }
}

Notice the flatMapSingle operator in the snippet above. This operator controls how multiple actions are handled, when we send them to the perform-section.

FlatMap

By using the flatMapSingle operator, we instruct Knot to perform all actions independent of each other. Each new action will be started immediately. Because the operator does not care about the order of the items, the actions will emit their resulting Changes as soon as they are performed. Thus, the result Changes of different actions may interleave.

This operator is safe to use when the number of Actions running in parallel is controlled in the reducer.

In our example, we schedule the Load action and also move the state machine into State.Loading, where all subsequent Change.Load requests are ignored. We are on the safe side here, because we guarantee that the Load action will be performed exactly once at a time.

ConcatMap

If the order of performed actions is important, then the concatMapSingle operator should be used. A use case for it could be some kind of a Store action, which adds a new entry to the database each time the action is performed.

SwitchMap

As the operator suggests, when switchMapSingle is used, each newly scheduled action will cancel previously scheduled action, if the latter is still running.

This operator is used when we want to ensure that a single action runs at a time and we allow a new action to cancel the previous one. We can also use it for implementing cancellable actions, which we will cover in the next section in more details.

Cancelling Actions

When the knot instance is not needed anymore - for example, when its hosting ViewModel gets cleared - we should explicitly dispose that knot instance by calling knot.dispose() method. Disposed knot instance cancels all running actions, ensuring that everything is cleaned up and no resources are leaked.

Sometimes, however, we will need to cancel just a single running action without disposing the whole knot instance. This can be achieved by using already mentioned switchMapSingle operator, thanks to its ability to unsubscribe from the previous Single, when a new Single is generated. What we need to do is send an additional cancellation flag with the action to the switchMapSingle operator and return a no-operation Single from the operator, if the cancellation flag was set. Returned no-operation Single will unsubscribe and dispose previously launched loading Single, which is exactly what we wanted to achieve.

Here is the implementation of this approach.

sealed class Action {
    data class Load(val cancel: Boolean = false) : Action()
}

knot<State, Change, Action> {
    changes {
        reduce { change ->
            when(change) {
                Change.Load -> when(this) {
                    State.Empty -> State.Loading + Action.Load()
                    else -> only
                }
                Change.Cancel -> when(this) {
                    State.Loading -> State.Empty + Action.Load(cancel = true)
                    else -> only
                }
                Change.Load.Success -> when(this) {
                    State.Loading  -> State.Content(change.payload)
                    else -> only // ignore, action was cancelled
                }
                ...
            }
        }
    }
    actions {
        perform<Action.Load> {
            switchMapSingle { action ->
                if (action.cancel) Single.never()
                else {
                    loadItems()
                        .map { Change.Load.Success(it.payload) }
                        .onErrorReturn { Change.Load.Failure }
                }
            }
        }
    }
}

Wrap-up

I hope this post was helpful for you and you can master asynchronous Actions in Knot with ease now.

Practice more and happy coding! ✌

Composite ViewModel

Fri, 05 Jun 2020 00:00:00 +0000

Introduction

Recently, my team and me worked on an Android application where MVVM + State Container + Unidirectional Data Flow were the patterns of choice. With more and more requirements coming in, some of the view models however became really big and complex and that often lead to poor code readability.

In addition of being hard to read, these view models often violated the separation of concerns and open-closed principles, because each new feature that was added to a screen also added a new concern to the accompanying view model class, making it even bigger and harder to deal with.

In this post I will show you the technique we used to make such view models extensible, maintainable and fun to develop.

Monolith

The architecture of the app was simple, yet effective at the same time. The ViewState object represented the state of a screen. The ViewModel received events from the View, created a new modified copy of the ViewState and returned it back to the View, which then rendered it. The same cycle of events happened again and again.

Notice that arrows in the diagram depict the data flow, not the dependencies between the components. The app architecture allowed the View to have a dependency to the ViewModel, but not the other way around. The ViewState was implemented as an observable property of the ViewModel.

As you can see, adding new features to the View made ViewModel more complex, too, and - after some time - extending and maintaining the monolithic ViewModel was a tough task.

Breaking the Monolith

We saw a clear need for breaking the ViewModel up into smaller pieces, where each piece would be responsible for a certain feature or concern, and that piece could be added or removed independently. The idea worked well. We extracted pieces of the ViewModel into small classes that we called view model delegates, or just Delegates for short.

Each Delegate in this design acts as a mini ViewModel - it handles events and creates a new ViewState. The main difference to a regular ViewModel is that a Delegate receives and handles only the events related to the concern it implements. Thus, for instance, when adding a new button to the screen, we would also add a new Delegate responsible for maintaining the events and the state of that button, but keeping the main ViewModel unchanged.

As you might notice, the only shared thing between the Delegates is the ViewState. In all other aspects Delegates are independent.

Thus the actual responsibility of the ViewModel shifts from handling events and maintaining the state into dispatching the right events to the right delegates.

Practice

The composition technique described above is simple enough and can be implemented with virtually any state container library out there, or even without one. In the code examples of this post I will use Knot, a library supporting this kind of view model composition off the shelf.

Modeling ViewState

I am going to practice the composition technique by implementing a single-screen application, capable of loading a list of books. The app will start with an Empty state, then go through a Loading state into either a Content state with a list of books, or an Error state showing an error message.

These states can be modeled using a sealed class as shown below.

sealed class State {
    object Empty : State()
    object Loading : State()
    data class Content(val books: List<Book>) : State()
    data class Error(val message: String) : State()
}

Modeling Events

There are just two events the View can send to the ViewModel. These are the Load and Clear events, which can also be modelled using a sealed class.

sealed class Event {
    object Load : Event() // tap to load, try again and reload
    object Clear : Event()
}

Declaring ViewModel

Once ViewState and events are modelled, the ViewModel can be declared as follows.

abstract class BooksViewModel : ViewModel() {
    abstract val state: Observable<State>
    abstract val event: Consumer<Event>
}

Observable and Consumer are the RxJava types. The View will observe changes happening to the ViewState and send Events to the consumer.

Monolithic ViewModel

I have everything prepared for implementing the ViewModel. As mentioned above, I will use the Knot library for that. The library lets us declare a state machine and a set of changes for modifying its state.

For the sake of brevity I omitted details like converting events into changes and the implementation of the loading action in the code snippets below. Check out the Knot samples (monolithic) to see the complete code in action.

Here is my monolithic view model, which handles all the events.

class MonolithicBooksViewModel : BooksViewModel() {

    override val state: Observable<State>
    	get() = knot.state

    override val event: Consumer<Event> =
        Consumer<Event> { knot.change.accept(it.toChange()) }

    private val knot = knot<State, Change, Action> {
        state { initial = State.Empty }
        changes {
            reduce { change ->
                when (change) {
                    Change.Load -> when (this) {
                        State.Empty,
                        is State.Content,
                        is State.Error -> State.Loading + Action.Load
                        else -> only
                    }
                    is Change.Load.Success -> when (this) {
                        State.Loading -> State.Content(change.books).only
                        else -> unexpected(change)
                    }
                    is Change.Load.Failure -> when (this) {
                        State.Loading -> State.Error(change.message).only
                        else -> unexpected(change)
                    }
                    Change.Clear -> when (this) {
                        is State.Content -> State.Empty.only
                        is State.Empty -> only
                        else -> unexpected(change)
                    }
                }
            }
        }
        actions { ... }
    }
}

Even though the code is pretty well structured, you should be able to imagine how complex it can become when more features are added to the screen.

Composite ViewModel

If we look closer, we will recognize two separate concerns that we can extract from the MonolithicBooksViewModel - loading and clearing. I am going to extract those into two separate delegate classes now.

Firstly, I need to make the ViewModel extensible. This can be achieved by declaring a delegate interface allowing delegates to receive events and change the state. Here is my interface.

interface Delegate {
    fun CompositeKnot<State>.register()
    fun CompositeKnot<State>.onEvent(event: Event): Boolean
}

Now the ViewModel should be able to receive a list of delegates in its constructor and delegate work to them. By doing so, new delegates can be added to the list without the necessity to modify the actual ViewModel.

class CompositeBooksViewModel(
    private val delegates: List<Delegate>
) : BooksViewModel() {

    override val state: Observable<State>
        get() = knot.state

    override val event: Consumer<Event> =
        Consumer<Event> { event ->
            delegates.any {
                with(it) { knot.onEvent(event) }
            }
        }

    private val knot = compositeKnot<State> {
        state { initial = State.Empty }
    }

    init {
        for (delegate in delegates) {
            with(delegate) { knot.register() }
        }
        knot.compose()
    }
}

As you can see, the only remaining logic of the state machine is to set the initial state. The actual functionality will be moved into the delegates and here they are.

class ClearButtonDelegate : Delegate {
    override fun CompositeKnot<State>.register() {
        registerDelegate<Change, Nothing> {
            changes {
                reduce<Change.Clear> { change ->
                    when (this) {
                        is State.Content -> State.Empty.only
                        is State.Empty -> only
                        else -> unexpected(change)
                    }
                }
            }
        }
    }
}

class LoadButtonDelegate : Delegate {
    override fun CompositeKnot<State>.register() {
        registerDelegate<Change, Action> {
            changes {
                reduce<Change.Load> {
                    when (this) {
                        State.Empty,
                        is State.Content,
                        is State.Error -> State.Loading + Load
                        else -> only
                    }
                }
                reduce<Change.Load.Success> { change ->
                    when (this) {
                        State.Loading -> State.Content(change.books).only
                        else -> unexpected(change)
                    }
                }
                reduce<Change.Load.Failure> { change ->
                    when (this) {
                        State.Loading -> State.Error(change.message).only
                        else -> unexpected(change)
                    }
                }
            }
            actions { ... }
        }
    }
}

Omitted implementation details can be found in the fully functional example of the composite ViewModel in Knot samples (composite).

Here we go! We had a monolithic ViewModel, and then we turned it into an extensible ViewModel and two independent Delegates.

Wrap-up

The composition technique described in the post saved many hours of work in my recent project and I hope you will find it useful as well. The biggest composite ViewModel I’ve written had about 30 delegates and handled dozens of events in 3 states. That was a hero screen which nonetheless was perfectly maintainable and extensible.

Try it out, improve it, practice more and have fun! ✌️

p.s. ✌️ If you need support for your team or product, feel free to contact me via email. Let’s discuss your project.

Magnet DI, Developer Guide

Sun, 08 Jul 2018 17:23:00 +0200

Minimalist and fast dependency injection library for Android.

Disclaimer and support

Magnet is fully open source and available under Apache License, Version 2.0 at https://github.com/sergejsha/magnet.

It is provided for free, without any kind of support. If you consider using Magnet in your commercial product and you need additional support or training, feel free to contact me.

Motivation

Why create another dependency injection library? Here are the objectives Magnet tries to pursue better that the others:

Simplicity. Magnet is based on just two simple concepts - scopes and instances. They are extremely easy-to-use and require almost no configuration (except for declarative annotations and creation of scopes).
Non-intrusive API. Your code should know very little to nothing about the injection framework it uses. Magnet tries to achieve this by generating helper code and transparently executing it.
Constructor Injection. Magnet enforces constructor injection. It requires declaration of a single constructor with dependencies, which improves encapsulation and protects the integrity of those dependencies at compile time.
Dependency inversion. When used in multi-module projects, Magnet is capable of injecting instances provided by any module, even if there is no build-time dependency between providing and consuming modules. This enforces clean and extensible software design.
Concise implementation. Magnet shrinks amount of supported features to the absolute minimum required. This helps to keep the method count to a minimum.

Getting started

Step 1: Configure project

To use Magnet in your project, include it as a dependency into your build.gradle file.

Kotlin

dependencies {
    api 'de.halfbit:magnet-kotlin:2.3'
    kapt 'de.halfbit:magnet-processor:2.3'
}

Java

dependencies {
    api 'de.halfbit:magnet:2.3'
    annotationProcessor 'de.halfbit:magnet-processor:2.3'
}

Releases of Magnet are published to mavenCentral() repository.

Step 2: Initialize Magnet

Create an empty marker interface in your main application module and annotate it. If you have a single-module application, just add it to that module. This one-time initialization will trigger generation of all needed helper code.

@Magnetizer
interface AppMagnetizer

@Magnetizer
interface AppMagnetizer {}

Step 3: Write and annotate application classes

Start wring classes needed for implementing your application and let Magnet know how to instantiate them by applying @Instance annotation.

// Repository.kt

interface Repository {
    fun getHelloMessage(): String
}

@Instance(type = Repository::class)
internal class DefaultRepository(): Repository {
    override fun getHelloMessage() = "Hello Magnet!"
}

// Presenter.kt

@Instance(type = Presenter::class)
class Presenter(private val repository: Repository) {
    fun presentHelloMessage() {
        println(repository.getHelloMessage())
    }
}

// Repository.java

interface Repository {
    String getHelloMessage();
}

// DefaultRepository.java

@Instance(type = Repository.class)
class DefaultRepository implements Repository {
    @Override
    public String getHelloMessage() {
        return "Hello Magnet!";
    }
}

// Presenter.java

@Instance(type = Presenter.class)
class Presenter {
    private Repository repository;

    Presenter(Repository repository) {
        this.repository = repository;
    }

    public void presentHelloMessage() {
        System.out.println(repository.getHelloMessage());
    }
}

In the example above we define a Repository interface and its DefaultRepository implementation. Annotation @Instance(type = Repository::class) instructs Magnet to create an instance of DefaultRepository when a new instance of Repository type gets requested. Presenter class declares a dependency of Repository type. Its annotation @Instance(type = Presenter::class) says, that Magnet needs to create new instance of Presenter when a new instance of Presenter type gets requested.

Step 4: Create scope and inject objects

Now it’s time for glueing everything together and let Magnet creating and providing us with all instances needed. Magnet does it through a scope.

Create root scope and request instances of application classes.

val scope = Magnet.createRootScope()
val presenter: Presenter = root.getSingle()
presenter.presentHelloMessage()

Scope scope = Magnet.createRootScope();
Presenter presenter = scope.getSingle(Presenter.class);
presenter.presentHelloMessage();

Magnet will create instance of Presenter and Repository for you. Respecting the configuration above, Magnet will create an instance of DefaultRepository and inject it into Presenter’s constructor automatically.

Documentation

Scopes and Instances

Magnet retains created instances in scopes. On other words a scope is a container for instances. Instance’s lifespan corresponds to the lifespan of the scope it belongs to. Thus, for example, if you have a scope which lives forever, all instances inside this scope will also live forever.

Creation and initialization of scope

At first you need to create a scope. Newly created scope is empty and has no instances. Magnet adds instances to the scope as your application requests them. If you want to pre-fill the scope with some instances right away - those can be some system-provided instances like Context in Android - then you can bind those instances into the scope programmatically.

val scope = createRootScope() {
    bind<Context>(this@App)
    bind(LayoutInflater.from(this@App))
}

Scope scope = Magnet.createRootScope()
    .bind(Context.class, this)
    .bind(LayoutInflater.class, LayoutInflater.from(this));

In the example above we create a root scope (the scope without a parent) and bind this instance though Context type and an instance of layout inflater through LayoutInflater type. Now, when an instance of Context type gets requested in the scope, Magnet will return this instance back.

Getting scope instances

Once scope is created we can start requesting instances from it. Instances get requested from the scope by type. Type is a class or interface which requested instance must implement. This is the same type we used in @Instance annotation and when we bound instances into the scope.

In the example below we request an instance of Presenter type from the scope.

// main
val presenter: Presenter = scope.getSingle()

// Presenter.kt
interface Presenter {
    fun present()
}

// main
Presenter presenter = scope.getSingle(Presenter.class);

// Presenter.java
interface Presenter {
    void present();
}

When scope instance is requested, Magnet does the following:

It checks the scope for requested instance by its type and, if the instance was found, Magnet returns it back.
If instance wasn’t found, Magnet will use @Instance-annotated classes of requested type to create the instance and to bind it into the scope. Then the instance gets returned back.

Code above requests an instance of Presenter type, which has no implementation yet. If you execute this code, it will fail. Next sections describes how to let Magnet know which implementation of Presenter type should be used, which an instance of Presenter type is requested.

Instance annotation

Annotating instance implementations is basically the main development effort related to usage of Magnet. By applying @Instance annotation to implementation classes your instruct Magnet which class to use when instance of certain type is requested.

In the example below we implement Presenter interface and annotate the implementation.

@Instance(type = Presenter::class)
internal class DefaultPresenter(
    private val layoutInflater: LayoutInflater
) : Presenter {

    override fun present() {
        layoutInflater.inflate(...)
        ...
    }
}

@Instance(type = Presenter.class)
class DefaultPresenter implements Presenter {
    private final LayoutInflater layoutInflater;

    DefaultPresenter(LayoutInflater layoutInflater) {
        this.layoutInflater = layoutInflater;
    }

    @Override public void present() {
        layoutInflater.inflate(...);
        ...
    }
}

Once DefaultPresenter class gets processed by Magnet’s annotation processor, Magnet will be able to instantiate it when scope instance of Presenter type gets requested.

Instance factory methods

Sometimes you will need to instantiate third-party implementations which cannot be annotated by you. For this purposes Magnet supports annotation of static methods, which serve as instance factories. The example below demonstrates how you can provide an instance of SharedPreferences class using a static method.

@Instance(type = SharedPreferences::class)
fun provideGlobalSharedPreferences(context: Context)
    : SharedPreferences = PreferenceManager
        .getDefaultSharedPreferences(context)

class SharedPreferencesProvider() {

    @Instance(type = SharedPreferences.class)
    public static SharedPreferences provide(Context context) {
        return PreferenceManager
            .getDefaultSharedPreferences(context);
    }
}

Using Classifier

When type alone is not enough to differentiate between two implementations and you need a more fine-grained type classification, you can use classifier. Classifier is an additional differentiator inside the same type.

It can be used, for instance, to differentiate between Application and Activity contexts. Both implement the same Context type, but after applying a classifier Magnet can easily provide one or another instance upon request.

// Activity.kt

const val ACTIVITY = "activity"
const val APPLICATION = "application"

// bind context
val activity = this
val scope = createRootScope() {
    bind<Context>(activity, ACTIVITY)
    bind<Context>(activity.applicationContext, APPLICATION)
}

// Renderer.kt

@Instance(type = Renderer::class)
internal class Renderer(
    @Classifier(ACTIVITY) val activityContext: Context,
    @Classifier(APPLICATION) val applicationContext: Context
)

At this point you might have been used to Kotlin syntax already. Thus all the other code snippets will be written in Kotlin only ;)

Instance cardinalities

Magnet is capable of injecting instances in three different cardinalities: optional, single and many.

Optional

Optional cardinality corresponds to zero or one instance. If your app can handle a case, when instance cannot be provided by Magnet (e.g. there is no implementation available), then you should use this cardinality.

Request optional from scope:

val context: Context? = scope.getOptional<Context>()

Request optional though dependency:

@Instance(type = Renderer::class)
internal class Renderer(
    val context: Context?
)

If Magnet cannot find an instance, it will inject null. If however there are more than one instance found, Magnet will fail injection.

When used with Java, Magnet respects @Nullable annotations if provided for enforced nullability.

Single

Single cardinality corresponds to exactly one instance. This is the most commonly used cardinality. If your app requires exactly one instance of a type to be provided by Magnet, you should use this cardinality.

Request single from scope:

val context = scope.getSingle<Context>()

Request single though dependency:

@Instance(type = Renderer::class)
internal class Renderer(
    val context: Context
)

If Magnet does not find requested instance or finds more than one instance, Magnet will fail injecting the value.

Many

Many cardinality corresponds to zero or more instances. If you expect zero or more instances of certain type to co-exist in your app, then this is the cardinality of choice.

Request many from scope:

interface MenuItem

val menuItems = scope.getMany<MenuItem>()

Request many though dependency:

@Instance(type = Renderer::class)
internal class Renderer(
    val menuItems: List<MenuItem>
)

The code above will inject all instances of MenuItem available in app. For instance, if you write a new application module and declare a new implementation of MenuItem for Magnet, new menu item will be available in the list right after the app gets recompiled and launched.

As you can see the cardinality uses List as container for instances. This imposes some restrictions on injection of List instances in Magnet. You cannot bind List type into scopes. Neither can you provide instances of List type. You should use custom classes instead. List type is reserved for many cardinality.

Scope hierarchies

The most power of Magnet can be gained by using hierarchical scopes. Each scope in Magnet can have an optional relation to a parent scope. If a parent relation is present, a scope hierarchy gets build up. The scope hierarchy can be any deep, but I suggest to keep it as flat as needed.

class App : Application() {

    override fun onCreate() {
        super.onCreate()
        scope.apply {
            bind(applicationContext, APP_CONTEXT)
            bind(contentResolver)
        }
    }

    companion object {
        val scope: Scope = Magnet.createRootScope()
    }
}

class PlayerActivity : Activity() {

    private lateinit var scope: Scope

    override fun onCreate(savedInstanceState: Bundle?) {
        val activity = this
        scope = App.scope.createSubscope {
            bind<Resources>(activity.resources)
            bind<Activity>(activity)
            bind<LifecycleOwner>(activity)
            bind(LayoutInflater.from(activity))
            bind(act.supportFragmentManager)
        }
    }
}

Parent scope does never know it is a parent scope, because it does not hold any references to its children. Parent relation allows instances kept in a child scope accessing instances of its parent scope or even parent’s parent scope up to the root.

This leads us to the following observations:

Scope keeps instances with the same lifespan together.
Parent scope does always have a longer lifespan than any of its child scopes.
Child scopes (with all their instances) can be created and destroyed without any impact on their parent scopes.

Such design fits the nature of Android applications very well. For instance, we can distinguish the following Android application scopes and put them into a hierarchy:

Application scope
Activity scope
Fragment scope
RecyclerView section scope
etc.

Application scope gets created on application start and lives as long as out app lives. Activity scope is a child of Application scope. It gets created and destroyed as user navigates from one activity to another through the application. The same happens to the other scopes.

Instances retained in Activity scope can access instances retained in Application scope. For example a Presenter from Activity scope can access NetworkManager from Application scope.

Scoping rules

Until now we learned how to bind instances into a scope. We also mentioned, that after Magnet creates a new instance it puts this instance into a scope. Scoping rules are exactly the rules Magnet applies when it puts instance into a scope.

After the instance is created, Magnet has to choose between the following options: retain the instance in scope or don’t retain. If first option is selected, there is another decision to make - in which exactly scope to retain it, because we have a scope hierarchy as you remember.

There is three scoping rules you can apply to instances for enforcing desired behavior.

Unscoped

Scoping.UNSCOPED is used when Magnet has to create new instances each time when instance is requested. The behavior is similar to usage of standard instance factory - each time instance is requested, each time Magnet create a new instance.

@Instance(
    type = PlayerViewModel::class,
    scoping = Scoping.UNSCOPED
)
internal class PlayerViewModel : ViewModel()

Direct

Scoping.DIRECT is used when Magnet has to bind created instance directly into the scope, from which this instance has been requested.

@Instance(
    type = ViewHolderProvider::class,
    scoping = Scoping.DIRECT
)
internal class SectionViewHolderProvider(
    private val layoutInflater: LayoutInflater,
    private val resources: Resources
) : ViewHolderProvider

Given the following scope hierarchy Fragment ➜ Activity ➜ App let’s see the behavoir of this scoping rule depending on initial and follow up requests.

Initially requesting from App scope. Magnet retains instance in App scope.
- Follow up request to Activity scope will return the instance retained in App scope, because Magnet will search scope hierarchy up and find the instance.
- Follow up request to Fragment scope will return the instance retained in App scope, because Magnet will search scope hierarchy up and find the instance.
Initially requesting from Activity scope. Magnet retains instance in Activity scope.
- Follow up request to App scope will create a new instance and retain it in App, because Magnet was not able to find the instance in scope hierarchy.
- Follow up request to Fragment scope will return the instance retained in Activity scope, because Magnet will search scope hierarchy up and find the instance.
Initially requesting from Fragment scope. Magnet retains instance in Fragment scope.
- Follow up request to App scope will create a new instance and retain it in App, because Magnet was not able to find the instance in scope hierarchy.
- Follow up request to Activity scope will return the instance retained in App scope, because Magnet will search scope hierarchy up and find the instance.

You should use Scoping.DIRECT when you want to keep instances in scope, but you don’t want to ‘inject’ them to the parent scope, which is possible when the next scoping rule is used.

Top Most

Scoping.TOPMOST is the default scoping rule instructing Magnet to find the top most scope for the requested instance, where all dependencies of the instance can still be satisfied.

We have same Fragment ➜ Activity[Resources] ➜ App scope hierarchy, but this time Activity scope has an instance of Resources bound into it.

Given the following classes, Magnet will inject UserInteractor and Presenter as following.

interface UserInteractor

@Instance(
    type = UserInteractor::class,
    scoping = Scoping.TOPMOST
)
internal class DefaultUserInteractor() : UserInteractor

@Instance(
    type = Presenter::class,
    scoping = Scoping.TOPMOST
)
class Presenter(
    private val resources: Resources,
    private val userInteractor: UserInteractor
)

Request Presenter from Fragment scope. Resulting scope hierarchy looks like Fragment ➜ Activity[Resources, Presenter] ➜ App[DefaultUserInteractor]
- Magnet retains instance of DefaultUserInteractor in App scope because DefaultUserInteractor has no dependencies and its top most scope is the root scope of scope hierarchy.
- Magnet retains instance of Presenter in Activity scope, because is has two dependencies: Resources and UserInteractor. The top most scope where both dependencies are reachable is the Activity scope.

Note: If we destroy Fragment scope and create a new Fragment2 scope then the hierarchy will look like this.

Fragment2 ➜ Activity[Resources, Presenter] ➜ App[DefaultUserInteractor].

Magnet keeps Activity and App scopes pre-filled with instances and another request of Presenter instance from Fragment2 scope will return same instance Magnet has already created when initial Fragment scope existed.

Request Presenter from Activity scope. The resulting scope hierarchy looks exactly like in case 1.
Request Presenter from Application scope. Magnet will fail injecting, because Presenter’s dependency on Resources cannot be satisfied.

Best practices

My implementation class has at least one optional dependency.
- Scoping.DIRECT or Scoping.UNSCOPED would be safe options there because top most scoping might place your instance in different scopes depending on whether optional dependency instance is present or not.
I want to inject fields into my activity (fragment, component etc.)
- Magnet does not support field injection by design. Create an unscoped holder class declaring instances you want to inject as dependencies and request it from the scope. Required instances will be injected into you holder class.

@Instance(
    type = InstanceHolder::class,
    scoping = Scoping.UNSCOPED
)
internal class InstanceHolder(
    val imageLoader: ImageLoader,
    val networkInteractor: NetworkInteractor
)

// MyActivity.kt

private lateinit var activityScope: Scope
private lateinit var holder: InstanceHolder

override fun onCreate(savedInstanceState: Bundle?) {
    super.onCreate(savedInstanceState)

    activityScope = appScope.createSubscope()
    holder = activityScope.getSingle()
}

AI is Lying to You (And How to Stop It)

Unplugged DI - DI.Y Basics

Intoduction

Why?

What’s instead?

Mental model

Modules

Contract

Dependencies

Dependency Injection

Launch it!

Wrap up

External Events in Knot

Introduction

💦 Event Source

Lifecycle

Initialization Events

🧊 Cold Event Source

Refresh Events

Wrap-up

Async Actions in Knot

Introduction

Adding Actions

Performing Actions

FlatMap

ConcatMap

SwitchMap

Cancelling Actions

Wrap-up

Composite ViewModel

Introduction

Monolith

Breaking the Monolith

Practice

Modeling ViewState

Modeling Events

Declaring ViewModel

Monolithic ViewModel

Composite ViewModel

Wrap-up

Magnet DI, Developer Guide

Table of contents

Disclaimer and support

Motivation

Getting started

Step 1: Configure project

Step 2: Initialize Magnet

Step 3: Write and annotate application classes

Step 4: Create scope and inject objects

Documentation

Scopes and Instances

Creation and initialization of scope

Getting scope instances

Instance annotation

Instance factory methods

Using Classifier

Instance cardinalities

Optional

Single

Many

Scope hierarchies

Scoping rules

Unscoped

Direct

Top Most

Best practices