# Hannes Dorfmann Recent content on Hannes Dorfmann This is one page of public article previews, not the complete archive. Follow Next page to continue. Summaries are not the original full articles. ## Instantiate test data with Instantiator DevFeed: [Instantiate test data with Instantiator]() Original publisher: [Read original article]() Author: Hannes Dorfmann Published: 2022-08-05T09:00:00Z Content type: tutorial Language: en Sources: [Hannes Dorfmann]() Topics: [Testing](), [unit test](), [Kotlin](), [Android](), [data](), [Library](), [Tool]() Tags: [android](), [data](), [kotlin](), [library](), [testing](), [tool](), [unit-tests]() ### AI overview The article introduces Instantiator, a Kotlin library that uses reflection to fill objects with random test data. It is presented as a way to reduce the effort of creating test data for unit tests involving transformed backend data, pagination, and nested data classes. ### Source excerpt I have noticed that most of the unit tests I write are testing how my code transforms data or business logic. My class or business logic just needs data as input (thus I need some test data to write unit tests). For example, most of my android apps load a list of items from the backend and then the android app is transforming that data into some state object or front-end specific domain objects. ## Perfectionism vs. Excellence DevFeed: [Perfectionism vs. Excellence]() Original publisher: [Read original article]() Author: Hannes Dorfmann Published: 2021-01-29T09:00:00Z Content type: article Language: en Sources: [Hannes Dorfmann]() Topics: [Software Engineering](), [engineering-culture](), [Development]() Tags: [blog-post](), [code-reviews](), [engineering](), [software-engineering]() ### AI overview The article distinguishes perfectionism from striving for excellence and examines the difference through the practical example of software engineering code reviews. It describes perfectionism as pursuit of subjective, unattainable ideals driven by approval and perception, and notes reported associations with poorer achievement and psychological difficulties. ### Source excerpt Perfectionism is not the same thing as striving for excellence. How does one differentiate from the other and why does it matter? How does it related to software engineering? These are the questions that I want to answer by looking at a very concrete example from the world of software engineering: Code Reviews. ## Finding the right abstraction (when working with Strings) DevFeed: [Finding the right abstraction (when working with Strings)]() Original publisher: [Read original article]() Author: Hannes Dorfmann Published: 2021-01-22T09:00:00Z Content type: tutorial Language: en Sources: [Hannes Dorfmann]() Topics: [Android](), [implementation](), [unit test]() Tags: [android](), [implementation](), [ui](), [unit-test]() ### AI overview A tutorial on introducing an abstraction layer for Android string resources. It explains how to handle simple, formatted, translated, and backend-provided text consistently, while keeping implementation details out of business logic and making ViewModels easier to test. ### Source excerpt Finding the right abstraction is hard. In this blog post, I would like to share a technique that works well for us (my android teammates and me) when dealing with String resources on android. An abstraction layer for Strings? Why do we even need an abstraction to simply work with Strings on Android? ## Flowing in the Deep - Event Streams in Kotlin DevFeed: [Flowing in the Deep - Event Streams in Kotlin]() Original publisher: [Read original article]() Author: Hannes Dorfmann Published: 2019-07-02T00:00:00Z Content type: tutorial Language: en Sources: [Hannes Dorfmann]() Topics: [Kotlin](), [Coroutines](), [RxJava](), [Streams](), [Android]() Tags: [android](), [backpressure](), [coroutine](), [coroutines](), [deep-dive](), [event](), [flow](), [flowable](), [introduction](), [kotlin](), [presentation](), [rxjava](), [scopes](), [streams](), [video]() ### AI overview This presentation introduces Kotlin Flow, compares it with RxJava Observable and Flowable, and explains its relationship to coroutines. It also covers implementation details, custom operators, coroutine channels, backpressure, and coroutine scopes for use in Android apps. ### Source excerpt The Kotlin team introduced a new type called Flow which looks similar to RxJava's Observable or Flowable. Have you ever wondered what's the difference between Flow and RxJava? How does Flow work under the hood? How is it connected to Coroutines? How do you write your own operator? What about Kotlin Coroutine Channels? ## Testing By Design DevFeed: [Testing By Design]() Original publisher: [Read original article]() Author: Hannes Dorfmann Published: 2019-05-22T00:00:00Z Content type: article Language: en Sources: [Hannes Dorfmann]() Topics: [Testing](), [Android](), [App]() Tags: [android](), [architecture](), [mvi](), [mvvm](), [presentation](), [testing](), [video]() ### AI overview A presentation about designing Android app architectures for efficient and maintainable testing. It discusses how MVP and MVVM improve testability and presents testing-first architecture, including MVI, as a way to write and maintain resilient tests with less code. ### Source excerpt Together with my friend Kostiantyn Tarasenko we talked about testing android apps. Building an efficient and maintainable test suite for an app is challenging. Design patterns like MVP or MVVM help decouple responsibilities so that it becomes easier to write testable code. What is the next level though? How can we get more out of our tests? ## Advanced Model-View-Intent: The Missing Guide DevFeed: [Advanced Model-View-Intent: The Missing Guide]() Original publisher: [Read original article]() Author: Hannes Dorfmann Published: 2018-06-26T00:00:00Z Content type: article Language: en Sources: [Hannes Dorfmann]() Topics: [RxJava](), [Library]() Tags: [guide](), [library](), [mvi](), [rxjava]() ### AI overview A presentation about Model-View-Intent (MVI) shares practical tips and introduces RxRedux, a library for building state machines with RxJava. ### Source excerpt Together with my friend Kostiantyn Tarasenko we talked about Model-View-Intent (MVI) and were sharing some tips that worked well for us. We also introduced a library to help us build state machines with RxJava called RxRedux ## Reactive Apps with Model-View-Intent - Part 8: Navigation DevFeed: [Reactive Apps with Model-View-Intent - Part 8: Navigation]() Original publisher: [Read original article]() Author: Hannes Dorfmann Published: 2018-05-06T09:00:00Z Content type: tutorial Language: en Sources: [Hannes Dorfmann]() Topics: [navigation](), [reactive](), [RxJava](), [Android]() Tags: [android](), [architecture](), [blog-post](), [callback](), [lambda](), [mvi](), [navigation](), [reactive](), [rxjava]() ### AI overview This tutorial explains how to apply the Coordinator pattern to navigation in an Android Model-View-Intent architecture. It describes passing a navigation callback into MviBasePresenter and reusing the state-rendering observable with an RxJava operator to trigger navigation when a particular state is reached. ### Source excerpt In my previous blog post we discussed how the Coordinator pattern can be applied on Android. This time I would like to show how this can be used in Model-View-Intent. If you don't know yet what the Coordinator pattern is I highly recommend to go back and read the introdcution. ## In-App Navigation with Coordinators DevFeed: [In-App Navigation with Coordinators]() Original publisher: [Read original article]() Author: Hannes Dorfmann Published: 2018-05-05T09:00:00Z Content type: tutorial Language: en Sources: [Hannes Dorfmann]() Topics: [Android](), [navigation](), [Architecture & Design](), [Development]() Tags: [android](), [android-development](), [architecture](), [mvi](), [mvvm](), [navigation](), [patterns]() ### AI overview This article examines the Coordinator pattern for organizing in-app navigation in Android applications. It discusses how navigation logic can become tightly coupled to activities or fragments and considers how coordinators can separate navigation flow logic from those UI components. ### Source excerpt Over the last years we have established best practices for writing android apps: clean architecture, architectural patterns like MVP, MVVM, MVI, Repository pattern and so on. But what about in-app navigation? In this blog post I would like to talk about the Coordinator pattern and how we could apply this pattern in android development to organize our in-app navigation code. ## Reactive State Management with Model-View-Intent DevFeed: [Reactive State Management with Model-View-Intent]() Original publisher: [Read original article]() Author: Hannes Dorfmann Published: 2017-10-05T00:00:00Z Content type: tutorial Language: en Sources: [Hannes Dorfmann]() Topics: [Architecture & Design](), [Android](), [reactive](), [RxJava](), [Redux]() Tags: [android](), [flow](), [mvi](), [patterns](), [rxjava](), [state-management]() ### AI overview A presentation explains Model-View-Intent (MVI) as an architectural pattern for managing application state on Android. It covers synchronous and asynchronous data, component lifecycles, navigation, process death, comparisons with Flux and Redux, and unidirectional data flow with RxJava. ### Source excerpt Managing application state is not a simple topic especially on Android with a synchronous and asynchronous source of data, components having different lifecycles, back stack navigation and process death. Model-View-Intent (MVI) is an architectural design pattern to separate the View from the Model. In this talk, we will discuss the idea behind MVI and how this pattern compares to other architectural patterns like Flux, Redux, Model-View-Presenter or Model-View-ViewModel. ## Reactive Apps with Model-View-Intent - Part 7: Timing (SingleLiveEvent problem) DevFeed: [Reactive Apps with Model-View-Intent - Part 7: Timing (SingleLiveEvent problem)]() Original publisher: [Read original article]() Author: Hannes Dorfmann Published: 2017-09-13T09:00:00Z Content type: tutorial Language: en Sources: [Hannes Dorfmann]() Topics: [reactive](), [App]() Tags: [architecture](), [display](), [livedata](), [mvi](), [reactive](), [screen](), [state](), [state-management](), [viewmodel]() ### AI overview This article explains how Model-View-Intent and proper state management can address the recurring Snackbar problem associated with SingleLiveEvent when Android views are recreated or revisited. It presents immutable view state and unidirectional data flow as the proposed approach. ### Source excerpt In my previous blog post we discussed the importance of proper state management and why I think introducing a SingleLiveEvent as discussed in Google's Architecture Components GitHub repo is not a good idea because it just hides the real underlying problem: state management. In this blog post I would like to discuss how the problem SingleLiveEvent claims to solve can be solved with Model-View-Intent and proper state management. ## ViewModel and LiveData: State-Management Pitfalls in Google's Architecture Components Samples DevFeed: [ViewModel and LiveData: State-Management Pitfalls in Google's Architecture Components Samples]() Original publisher: [Read original article]() Author: Hannes Dorfmann Published: 2017-06-25T09:00:00Z Content type: opinion Language: en Sources: [Hannes Dorfmann]() Topics: [Programming](), [reactive](), [Google](), [RxJava](), [GitHub](), [REST API]() Tags: [architecture](), [blog-post](), [google](), [livedata](), [mvi](), [mvvm](), [pitfalls](), [reactive](), [reactive-programming](), [rxjava](), [state-management](), [viewmodel]() ### AI overview An opinionated review of ViewModel and LiveData in Google's Architecture Components samples, focusing on state management, pagination, lifecycle awareness, and differences from RxJava. ### Source excerpt At I/O 2017 Google surprised us with a new initiative: Architecture Components. I really appreciate this initiative. In this blog post I would like to share my thoughts about ViewModel and some pitfalls you might stumble upon when using ViewModel and LiveData by taking a look at the official Google samples. ## Reactive Apps with Model-View-Intent - Part 6: Restoring State DevFeed: [Reactive Apps with Model-View-Intent - Part 6: Restoring State]() Original publisher: [Read original article]() Author: Hannes Dorfmann Published: 2017-05-02T09:00:00Z Content type: tutorial Language: en Sources: [Hannes Dorfmann]() Topics: [reactive](), [RxJava](), [Android](), [Processes](), [navigation](), [push-notification]() Tags: [android](), [blog-post](), [mvi](), [navigation](), [process](), [push-notification](), [reactive](), [rxjava]() ### AI overview This article explains how Model-View-Intent and unidirectional data flow can support state restoration in Android applications. It covers restoring in-memory state across view lifecycle events such as orientation changes and back-stack navigation, as well as persistent state across process death. The examples discuss Mosby, RxJava streams, presenters, and push-notification updates. ### Source excerpt In the previous blog posts we have discussed Model-View-Intent (MVI) and the importance of unidirectional data flow. That simplifies state restoration a lot. How and why? We will discuss that in this blog post. There are two scenarios we will focus on in this blog post: Restoring state "in memory" (for example during screen orientation change) and restoring a "persistent state" (for example from Bundle previously saved in Activity. ## Reactive Apps with Model-View-Intent - Part 5: Debugging with ease DevFeed: [Reactive Apps with Model-View-Intent - Part 5: Debugging with ease]() Original publisher: [Read original article]() Author: Hannes Dorfmann Published: 2017-03-17T09:00:00Z Content type: tutorial Language: en Sources: [Hannes Dorfmann]() Topics: [debugging](), [Logging](), [reactive](), [Crashlytics](), [RxJava](), [JSON]() Tags: [crashlytics](), [debugging](), [json](), [logging](), [mvi](), [reactive](), [rxjava]() ### AI overview This tutorial explains how the Model-View-Intent pattern and unidirectional data flow can simplify debugging unreproducible crashes. It shows how to log user intents and rendered view state, serialize the state as JSON, and include these logs in crash reports using Crashlytics or another crash-reporting tool. ### Source excerpt In the previous blog posts we have discussed the Model-View-Intent (MVI) pattern and it's characteristics. In part 1 we have talked about the importance of an unidirectional data flow and application state that is driven by the "business logic". In this blog post we will see how this pays off when it comes to debugging to simplify the life of developers. ## Reactive Apps with Model-View-Intent - Part 4: Independent UI Components DevFeed: [Reactive Apps with Model-View-Intent - Part 4: Independent UI Components]() Original publisher: [Read original article]() Author: Hannes Dorfmann Published: 2017-02-25T09:00:00Z Content type: tutorial Language: en Sources: [Hannes Dorfmann]() Topics: [reactive](), [ui](), [App](), [Code]() Tags: [blog](), [design-patterns](), [flow](), [recyclerview](), [shopping](), [toolbar](), [ui-components](), [viewmodel]() ### AI overview This blog post discusses building independent, reusable UI components in reactive application architectures such as Model-View-Intent, Model-View-Presenter, and Model-View-ViewModel. It argues that presenters should communicate indirectly by observing shared business logic and describes this approach using a shopping-basket example. ### Source excerpt In this blog post we will discuss how to build independent UI components and clarify why Parent-Child relations are a code smell in my opinion. Furthermore, we will discuss why I think such relations are needless. One question that arises from time to time with architectural design patterns such as Model-View-Intent, Model-View-Presenter or Model-View-ViewModel is how do Presenters (or ViewModels) communicate with each other? ## Reactive Apps with Model-View-Intent - Part 3: State Reducer DevFeed: [Reactive Apps with Model-View-Intent - Part 3: State Reducer]() Original publisher: [Read original article]() Author: Hannes Dorfmann Published: 2017-01-19T09:00:00Z Content type: tutorial Language: en Sources: [Hannes Dorfmann]() Topics: [reactive](), [App](), [Code](), [ui](), [implementation]() Tags: [3](), [apps](), [blog](), [blog-post](), [build](), [code](), [component](), [data](), [flow](), [how-to](), [implement](), [interface](), [load](), [merge](), [model](), [model-view-intent](), [mvi](), [reactive](), [screen](), [state]() ### AI overview Part 3 of a tutorial on Reactive Apps with Model-View-Intent explains how to build a more complex MVI screen using a state reducer and unidirectional data flow. The example includes categorized product lists, loading more items, pull-to-refresh, pagination, concurrent actions, failures, and presenter logic. ### Source excerpt In the previous part we have discussed how to implement a simple screen with the Model-View-Intent pattern with an unidirectional data flow. In this blog post we are going to build a more complex screen with MVI with the help of a state reducer. If you haven't read part 2 yet, you should read that before continue with this blog post, because there is described how we connect the View via Presenter with the business logic and how data flows unidirectional. ## Reactive Apps with Model-View-Intent - Part 2: View and Intent DevFeed: [Reactive Apps with Model-View-Intent - Part 2: View and Intent]() Original publisher: [Read original article]() Author: Hannes Dorfmann Published: 2017-01-17T09:00:00Z Content type: article Language: en Sources: [Hannes Dorfmann]() Topics: [reactive](), [Development](), [Mobile](), [JavaScript]() Tags: [code](), [immutability](), [javascript](), [mvi](), [reactive](), [ui]() ### AI overview This second-part article introduces the Model-View-Intent pattern for building reactive Android applications. It explains how user intents produce model changes, how business logic returns a new immutable model, and how the view renders that model. ### Source excerpt In the first part we have discussed what a Model actually is, the relation to State and how a well defined Model can solve some common issues in android development. In this blog post we continue our journey towards "Reactive Apps" by introducing the Model-View-Intent pattern to build Reactive Apps. ## Reactive Apps with Model-View-Intent - Part 1: Model DevFeed: [Reactive Apps with Model-View-Intent - Part 1: Model]() Original publisher: [Read original article]() Author: Hannes Dorfmann Published: 2017-01-09T09:00:00Z Content type: tutorial Language: en Sources: [Hannes Dorfmann]() Topics: [RxJava](), [android-development](), [reactive](), [mvc]() Tags: [android-development](), [immutability](), [mvc](), [mvi](), [mvvm](), [patterns](), [process](), [reactive](), [rxjava]() ### AI overview This first part of a blog series explains why a well-defined Model matters in Android applications using Reactive Apps, RxJava, and Model-View-Intent (MVI). It contrasts this approach with MVC, MVP, and MVVM, and connects a Model to issues such as state, configuration changes, navigation, process death, and immutability. ### Source excerpt Once I have figured out that I have modeled my Model classes wrong all the time, a lot of issues and headache I previously had with some Android platform related topics are gone. Moreover, finally I was able to build Reactive Apps using RxJava and Model-View-Intent (MVI) as I never was able before although the apps I have built so far are reactive too but not on the same level of reactiveness as I'm going to describe in this blog post series. ## Why a library developer should use abstract class instead of interface DevFeed: [Why a library developer should use abstract class instead of interface]() Original publisher: [Read original article]() Author: Hannes Dorfmann Published: 2016-10-13T09:00:00Z Content type: opinion Language: en Sources: [Hannes Dorfmann]() Topics: [Library](), [Development](), [Java](), [Android]() Tags: [abstract-class](), [android](), [inheritance](), [interface](), [java](), [library]() ### AI overview The article explains why the author switched AdapterDelegates 3.0 from an interface to an abstract base class in an Android library. It compares interfaces and abstract classes, focusing on flexibility, shared behavior, state, and inheritance risks. ### Source excerpt Use interfaces for java development they said. It will be more flexible they said. Well, that all might be true but for library projects that doesn't necessarily has to be true as well. In this post I will explain you why I have switched from interface to an abstract class as base class in one of my library projects called AdapterDelegates 3. ## The Repository Pattern: History, Abstraction, and Android Use Cases DevFeed: [The Repository Pattern: History, Abstraction, and Android Use Cases]() Original publisher: [Read original article]() Author: Hannes Dorfmann Published: 2016-07-17T09:00:00Z Content type: article Language: en Sources: [Hannes Dorfmann]() Topics: [Programming](), [android-development](), [Refactoring](), [Code]() Tags: [abstraction](), [android-development](), [architecture](), [blog](), [clean-architecture](), [opinion]() ### AI overview This article traces how the Repository Pattern is defined in different contexts and programming languages. It argues that the original definition can introduce unnecessary abstraction and overengineering, especially in Android, while discussing a more practical interpretation for common use cases. ### Source excerpt A listener from our podcast, The Context, that Artem Zinnatullin and I run asked me, if I can give him an example of the Repository Pattern. So I googled around and stumbled upon some blog posts and found out that the term Repository Pattern is used and described in many different ways. ## Refactoring Plaid App - A reactive MVP approach DevFeed: [Refactoring Plaid App - A reactive MVP approach]() Original publisher: [Read original article]() Author: Hannes Dorfmann Published: 2016-06-16T00:00:00Z Content type: article Language: en Sources: [Hannes Dorfmann]() Topics: [Refactoring](), [software-architecture](), [Android](), [Material Design](), [RxJava](), [Dependency injection](), [Test-driven development](), [Code quality](), [Google](), [App](), [Code](), [reactive]() Tags: [android](), [architecture](), [code](), [code-quality](), [dependency-injection](), [google](), [material-design](), [refactoring](), [rxjava](), [software](), [software-architecture](), [tdd](), [ui]() ### AI overview A presentation about refactoring the open-source Android app Plaid from a traditional architecture toward a modular, decoupled Model-View-Presenter architecture. It covers RxJava, dependency injection, testing with Test-Driven Development, code quality, and the meaning of "reactive" in this context. ### Source excerpt Nick Butcher, developer advocate at Google, has open sourced an android app called Plaid with an outstanding UI, meaningful animations and a lot of others material design goodies. However, from the software architecture's point of view, the architecture of this app more "traditional" so that both, beginners and expert developers, can understand the source code easily. ## Android Software Architecutre by Example DevFeed: [Android Software Architecutre by Example]() Original publisher: [Read original article]() Author: Hannes Dorfmann Published: 2016-06-02T00:00:00Z Content type: comparison Language: en Sources: [Hannes Dorfmann]() Topics: [Android](), [flux](), [mvc](), [Redux](), [Open Source]() Tags: [android](), [flux](), [mvc](), [open-source](), [redux](), [video]() ### AI overview A video presentation comparing MVC, MVP, MVVM, Redux, Flux, and MVI architectural patterns and their application to existing open-source Android applications. ### Source excerpt Comparing some architectural design patterns like MVC, MVP, MVVM, Redux, Flux, MVI and how they could be applied on existing open source applications. ## Building Reusable Components for Similar Android and iOS Apps DevFeed: [Building Reusable Components for Similar Android and iOS Apps]() Original publisher: [Read original article]() Author: Hannes Dorfmann Published: 2016-05-13T09:00:00Z Content type: article Language: en Sources: [Hannes Dorfmann]() Topics: [App](), [ui](), [Android](), [iOS](), [navigation]() Tags: [android](), [blog-post](), [building](), [components](), [design](), [ios]() ### AI overview This blog post shares lessons learned from building reusable components for similar Android and iOS football apps with overlapping UI and functionality. ### Source excerpt Before joining my current employer I have worked for an app agency and one thing I have noticed is that we were building every app entirely new from scratch even if we were building a similar app for the same customer with similar UI. We hadn't reusable components. In this blog post I want to share some thoughts and lessons learned while building such reusable components. ## Mixins as an alternative to inheritance in Java 8 DevFeed: [Mixins as an alternative to inheritance in Java 8]() Original publisher: [Read original article]() Author: Hannes Dorfmann Published: 2016-04-26T09:00:00Z Content type: tutorial Language: en Sources: [Hannes Dorfmann]() Topics: [Java](), [interfaces](), [Ruby](), [Scala](), [Polymorphism]() Tags: [inheritance](), [interfaces](), [java](), [java-8](), [programming](), [programming-language](), [ruby](), [scala]() ### AI overview This tutorial explains how Java 8 default methods in interfaces can be used to compose reusable behavior as mixins, providing an alternative to inheritance. It contrasts this approach with delegation and with mixins or traits in Ruby and Scala. ### Source excerpt Starting in Android N Google has added some java 8 language features. One of those features is the ability to add default methods to interfaces. Surprisingly (since java 8 has already been released 2 years ago) I haven't found good articles describing the advantage of default methods for interfaces: Mixins! ## Presenters don't need lifecycle events DevFeed: [Presenters don't need lifecycle events]() Original publisher: [Read original article]() Author: Hannes Dorfmann Published: 2016-03-24T09:00:00Z Content type: opinion Language: en Sources: [Hannes Dorfmann]() Topics: [mvc](), [Library](), [Code]() Tags: [code](), [components](), [library]() ### AI overview The article argues that MVP Presenters in Mosby do not need Android lifecycle callback methods. It says Presenters should coordinate the view, transform model data for presentation, and bridge to business logic, while only tracking whether a view is attached. It discusses LightCycle as a way to delegate lifecycle logic into smaller components, but cautions that adding lifecycle methods to Presenters can merely relocate complex code. ### Source excerpt I have been asked several times why Presenters in Mosby (MVP library) don't have lifecycle callback methods like onCreate(Bundle), onResume() etc. Also the awesome guys over at SoundCloud have published a library called LightCycle that helps break logic out of Activity or Fragments into smaller containers bound to the parents Activity's or Fragment's lifecycle. [Next page]()