feed.xml

<?xml version="1.0" encoding="utf-8"?><feed xmlns="http://www.w3.org/2005/Atom" ><generator uri="https://jekyllrb.com/" version="3.8.5">Jekyll</generator><link href="https://ricardocosteira.com/feed.xml" rel="self" type="application/atom+xml" /><link href="https://ricardocosteira.com/" rel="alternate" type="text/html" /><updated>2020-03-09T12:12:37+00:00</updated><id>https://ricardocosteira.com/feed.xml</id><title type="html">Ricardo Costeira</title><subtitle>A mobile software engineer with a passion for Android and clean, maintainable code. I build apps from the ground up and maintain existing ones.</subtitle><entry><title type="html">Glide’ing your way into RecyclerView state invalidation</title><link href="https://ricardocosteira.com/glideing-your-way-into-recyclerview-state-invalidation" rel="alternate" type="text/html" title="Glide'ing your way into RecyclerView state invalidation" /><published>2020-03-09T10:00:00+00:00</published><updated>2020-03-09T10:00:00+00:00</updated><id>https://ricardocosteira.com/glideing-your-way-into-recyclerview-state-invalidation</id><content type="html" xml:base="https://ricardocosteira.com/glideing-your-way-into-recyclerview-state-invalidation">&lt;p&gt;A few days ago, I worked on a sample project for a tutorial. It was a very simple app: a list of images, where you could click any image to view it in full screen. The code was simple, well structured, did what it had to do, and did it well. There was only one problem: the &lt;code&gt;RecyclerView&lt;/code&gt; responsible for showing the image list was resetting its state, i.e., its scroll position, when you came back to it after checking an image in full screen.&lt;/p&gt;

&lt;h2 id=&quot;a-few-things-about-recyclerviews&quot;&gt;A few things about RecyclerViews&lt;/h2&gt;

&lt;p&gt;Well, this can’t be right… I know I’m doing everything I’m supposed to do in order for the &lt;code&gt;RecyclerView&lt;/code&gt; to be able to retain its scroll position!&lt;/p&gt;

&lt;p&gt;Given the huge amount of code samples online explaining how to manually save and restore &lt;code&gt;RecyclerView&lt;/code&gt; state, it seems that a lot of people think that this isn’t supposed to happen automatically. Well, it is, and it’s actually quite simple to do. You just have to make sure that:&lt;/p&gt;

&lt;ol&gt;
  &lt;li&gt;The &lt;code&gt;RecyclerView&lt;/code&gt; has an ID.&lt;/li&gt;
  &lt;li&gt;You setup the &lt;code&gt;Adapter&lt;/code&gt; with all the data &lt;strong&gt;before&lt;/strong&gt; the &lt;code&gt;RecyclerView&lt;/code&gt; goes through its first layout pass.&lt;/li&gt;
&lt;/ol&gt;

&lt;p&gt;The first one is simple: you just go to the layout and add an ID to the &lt;code&gt;RecyclerView&lt;/code&gt;. By default, if a &lt;code&gt;View&lt;/code&gt; doesn’t have an ID, its state &lt;a href=&quot;https://android.googlesource.com/platform/frameworks/base/+/refs/heads/android10-c2f2-release/core/java/android/view/View.java#20264&quot; target=&quot;_blank&quot;&gt;won’t be stored&lt;/a&gt;. This one’s actually hard to miss since you’re probably using an ID to access the view in the code.&lt;/p&gt;

&lt;p&gt;The second one is trickier. It’s not only a matter of setting up the &lt;code&gt;Adapter&lt;/code&gt; before the &lt;code&gt;RecyclerView&lt;/code&gt;. You need to make sure that when the &lt;code&gt;RecyclerView&lt;/code&gt; is about to go through that first layout pass, it already has &lt;strong&gt;all the data&lt;/strong&gt; it needs. If the layout pass starts and the &lt;code&gt;Adapter&lt;/code&gt; doesn’t have the same data or is empty, the &lt;code&gt;RecyclerView&lt;/code&gt;’s scroll position will get reset, as its state will be invalidated. So, for instance, if an app displaying a &lt;code&gt;RecyclerView&lt;/code&gt; undergoes a config change and has to send an API request for data, it’ll be next to impossible for the data to arrive in time for the layout pass, which means that the &lt;code&gt;RecyclerView&lt;/code&gt;’s scrolling position will inevitably be reset to the initial position.&lt;/p&gt;

&lt;p&gt;The solution here is simple: just cache the data. For example, if you have all the data cached in a &lt;code&gt;LiveData&lt;/code&gt;, something like this will work:&lt;/p&gt;

&lt;pre&gt;&lt;code class=&quot;language-Kotlin&quot;&gt;override fun onCreateView(
    inflater: LayoutInflater,
    container: ViewGroup?,
    savedInstanceState: Bundle?
  ): View? {
    val view = inflater.inflate(R.layout.fragment_list, container, false)

    val myAdapter = createAdapter()

    setupRecyclerView(view, myAdapter)
    observeViewModel(myAdapter)

    return view
  }

private fun setupRecyclerView(view: View, myAdapter: MyAdapter) {
  view.recyclerView.adapter = myAdapter

  // Other settings like listeners, setHasFixedSize, etc
}

private fun observeViewModel(myAdapter: MyAdapter) {
  viewModel.myLiveData.observe(viewLifecycleOwner) {
    myAdapter.submitList(it)
  }
}
&lt;/code&gt;&lt;/pre&gt;

&lt;p&gt;By the time the &lt;code&gt;RecyclerView&lt;/code&gt; starts getting drawn, the data is more than ready.&lt;/p&gt;

&lt;h2 id=&quot;hello-darkness-my-old-friend&quot;&gt;Hello darkness my old friend&lt;/h2&gt;

&lt;blockquote&gt;
  &lt;p&gt;“What am I missing?!”&lt;/p&gt;
&lt;/blockquote&gt;

&lt;p&gt;This was the question I asked myself for three days. My &lt;code&gt;RecyclerView&lt;/code&gt; had an ID, and my data was cached and ready on time, so what could be wrong?&lt;/p&gt;

&lt;p&gt;I tried everything I could think of. Removing &lt;code&gt;setHasFixedSize(true)&lt;/code&gt; from the &lt;code&gt;RecyclerView&lt;/code&gt; setup, removing animations, using &lt;code&gt;RecyclerView.Adapter&lt;/code&gt; instead of &lt;code&gt;ListAdapter&lt;/code&gt;, &lt;code&gt;StaggeredGridLayout&lt;/code&gt; instead of &lt;code&gt;GridLayout&lt;/code&gt;, setting things up in different lifecycle methods and in different combinations, persisting everything… I even saved and restored the state manually at one point, but was not happy at all with the result (UI flickering). Going through the &lt;code&gt;RecyclerView&lt;/code&gt;’s code, I could see that its state was indeed being saved and correctly retrieved, but later invalidated. I hadn’t felt this mad at Android for years!&lt;/p&gt;

&lt;p&gt;As I was close to give up on fixing the bug and on my software engineering career in general, I began browsing Slack channels. In one specific channel, I found something that &lt;a href=&quot;https://twitter.com/JonFHancock&quot; target=&quot;_blank&quot;&gt;Jon F Hancock&lt;/a&gt; said when trying to help someone else with a different &lt;code&gt;RecyclerView&lt;/code&gt; problem:&lt;/p&gt;

&lt;blockquote&gt;
  &lt;p&gt;If the size of your RecyclerView depends on its children, you shouldn’t set that to true.&lt;/p&gt;
&lt;/blockquote&gt;

&lt;p&gt;The “that” in the quote refers to &lt;code&gt;setHasFixedSize(true)&lt;/code&gt;. But the bit that actually caught my attention was the first part: “&lt;em&gt;If the size of your RecyclerView depends on its children (…)&lt;/em&gt;”.&lt;/p&gt;

&lt;p&gt;Holy crap. Could it be?&lt;/p&gt;

&lt;h2 id=&quot;i-can-see-clearly-now-the-rain-is-gone&quot;&gt;I can see clearly now, the rain is gone&lt;/h2&gt;

&lt;p&gt;What Jon said was related to the &lt;code&gt;Recyclerview&lt;/code&gt;’s size. However, it got me thinking about the size of the &lt;code&gt;RecyclerView&lt;/code&gt;’s children.&lt;/p&gt;

&lt;p&gt;So, here’s the layout for the &lt;code&gt;RecyclerView&lt;/code&gt; items:&lt;/p&gt;

&lt;pre&gt;&lt;code class=&quot;language-xml&quot;&gt;&amp;lt;?xml version=&quot;1.0&quot; encoding=&quot;utf-8&quot;?&amp;gt;
&amp;lt;ImageView xmlns:android=&quot;http://schemas.android.com/apk/res/android&quot;
  xmlns:tools=&quot;http://schemas.android.com/tools&quot;
  android:id=&quot;@+id/image_view_image&quot;
  android:layout_width=&quot;match_parent&quot;
  android:layout_height=&quot;wrap_content&quot;
  android:adjustViewBounds=&quot;true&quot;
  android:contentDescription=&quot;@null&quot;
  tools:src=&quot;@tools:sample/backgrounds/scenic&quot; /&amp;gt;
&lt;/code&gt;&lt;/pre&gt;

&lt;p&gt;At a first glance, you probably won’t see anything unusual. And there isn’t! It’s a pretty standard setup for an &lt;code&gt;ImageView&lt;/code&gt;. However, this innocent code was masking a nasty bug.&lt;/p&gt;

&lt;p&gt;The images that feed the &lt;code&gt;RecyclerView&lt;/code&gt; come from an image API. The images are random, and are loaded by &lt;strong&gt;Glide&lt;/strong&gt;. Here’s the extension function for image loading:&lt;/p&gt;

&lt;pre&gt;&lt;code class=&quot;language-Kotlin&quot;&gt;fun ImageView.load(imageAddress: String) {
  Glide.with(this)
      .load(imageAddress)
      .into(this)
}
&lt;/code&gt;&lt;/pre&gt;

&lt;p&gt;Glide is smart enough to cache unmodified data, so it won’t keep requesting the images from the API. However, Glide caches the images with their original size, so it will still have to resize them to fit in the &lt;code&gt;ImageView&lt;/code&gt;. Not only that, but since the xml layout is setting the height for the &lt;code&gt;ImageView&lt;/code&gt; as &lt;code&gt;wrap_content&lt;/code&gt;, and Glide is not specifying any default size either, the latter will have to calculate the height of &lt;strong&gt;each&lt;/strong&gt; image it loads.&lt;/p&gt;

&lt;p&gt;This calculation takes its time, and while Glide is busy with it, the &lt;code&gt;RecyclerView&lt;/code&gt; is setting up its layout. When it’s ready to layout its children, it gets the height of each item so that it knows the space each of them will occupy, i.e., how many &lt;code&gt;ViewHolder&lt;/code&gt; instances it needs. The &lt;code&gt;RecyclerView&lt;/code&gt; reaches this step in a lot less time than Glide takes to be done with the image size calculations. As such, by having the height of the &lt;code&gt;ImageView&lt;/code&gt; declared as &lt;code&gt;wrap_content&lt;/code&gt;, its actual measured height &lt;strong&gt;will default to zero&lt;/strong&gt; until it’s finally displaying an image.&lt;/p&gt;

&lt;p&gt;This effectively messes up the whole logic that comes afterwards:&lt;/p&gt;

&lt;ol&gt;
  &lt;li&gt;The &lt;code&gt;RecyclerView&lt;/code&gt;uses the scrolling position that comes from the previous state to know from which view it should start displaying the items.&lt;/li&gt;
  &lt;li&gt;Using the current position and the size of the items, the &lt;code&gt;RecyclerView&lt;/code&gt; figures out how many more items it can show. It first goes from the current position to the last item, and then from the current position to the first item.&lt;/li&gt;
  &lt;li&gt;Since the item size is coming out as zero, it’ll basically try to set &lt;strong&gt;every item&lt;/strong&gt; in the item list as a visible item. This will then make it so that the previous state is invalidated, forcing the &lt;code&gt;RecyclerView&lt;/code&gt;to reset everything and discard the scrolling position, drawing the items from the beginning.&lt;/li&gt;
&lt;/ol&gt;

&lt;p&gt;Uff! How can you solve this then? There are a few options. You can:&lt;/p&gt;

&lt;ul&gt;
  &lt;li&gt;Hardcode the height in the layout&lt;/li&gt;
&lt;/ul&gt;

&lt;pre&gt;&lt;code class=&quot;language-xml&quot;&gt;&amp;lt;?xml version=&quot;1.0&quot; encoding=&quot;utf-8&quot;?&amp;gt;
&amp;lt;ImageView xmlns:android=&quot;http://schemas.android.com/apk/res/android&quot;
  xmlns:tools=&quot;http://schemas.android.com/tools&quot;
  android:id=&quot;@+id/image_view_doggo&quot;
  android:layout_width=&quot;match_parent&quot;
  android:layout_height=&quot;200dp&quot;
  android:adjustViewBounds=&quot;true&quot;
  android:contentDescription=&quot;@null&quot;
  tools:src=&quot;@tools:sample/backgrounds/scenic&quot; /&amp;gt;
&lt;/code&gt;&lt;/pre&gt;

&lt;ul&gt;
  &lt;li&gt;Override the view size with Glide&lt;/li&gt;
&lt;/ul&gt;

&lt;pre&gt;&lt;code class=&quot;language-Kotlin&quot;&gt;fun ImageView.load(imageAddress: String) {
  Glide.with(this)
      .load(imageAddress)
      .override(Target.SIZE_ORIGINAL, 200)
      .into(this)
}
&lt;/code&gt;&lt;/pre&gt;

&lt;ul&gt;
  &lt;li&gt;Add a placeholder with Glide, so that the &lt;code&gt;RecyclerView&lt;/code&gt; uses its height&lt;/li&gt;
&lt;/ul&gt;

&lt;pre&gt;&lt;code class=&quot;language-Kotlin&quot;&gt;fun ImageView.load(imageAddress: String) {
  Glide.with(this)
      .load(imageAddress)
      .placeholder(R.drawable.placeholder)
      .into(this)
}
&lt;/code&gt;&lt;/pre&gt;

&lt;p&gt;The main point here is that, as long as you set the height of the view &lt;strong&gt;before&lt;/strong&gt; the &lt;code&gt;RecyclerView&lt;/code&gt; tries to layout its children, you’re good!&lt;/p&gt;

&lt;h2 id=&quot;final-thoughts&quot;&gt;Final thoughts&lt;/h2&gt;

&lt;p&gt;That’s it for this article. Congratulations on your retained &lt;code&gt;RecyclerView&lt;/code&gt; state! I hope this was helpful, or that you at least learned something new. Feel free to talk about it either in the comment section down below or at Twitter.&lt;/p&gt;

&lt;p&gt;Until next time!&lt;/p&gt;</content><author><name>Ricardo Costeira</name></author><category term="Android" /><summary type="html">A few days ago, I worked on a sample project for a tutorial. It was a very simple app: a list of images, where you could click any image to view it in full screen. The code was simple, well structured, did what it had to do, and did it well. There was only one problem: the RecyclerView responsible for showing the image list was resetting its state, i.e., its scroll position, when you came back to it after checking an image in full screen.</summary></entry><entry><title type="html">My talk about Kotlin Flow at DevFest Leiria 2019</title><link href="https://ricardocosteira.com/my-talk-about-kotlin-flow-at-devfest-leiria-2019" rel="alternate" type="text/html" title="My talk about Kotlin Flow at DevFest Leiria 2019" /><published>2019-12-23T00:00:00+00:00</published><updated>2019-12-23T00:00:00+00:00</updated><id>https://ricardocosteira.com/my-talk-about-kotlin-flow-at-devfest-leiria-2019</id><content type="html" xml:base="https://ricardocosteira.com/my-talk-about-kotlin-flow-at-devfest-leiria-2019">&lt;p&gt;On December 14 of 2019, I gave a talk about Kotlin Flow at DevFest Leiria.
My main motivation for wanting to give this talk was simple: reactive programming is here to stay.
Most Android devs nowadays are used to sprinkle RxJava throughout their apps, even if they don’t actually have use for reactive streams and just want to simplify thread scheduling. However, it’s also true that more and more devs are becoming aware that Rx is an overkill for their use case, and long for better options.&lt;/p&gt;

&lt;p&gt;Kotlin Flow is one of the new additions to the Kotlin coroutines library, and is meant to bring reactive streams to the coroutine world. But is it as powerful as RxJava?
In this talk, I explored what Kotlin Flow is, how can it be used, and how can it imbue our apps with the power of reactive programming.&lt;/p&gt;

&lt;hr /&gt;

&lt;p&gt;I had a great time. GDG Leiria managed to pull off a wonderful event, and it was their first DevFest! You can find a link to the slides &lt;a href=&quot;https://speakerdeck.com/rcosteira79/do-you-even-kotlin-flow-the-new-api-for-reactive-programming&quot;&gt;here&lt;/a&gt;, and a link to the event page &lt;a href=&quot;https://devfest.gdgleiria.xyz/&quot;&gt;here&lt;/a&gt;. Thank you for reading!&lt;/p&gt;</content><author><name>Ricardo Costeira</name></author><category term="Android" /><category term="Talks" /><summary type="html">On December 14 of 2019, I gave a talk about Kotlin Flow at DevFest Leiria. My main motivation for wanting to give this talk was simple: reactive programming is here to stay. Most Android devs nowadays are used to sprinkle RxJava throughout their apps, even if they don’t actually have use for reactive streams and just want to simplify thread scheduling. However, it’s also true that more and more devs are becoming aware that Rx is an overkill for their use case, and long for better options.</summary></entry><entry><title type="html">Going with the Flow: from RxJava to Kotlin coroutines - Part 1</title><link href="https://ricardocosteira.com/going-with-the-flow-rxjava-to-coroutines-part-1" rel="alternate" type="text/html" title="Going with the Flow: from RxJava to Kotlin coroutines - Part 1" /><published>2019-08-19T01:00:00+01:00</published><updated>2019-08-19T01:00:00+01:00</updated><id>https://ricardocosteira.com/going-with-the-flow-rxjava-to-coroutines-part-1</id><content type="html" xml:base="https://ricardocosteira.com/going-with-the-flow-rxjava-to-coroutines-part-1">&lt;p&gt;I’ve been playing around with Kotlin’s coroutines library. I had some trouble wrapping my head around the whole coroutine concept, mainly because I was consistently looking out for RxJava resemblances. Well, the truth is RxJava is one thing, and coroutines are another thing. Sure, they can be used for the same use cases, but they’re two different concepts. I’ll try not to go too deep into the rabit hole here, but RxJava is an API for asynchronous and/or concurrent programming that follows the &lt;strong&gt;functional&lt;/strong&gt; and &lt;strong&gt;reactive&lt;/strong&gt; paradigms. On the other hand, the coroutines library aims to facilitate asynchronous and/or concurrent programming, while &lt;strong&gt;deferring the decision of going functional or reactive to the user&lt;/strong&gt;. Once I became aware of this, coroutines became a lot easier to understand. And it took me a lot less time than RxJava. I dare say that this might mean they’re easier to grasp for beginners, or at least to someone that’s not familiarized with RxJava.&lt;/p&gt;

&lt;p&gt;In this article series, I’ll go through a sample app built with RxJava and refactor it using the coroutines library. The plan for the series is to:&lt;/p&gt;

&lt;ul&gt;
  &lt;li&gt;Refactor API requests with coroutines;&lt;/li&gt;
  &lt;li&gt;Refactor a Database event subscription with Flow;&lt;/li&gt;
  &lt;li&gt;Refactor a UI interaction with Flow and Channels;&lt;/li&gt;
&lt;/ul&gt;

&lt;p&gt;I will show you both implementations and explain the reasoning behind them, albeit assuming that you’re at least familiar with RxJava. I will measure performance (I’m an Engineer™) and show you how can you write tests for both versions. In this article, I’ll start with the refactoring that, in my opinion, lays the foundation to understand the upcoming ones - refactoring API requests with coroutines. So, let’s get started.&lt;/p&gt;

&lt;h3 id=&quot;the-app&quot;&gt;The app&lt;/h3&gt;

&lt;p&gt;Well, more like “The view”. I didn’t want to show you just small “before” and “after” code samples, but I also didn’t want to make an extremely complex and hard to follow app.&lt;/p&gt;

&lt;figure&gt;
  &lt;img src=&quot;https://ricardocosteira.com/assets/images/going-with-the-flow-rxjava-to-coroutines-part-1-1.png&quot; alt=&quot;App screenshot&quot; /&gt;
  &lt;figcaption&gt;Design skills too stronk.&lt;/figcaption&gt;
&lt;/figure&gt;

&lt;p&gt;The UI is composed by a &lt;code&gt;Fragment&lt;/code&gt; with a search bar and a &lt;code&gt;RecyclerView&lt;/code&gt; (don’t mind the &lt;code&gt;BottomNavigationView&lt;/code&gt;, it’s there just so that I can jump between different code samples - this is my skeleton/playground project). Each &lt;code&gt;RecyclerView&lt;/code&gt; item shows a card with user information. When the app starts, it checks the database for existing data, and displays it accordingly. It also queries the Github API for more data in order to update the database. The search bar filters the user list by name, and the &lt;em&gt;DELETE&lt;/em&gt; button on each card sends a delete command to the database for the corresponding user.&lt;/p&gt;

&lt;p&gt;I’m using Room for the database and Retrofit for the Github API requests. Dependencies are provided by Dagger. The app as a whole is built using a common pattern (&lt;a href=&quot;http://blog.cleancoder.com/uncle-bob/2012/08/13/the-clean-architecture.html&quot;&gt;Clean Architecture&lt;/a&gt;). State is managed through view state and view event classes. Data flow between the view and the &lt;code&gt;ViewModel&lt;/code&gt; is unidirectional. If you want to know more about the implementation details, you can check the &lt;a href=&quot;https://github.com/rcosteira79/AndroidMultiModuleCleanArchTemplate&quot;&gt;repository&lt;/a&gt;. That said, let’s dive into the API request details.&lt;/p&gt;

&lt;h3 id=&quot;handling-an-api-request-with-rxjava&quot;&gt;Handling an API request with RxJava&lt;/h3&gt;

&lt;p&gt;To fetch the users we need to contact the Github API. However, some of the information we want to show, such as location or blog url, are not available in the list that the API returns. As such, we need to do another request - one for &lt;strong&gt;each&lt;/strong&gt; user - to retrieve those details.&lt;/p&gt;

&lt;p&gt;Given this, the app has the following Retrofit API:&lt;/p&gt;

&lt;pre&gt;&lt;code class=&quot;language-Kotlin&quot;&gt;interface Api {
  @GET(&quot;users&quot;)
  fun getAllUsers(): Maybe&amp;lt;List&amp;lt;GithubUser&amp;gt;&amp;gt;

  @GET(&quot;users/{username}&quot;)
  fun getUserDetails(@Path(&quot;username&quot;) username: String): Maybe&amp;lt;GithubDetailedUser&amp;gt;
}
&lt;/code&gt;&lt;/pre&gt;

&lt;p&gt;Yes, I could use &lt;code&gt;Observable&lt;/code&gt; instead of &lt;code&gt;Maybe&lt;/code&gt; here, but &lt;code&gt;Maybe&lt;/code&gt; makes more &lt;em&gt;semantic&lt;/em&gt; meaning to me: maybe I’ll get the response I expect, or maybe I won’t. Still, &lt;code&gt;getAllUsers&lt;/code&gt; returns a &lt;code&gt;List&amp;lt;GithubUser&amp;gt;&lt;/code&gt; stream, and we need to operate on each individual user. So the &lt;strong&gt;repository&lt;/strong&gt; converts this stream into an &lt;code&gt;Observable&lt;/code&gt; stream of &lt;code&gt;GithubUser&lt;/code&gt;. The other stream remains the same:&lt;/p&gt;

&lt;pre&gt;&lt;code class=&quot;language-Kotlin&quot;&gt;override fun getUsersFromApi(): Observable&amp;lt;User&amp;gt; {
  return api.getAllUsers() // returns Maybe for semantic purposes - one possible response on each request.
    .flattenAsObservable { it } // However, we need to transform each element of the list
    .map { userMapper.mapToEntity(it) }
}

override fun getUserDetailsFromApi(username: Username): Maybe&amp;lt;DetailedUser&amp;gt; {
  return api.getUserDetails(username.value) // Username is an inline class. Handy for domain modeling!
    .map { detailedUserMapper.mapToEntity(it) }
}
&lt;/code&gt;&lt;/pre&gt;

&lt;p&gt;Following Clean Architecture, I have &lt;code&gt;UseCase&lt;/code&gt; classes connecting the &lt;code&gt;ViewModel&lt;/code&gt; to the repository. Regardless, I’m skipping them here since I’m only using them to forward the calls from the &lt;code&gt;ViewModel&lt;/code&gt; to the repository. This is actually something that bothers me, because according to the Clean Architecture definition, a use case is called a “use case” because it encapsulates use case logic. On Android though, we tend to keep the this logic both in the repository and the &lt;code&gt;ViewModel&lt;/code&gt; (at least in most Clean Architecture implementations I’ve seen so far). In other words, the &lt;code&gt;UseCase&lt;/code&gt; classes are used only to improve code readability - as their intent is, by nature, straightforward - and define boundaries. Since most of the work done by an Android app is fetching data from wherever and showing it on the screen, one might wonder if the extra classes, extra maintenance effort, extra performance cost and extra APK size increase are really worth it. Anyway, this is a subject for another article, maybe. Back to the refactoring.&lt;/p&gt;

&lt;p&gt;The API is ready, and the repository is ready. Now we just need to make the call in the &lt;code&gt;ViewModel&lt;/code&gt;, and subscribe to it:&lt;/p&gt;

&lt;pre&gt;&lt;code class=&quot;language-Kotlin&quot;&gt;// Gets users from the api and stores them in the database
private fun updateCache() {
  getUsersFromApiAsSingle()
    .doOnSuccess { Logger.d(&quot;Updating database&quot;) }
    .subscribeOn(Schedulers.io())
    .subscribe(
      { updateCachedUsers(it) }, //onSuccess
      { handleErrors(it) } // onError
    )
    .addTo(compositeDisposable) // Extension function
}

private fun getUsersFromApiAsSingle(): Single&amp;lt;List&amp;lt;DetailedUser&amp;gt;&amp;gt; {
  return getUsersFromApi(NoParameters()) // NoParameters is a UseCase implementation detail
    .take(10) // Github API has a hourly call limit :D and 10 are more than enough for what we're doing
    .flatMapMaybe { getUserDetailsFromApi(it.username) } // 2nd api call with information from the 1st one
    .toList() // gather all stream events back into one Single list
}
&lt;/code&gt;&lt;/pre&gt;

&lt;p&gt;I’m going to pretend I don’t have all these layers and boundaries for a second, so that the whole process is easier to visualize:&lt;/p&gt;

&lt;pre&gt;&lt;code class=&quot;language-Kotlin&quot;&gt;api.getAllUsers() // returns Maybe for semantic purposes - one possible response on each request.
  .flattenAsObservable { it } // However, we need to transform each element of the list
  .map { userMapper.mapToEntity(it) }
  .take(10) // Github API has a hourly call limit :D and 10 are more than enough for what we're doing
  .flatMapMaybe { // 2nd api call with information from the 1st one
      api.getUserDetails(username.value)
          .map { detailedUserMapper.mapToEntity(it) }
  }
  .toList() // gather all stream events back into one Single list -&amp;gt; Single&amp;lt;List&amp;lt;DetailedUser&amp;gt;&amp;gt;
  .doOnSuccess { Logger.d(&quot;Updating database&quot;) }
  .subscribeOn(Schedulers.io())
  .subscribe(
    { updateCachedUsers(it) }, //onSuccess
    { handleErrors(it) } // onError
  )
  .addTo(compositeDisposable) // Extension function
&lt;/code&gt;&lt;/pre&gt;

&lt;p&gt;Ok, so what’s happening here?&lt;/p&gt;

&lt;ul&gt;
  &lt;li&gt;We send a request to the API and get back a &lt;code&gt;Maybe&amp;lt;List&amp;lt;GithubUser&amp;gt;&amp;gt;&lt;/code&gt; stream;&lt;/li&gt;
  &lt;li&gt;We flatten the list into an &lt;code&gt;Observable&amp;lt;GithubUser&amp;gt;&lt;/code&gt; stream;&lt;/li&gt;
  &lt;li&gt;We map each element to a domain entity called &lt;code&gt;User&lt;/code&gt; (even though I’m pretending there are no boundaries, I left this mapping on purpose since it’s part of the stream’s operations);&lt;/li&gt;
  &lt;li&gt;We take the first ten elements just because we’ll have to do another API call for each user, and Github has a very low limit for unauthenticated requests;&lt;/li&gt;
  &lt;li&gt;We use &lt;code&gt;flatMapMaybe&lt;/code&gt; to get the user details for each of the ten users, and map each one of the returned objects (&lt;code&gt;GithubDetailedUser&lt;/code&gt;) to a domain entity called &lt;code&gt;DetailedUser&lt;/code&gt;. Why &lt;code&gt;flatMapMaybe&lt;/code&gt; instead of a regular &lt;code&gt;flatMap&lt;/code&gt;? Because the &lt;code&gt;getUserDetails&lt;/code&gt; API call returns a &lt;code&gt;Maybe&amp;lt;GithubDetailedUser&amp;gt;&lt;/code&gt;, and a simple &lt;code&gt;flatMap&lt;/code&gt; requires that you provide it with the same kind of stream you apply it on, since it has to return the same type (in this case, an &lt;code&gt;Observable&lt;/code&gt; stream). As such, &lt;code&gt;flatMapMaybe&lt;/code&gt; is expecting a Maybe stream as its parameter, and returns an &lt;code&gt;Observable&lt;/code&gt; stream at the end;&lt;/li&gt;
  &lt;li&gt;After &lt;code&gt;flatMapMaybe&lt;/code&gt; does its magic and flattens the incoming streams into one &lt;code&gt;Observable&amp;lt;DetailedUser&amp;gt;&lt;/code&gt; stream, we call the &lt;code&gt;toList&lt;/code&gt; operator, which in turn will output a &lt;code&gt;Single&amp;lt;List&amp;lt;DetailedUser&amp;gt;&amp;gt;&lt;/code&gt; stream;&lt;/li&gt;
  &lt;li&gt;Finally, we do some logging, bind all operations to a thread from the IO pool and subscribe to the whole thing. Since the last operation outputs a &lt;code&gt;Single&lt;/code&gt; stream, the observer only has two functions: an &lt;code&gt;onSuccess&lt;/code&gt; lambda that calls the &lt;code&gt;updateCachedUsers&lt;/code&gt; method, and an &lt;code&gt;onError&lt;/code&gt; lambda that calls the &lt;code&gt;handleErrors&lt;/code&gt; method. If everything goes through the happy path, &lt;code&gt;updateCachedUsers&lt;/code&gt; then proceeds to update the database with the information it gets as parameter, i.e. a &lt;code&gt;List&amp;lt;DetailedUser&amp;gt;&lt;/code&gt;. The lack of an &lt;code&gt;observeOn&lt;/code&gt; operator is not a bug: &lt;code&gt;updateCachedUsers&lt;/code&gt; is supposed to run in the background, so we can keep the stream running in the same thread.&lt;/li&gt;
&lt;/ul&gt;

&lt;p&gt;Whew. That’s a whole lot of stream operations. But it does exactly what we want: it fetched data from a remote API and updates the local database, all in an asynchronous - and partially concurrent, thanks to the flatMapMaybe - fashion. Let’s see how can we do the same with coroutines.&lt;/p&gt;

&lt;h3 id=&quot;coroutines&quot;&gt;Coroutines&lt;/h3&gt;

&lt;p&gt;First, I want to talk a little about how coroutines work in Kotlin. I’ll only graze the surface on the topic, but it should be enough to get you started. To make it easier to process, I’ll talk about the basic coroutine theory now, and then talk about the practical concepts as they show up while refactoring. If you already understand how coroutines work under the hood, you can skip to the next section.&lt;/p&gt;

&lt;p&gt;So, a coroutine is a construct meant to turn async programming into a walk in a park. They are usually referred to as &lt;em&gt;lightweigth threads&lt;/em&gt;, since they are so much lighter to use than a regular thread. On Android at least, a typical thread occupies 1 to 2 MB of memory (that’s why we love thread pools!). Each Java thread gets mapped to a kernel thread, which means that the OS manages them. The OS then schedules which thread runs at a given time, jumps between them (context switching), has to invalidate cache in the process… All of these and other related operations have their performance cost.&lt;/p&gt;

&lt;p&gt;Coroutines are executed in threads. These threads come from thread pools managed by coroutines themselves. Coroutines are not bound to any particular thread, which means that they can start in one thread, &lt;em&gt;suspend&lt;/em&gt;, and resume in another thread. Since this process is fully managed by coroutines through &lt;code&gt;Continuation&lt;/code&gt;s, we don’t get the context switching overhead (more on this in a minute). They also aren’t managed by the OS, which automatically frees us from the thread scheduler overhead mentioned above. The coroutine object in itself has a small memory footprint (bytes), which means that you can have a bunch of them being executed at the same time without having to worry about running out of memory. There are a few examples online where people launch 100.000 coroutines at the same time without having any problems at all, while getting an OutOfMemoryException when they try to do the same with regular threads.&lt;/p&gt;

&lt;p&gt;I mentioned &lt;code&gt;Continuation&lt;/code&gt; before. This happens to be one of the most important aspects about coroutines, if not the most important. Kotlin coroutines implement what is called a &lt;strong&gt;continuation passing style&lt;/strong&gt;. Whenever you write a &lt;strong&gt;suspendable function&lt;/strong&gt; (you’ve probably seen &lt;code&gt;suspend fun&lt;/code&gt; written somewhere by now), you’re letting Kotlin know that this function is to be executed in a coroutine. Why? Because under the hood, the compiler translates the &lt;code&gt;suspend fun&lt;/code&gt; to a function that receives a &lt;code&gt;Continuation&lt;/code&gt; as a parameter! So, when you write something like this&lt;/p&gt;

&lt;pre&gt;&lt;code class=&quot;language-Kotlin&quot;&gt;suspend fun login(user: User): Token { ... }
&lt;/code&gt;&lt;/pre&gt;

&lt;p&gt;It gets decompiled to something similar to&lt;/p&gt;

&lt;pre&gt;&lt;code class=&quot;language-Java&quot;&gt;Object login(User user, Continuation&amp;lt;Token&amp;gt; continuation) { ... }
&lt;/code&gt;&lt;/pre&gt;

&lt;p&gt;Every time a coroutine suspends, it stores its state in the continuation. When it wants to resume its execution, it only has to check the continuation for the information it needs, and that’s it. This seamless suspend-resume process is what allows us to write seemingly &lt;strong&gt;sequential&lt;/strong&gt; code instead of callbacks for async work. Whenever there’s async work to be done, the coroutine suspends, and later resumes when the work is done. Meanwhile, the world keeps spinning like nothing’s going on, as this suspension &lt;strong&gt;does not&lt;/strong&gt; block the thread the coroutine is running on. In fact, while this coroutine is suspended, another coroutine can immediately start some work on the same thread.&lt;/p&gt;

&lt;p&gt;Ok, you’re still reading. I know this is a lot, but hopefully it’ll help you understand things when we get our hands on the code (it certainly did help me).&lt;/p&gt;

&lt;h3 id=&quot;handling-an-api-request-with-coroutines&quot;&gt;Handling an API request with coroutines&lt;/h3&gt;

&lt;p&gt;Retrofit has native support for coroutines, so the first step is to add the &lt;code&gt;suspend&lt;/code&gt; keyword to the methods and change their return parameters:&lt;/p&gt;

&lt;pre&gt;&lt;code class=&quot;language-Kotlin&quot;&gt;@GET(&quot;users&quot;)
suspend fun getAllUsers(): List&amp;lt;GithubUser&amp;gt;

@GET(&quot;users/{username}&quot;)
suspend fun getUserDetails(@Path(&quot;username&quot;) username: String): GithubDetailedUser
&lt;/code&gt;&lt;/pre&gt;

&lt;p&gt;Easy enough. Now, propagate the same changes to the repository:&lt;/p&gt;

&lt;pre&gt;&lt;code class=&quot;language-Kotlin&quot;&gt;override suspend fun getUsersFromApi(): List&amp;lt;User&amp;gt; {
  return api.getAllUsers()
    .map { userMapper.mapToEntity(it) }
}

override suspend fun getUserDetailsFromApi(username: Username): DetailedUser {
  val detailedUser = api.getUserDetails(username.value)
  return detailedUserMapper.mapToEntity(detailedUser)
}
&lt;/code&gt;&lt;/pre&gt;

&lt;p&gt;It’s not that different from what we had before. We’re still just mapping the data entities to domain entities. Nothing more.&lt;/p&gt;

&lt;p&gt;Next up is the &lt;code&gt;ViewModel&lt;/code&gt;. Here is where the differences are noticeable:&lt;/p&gt;

&lt;pre&gt;&lt;code class=&quot;language-Kotlin&quot;&gt;private fun updateCacheWithCoroutines() {
  // I don't like try-catch. So we're using an exception handler instead
  val exceptionHandler = CoroutineExceptionHandler { _, throwable -&amp;gt;
    handleErrors(throwable)
  }

  // we want the coroutine to be bounded to the `ViewModel`'s lifecycle (it's on the main thread)
  viewModelScope.launch(exceptionHandler) {
    // But the request should go to the backgound
    withContext(Dispatchers.IO) {
      getUsersFromApiThroughCoroutine(this)
    } // Don't forget: at this point, we're in the main thread context again!
  }
}

private suspend fun getUsersFromApiThroughCoroutine(coroutineScope: CoroutineScope) {
  val userList = getUsersFromApi(NoParameters()) // List&amp;lt;User&amp;gt;
    .take(10) // Github API has a hourly call limit :D and 10 are more than enough for what we're doing
    .map { coroutineScope.async { getUserDetailsFromApi(it.username) } } // Yay parallelism!
    .map { it.await() } // Wait for them to finish... These two last maps are pretty much a flatMap

  if (userList.isNotEmpty()) {
    Logger.d(&quot;Updating database&quot;)
    updateCachedUsers(userList)
  }
}
&lt;/code&gt;&lt;/pre&gt;

&lt;p&gt;Before I start explaining what’s happening here, there are a few keypoints that you need to be aware of (if you know how coroutines are launched and what contexts and jobs are, you can skip to the next code snippet):&lt;/p&gt;

&lt;ul&gt;
  &lt;li&gt;Coroutines are launched through a &lt;code&gt;CoroutineBuilder&lt;/code&gt;. The typical ones are &lt;code&gt;launch&lt;/code&gt; and &lt;code&gt;async&lt;/code&gt; (theres also &lt;code&gt;runBlocking&lt;/code&gt;, which we’ll use for testing). As you can see above, you can launch coroutines inside coroutines: we’re launching coroutines with &lt;code&gt;async&lt;/code&gt;, while in another coroutine that was launched by &lt;code&gt;launch&lt;/code&gt;. The &lt;code&gt;async&lt;/code&gt; builder is used for concurrent tasks. You execute concurrent coroutines with it and wait for them with the &lt;code&gt;await&lt;/code&gt; suspending function, which suspends the parent coroutine until the async children finish;&lt;/li&gt;
  &lt;li&gt;&lt;code&gt;Dispatchers&lt;/code&gt; are used to confine coroutine execution to specific threads. They are used either with a &lt;code&gt;CoroutineBuilder&lt;/code&gt; or with the &lt;code&gt;withContext&lt;/code&gt; suspendable function;&lt;/li&gt;
  &lt;li&gt;Every coroutine is bound to a &lt;code&gt;CoroutineScope&lt;/code&gt;. These scopes let you bind the coroutine to specific lifecycles. &lt;code&gt;CoroutineBuilder&lt;/code&gt;s are actually extension functions defined in &lt;code&gt;CoroutineScope&lt;/code&gt; types (except for &lt;code&gt;runBlocking&lt;/code&gt;). On Android, we probably want to avoid &lt;code&gt;GlobalScope&lt;/code&gt;, which is meant for coroutines that run throughout the app’s lifetime. In the code, I use a &lt;code&gt;ViewModelScope&lt;/code&gt; to bind the coroutines to the &lt;code&gt;ViewModel&lt;/code&gt;’s lifecycle;&lt;/li&gt;
  &lt;li&gt;Coroutines can be cancelled. We can cancel them either by throwing a &lt;code&gt;CancellationException&lt;/code&gt; or through a &lt;code&gt;Job&lt;/code&gt;. Every coroutine is associated with a &lt;code&gt;Job&lt;/code&gt;. Canceling a &lt;code&gt;Job&lt;/code&gt; will cancel its coroutine. &lt;code&gt;Job&lt;/code&gt;s can form parent-child hierarchies, where cancellation of the parent also cancels all children, and failure/cancellation of a child also cancels the parent (except if the child throws a &lt;code&gt;CancellationException&lt;/code&gt;). There’s also the &lt;code&gt;SupervisorJob&lt;/code&gt;, where a child can fail without affecting other children or the parent. The typical way to obtain a coroutine’s &lt;code&gt;Job&lt;/code&gt; is either by storing the return value of the &lt;code&gt;launch&lt;/code&gt; builder, or by accessing it directly inside the coroutine;&lt;/li&gt;
  &lt;li&gt;Just like Android, coroutines have a &lt;strong&gt;context&lt;/strong&gt;. It’s main elements are the coroutine’s &lt;code&gt;Job&lt;/code&gt; and &lt;code&gt;Dispatcher&lt;/code&gt;. When the coroutine is launched, we have the choice of passing a &lt;code&gt;CoroutineContext&lt;/code&gt; to the builder. If we don’t, it’ll use a default one. We can also change the coroutine’s context later through the &lt;code&gt;withContext&lt;/code&gt; function. A bunch of different classes implement the &lt;code&gt;CoroutineContext&lt;/code&gt; interface, which is really handy (for instance, &lt;code&gt;Dispatchers&lt;/code&gt; implement it, so we can pass them to a &lt;code&gt;CoroutineBuilder&lt;/code&gt; or &lt;code&gt;withContext&lt;/code&gt;).&lt;/li&gt;
&lt;/ul&gt;

&lt;p&gt;Back to the code. Like I did with the RxJava version, I’m going to pretend that there are no layers and join the whole thing:&lt;/p&gt;

&lt;pre&gt;&lt;code class=&quot;language-Kotlin&quot;&gt;// I don't like try-catch. So we're using an exception handler instead
val exceptionHandler = CoroutineExceptionHandler { _, throwable -&amp;gt;
  handleErrors(throwable)
}

// we want the coroutine to be bounded to the `ViewModel`'s lifecycle (it's on the main thread)
viewModelScope.launch(exceptionHandler) {
  // But the request should go to the background
  withContext(Dispatchers.IO) {
    val userList = api.getAllUsers()
      .map { userMapper.mapToEntity(it) }
      .take(10) // Github API has a hourly call limit :D and 10 are more than enough for what we're doing
      .map {
        async { // Yay concurrency!
          val detailedUser = api.getUserDetails(it.username.value)
          detailedUserMapper.mapToEntity(detailedUser)
        }
      }
      .map { it.await() } // Wait for all calls to finish... These two last maps are pretty much a flatMap

    if (userList.isNotEmpty()) {
      Logger.d(&quot;Updating database&quot;)
      updateCachedUsers(userList)
    }
  } // Don't forget: at this point, we're in the main thread context again!
}
&lt;/code&gt;&lt;/pre&gt;

&lt;p&gt;Lets begin:&lt;/p&gt;

&lt;ul&gt;
  &lt;li&gt;We start by creating a &lt;code&gt;CoroutineExceptionHandler&lt;/code&gt;. Coroutines bubble up exceptions all the way to the top-most coroutine, so instead of having &lt;code&gt;try-catch&lt;/code&gt; blocks all over the place, we pass an exception handler &lt;strong&gt;to the top-most coroutine&lt;/strong&gt;. This handler works for simple cases, as it will handle all exceptions (note that child coroutines can still have their own exception handling mechanisms);&lt;/li&gt;
  &lt;li&gt;We &lt;code&gt;launch&lt;/code&gt; a coroutine on the &lt;code&gt;viewModelScope&lt;/code&gt; and pass it the exception handler (&lt;code&gt;CoroutineExceptionHandler&lt;/code&gt; also implements &lt;code&gt;CoroutineContext&lt;/code&gt;). By launching the coroutine on this scope, we’re also binding it to the &lt;strong&gt;main thread&lt;/strong&gt;. On a side note, we need to clear all the &lt;code&gt;viewModelScope&lt;/code&gt;’s &lt;code&gt;Job&lt;/code&gt;s at the end of the &lt;code&gt;ViewModel&lt;/code&gt;’s lifecycle, just like we do with Rx’s &lt;code&gt;CompositeDisposable&lt;/code&gt;;&lt;/li&gt;
  &lt;li&gt;As soon as we start the coroutine, we change its context so that it’ll run on the IO thread pool. Now, this is &lt;strong&gt;very&lt;/strong&gt; important: the code inside &lt;code&gt;withContext&lt;/code&gt;’s lambda will run on an IO thread. As &lt;strong&gt;soon&lt;/strong&gt; as the lambda ends in line 25, we’re back to the main thread! Unlike RxJava where we’re used to bind the upstream to a thread and the downstream to another thread, coroutines rely on the actual &lt;strong&gt;blocks&lt;/strong&gt; of code. In other words, everything inside the &lt;code&gt;launch {}&lt;/code&gt; block will run on the main thread, but since we explicitly specify that an inner block should run on an IO thread with &lt;code&gt;withContext&lt;/code&gt;, so it will be;&lt;/li&gt;
  &lt;li&gt;We get the users from the API, map them to domain entities and take the first ten;&lt;/li&gt;
  &lt;li&gt;Now for the other interesting bit. For each &lt;code&gt;User&lt;/code&gt;, we’re launching a new coroutine with &lt;code&gt;async&lt;/code&gt; in order to fetch the details from the API. We then map each response item to a domain entity. Due to the &lt;code&gt;async&lt;/code&gt; calls, this &lt;code&gt;map&lt;/code&gt; will return &lt;code&gt;List&amp;lt;Deferred&amp;lt;DetailedUser&amp;gt;&amp;gt;&lt;/code&gt;, as each &lt;code&gt;async&lt;/code&gt; returns a &lt;code&gt;Deferred&amp;lt;T&amp;gt;&lt;/code&gt; type. All &lt;code&gt;async&lt;/code&gt; calls effectively run in a concurrent manner;&lt;/li&gt;
  &lt;li&gt;Right below, we have another &lt;code&gt;map&lt;/code&gt; being called. We’re calling it so that we can call &lt;code&gt;await&lt;/code&gt; on each of the &lt;code&gt;Deferred&lt;/code&gt; values, in order for the coroutine to suspend until they all finish. In the end, by using this &lt;code&gt;map&lt;/code&gt; together with the one with the &lt;code&gt;async&lt;/code&gt; calls, we’re mimicking what an Rx’s &lt;code&gt;flatMap&lt;/code&gt; would do;&lt;/li&gt;
  &lt;li&gt;That’s it. The rest is just sequential, normal code. However, a side note on this. &lt;code&gt;updateCachedUsers&lt;/code&gt; is a call that gets propagated through the repository until it triggers Room to actually update itself with the new data. Now, the caveat: if the actual Room function was a &lt;code&gt;suspend&lt;/code&gt; function, this &lt;code&gt;updateCachedUsers&lt;/code&gt; call above would have to be out the &lt;code&gt;withContext&lt;/code&gt; block, and be executed in the main thread. As it turns out, Room &lt;code&gt;suspend&lt;/code&gt; functions are &lt;strong&gt;main-safe&lt;/strong&gt;, as Room uses its own custom &lt;code&gt;Dispatcher&lt;/code&gt; - calling it from any other thread other that main will only slow things down.&lt;/li&gt;
&lt;/ul&gt;

&lt;h3 id=&quot;final-words&quot;&gt;Final words&lt;/h3&gt;

&lt;p&gt;This concludes the part 1 of this series. I wanted to include both testing and performance measurements for this refactoring in this article as well, but damn, this is already huge as it is. That said, in part 2 I’ll be writing about how can you unit test both implementations (although I don’t agree that you should in this specific case, but I’ll explain why in the article) and compare them both in terms of performance. I’m expecting them to be really close to each other in execution time, but I’m rather curious with the memory footprint of each implementation. If I had to bet, I’d say that RxJava is heavier on memory usage, but we’ll see.&lt;/p&gt;

&lt;p&gt;As for RxJava vs. coroutines… Well, as I said in the beginning, you really can’t compare two different things. The only thing I can say right now is that both are really fun to use, and if your RxJava use case is one where you only use it for async work &lt;strong&gt;and you’re looking for an alternative&lt;/strong&gt;, you should totally consider coroutines.&lt;/p&gt;

&lt;hr /&gt;

&lt;p&gt;Thank you so much for taking your time to read this. Do you have any thoughts or opinions? If so, please leave a comment or reach out on Twitter. See you in part 2!&lt;/p&gt;</content><author><name>Ricardo Costeira</name></author><category term="Android" /><summary type="html">I’ve been playing around with Kotlin’s coroutines library. I had some trouble wrapping my head around the whole coroutine concept, mainly because I was consistently looking out for RxJava resemblances. Well, the truth is RxJava is one thing, and coroutines are another thing. Sure, they can be used for the same use cases, but they’re two different concepts. I’ll try not to go too deep into the rabit hole here, but RxJava is an API for asynchronous and/or concurrent programming that follows the functional and reactive paradigms. On the other hand, the coroutines library aims to facilitate asynchronous and/or concurrent programming, while deferring the decision of going functional or reactive to the user. Once I became aware of this, coroutines became a lot easier to understand. And it took me a lot less time than RxJava. I dare say that this might mean they’re easier to grasp for beginners, or at least to someone that’s not familiarized with RxJava.</summary></entry><entry><title type="html">How not to use sealed classes and LiveData for state management</title><link href="https://ricardocosteira.com/how-not-to-use-sealed-classes-and-livedata-for-state-management" rel="alternate" type="text/html" title="How not to use sealed classes and LiveData for state management" /><published>2019-05-28T11:00:00+01:00</published><updated>2019-05-28T11:00:00+01:00</updated><id>https://ricardocosteira.com/how-not-to-use-sealed-classes-and-livedata-for-state-management</id><content type="html" xml:base="https://ricardocosteira.com/how-not-to-use-sealed-classes-and-livedata-for-state-management">&lt;p&gt;A few months ago, I was washing my dishes while listening to &lt;a href=&quot;https://fragmentedpodcast.com/episodes/148/&quot;&gt;episode 148 of the Fragmented podcast&lt;/a&gt;. In this episode, Donn Felker and Kaushik Gopal talk about architecture. To be specific, about an MVI-like architecture that Kaushik has been using.&lt;/p&gt;

&lt;p&gt;This architecture specifies that each screen has one and only one ViewModel, that exposes a single observable to the Activity or Fragment. This observable emits the screen’s state: when an update is required, the observable emits a new state object, which the view uses to update its state. To emit a state update, the ViewModel has to receive an event. Different events trigger different updates. Events then generate results, which generate the state updates. Each event class has a corresponding result class.&lt;/p&gt;

&lt;p&gt;There are many other nuances around the architecture, but these are the ones that matter for this article.&lt;/p&gt;

&lt;h3 id=&quot;the-epiphany&quot;&gt;The Epiphany&lt;/h3&gt;

&lt;p&gt;In the &lt;a href=&quot;https://github.com/kaushikgopal/movies-usf&quot;&gt;sample repo&lt;/a&gt; that Kaushik provides, you can see this example of a view state class:&lt;/p&gt;

&lt;pre&gt;&lt;code class=&quot;language-kotlin&quot;&gt;data class MSMovieViewState(
    val searchBoxText: String? = null,
    val searchedMovieTitle: String = &quot;&quot;,
    val searchedMovieRating: String = &quot;&quot;,
    val searchedMoviePoster: String = &quot;&quot;,
    val searchedMovieReference: MSMovie? = null,
    val adapterList: List&amp;lt;MSMovie&amp;gt; = emptyList()
)
&lt;/code&gt;&lt;/pre&gt;

&lt;p&gt;This is quite similar to a &lt;a href=&quot;https://martinfowler.com/eaaDev/PresentationModel.html&quot;&gt;presentation model&lt;/a&gt;, but without the behavior definition. Also, as you can see, the class is immutable. This means that whenever there’s a new state update, the old values get copied into a new object. This new object also has the updated value for each specific state change. For example, given the events class:&lt;/p&gt;

&lt;pre&gt;&lt;code class=&quot;language-kotlin&quot;&gt;sealed class MSMovieEvent {
    object ScreenLoadEvent : MSMovieEvent()
    data class SearchMovieEvent(val searchedMovieTitle: String = &quot;&quot;) : MSMovieEvent()
    data class AddToHistoryEvent(val searchedMovie: MSMovie) : MSMovieEvent()
    data class RestoreFromHistoryEvent(val movieFromHistory: MSMovie) : MSMovieEvent()
}
&lt;/code&gt;&lt;/pre&gt;

&lt;p&gt;for a “add to history event”, you would have something like (this is an oversimplified version of the repo’s code):&lt;/p&gt;

&lt;pre&gt;&lt;code class=&quot;language-kotlin&quot;&gt;val movie: MSMovie = result.packet.movie

val newState = oldState.copy(
  searchedMovieTitle = movie.title,
  searchedMovieRating = movie.ratingSummary,
  searchedMoviePoster = movie.posterUrl,
  searchedMovieReference = movie)
&lt;/code&gt;&lt;/pre&gt;

&lt;p&gt;When I saw this, my train of thought was more or less like “OK, this looks nice. Every state detail becomes enclosed in the same object. But this also means I have to redraw the whole UI on each update, even if I just change a simple text label. This seems rather heavy…”.&lt;/p&gt;

&lt;p&gt;I was really hyped about the architecture, but this bummed me out a little. There must be another way…&lt;/p&gt;

&lt;p&gt;And then it dawned on me: “What if I tried to use sealed classes for this?”&lt;/p&gt;

&lt;h3 id=&quot;keep-it-simple-also-keep-it-working-correctly&quot;&gt;Keep it simple. Also, keep it working correctly&lt;/h3&gt;

&lt;p&gt;Kaushik makes heavy usage of RxJava in this architecture. I love RxJava and think it’s amazing. Yet, like many, I also think that in most cases it’s an overkill. Especially when the framework already provides similar tools for the most common cases. Instead of using RxJava, I’ll be using LiveData for observability. For async work, I’ll use Coroutines. I also won’t be using events or results. Results seem rather redundant when you have observability. As for the events, they also seem to be superfluous: I have methods causing state changes. As such, observability should take care of everything for me, right? Eh, not quite, but we’ll get to that later.&lt;/p&gt;

&lt;p&gt;Before I start explaining what I’m about to do, I want to make something clear: I’m not recommending an architecture of any kind. I’m just testing a different approach to an already well defined architecture, and writing about the results. Nothing more. That being said, let’s get started.&lt;/p&gt;

&lt;p&gt;I’ll be implementing a Fragment that displays a RecyclerView with a list of user names. Each row has a checkbox that gets checked/unchecked either when you click on it or on the row itself. A button at the bottom of the view will update its label according to the number of selected users. I could’ve picked an even simpler example, but I really wanted to test the limits of this approach.&lt;/p&gt;

&lt;p&gt;So, I have two pieces of state here: the contents of the RecyclerView and the button label. I also have the actual user list internal state, i.e., if rows are checked or not. However, since we can consider this as the RecyclerView’s internal state, I’ll let it slide (otherwise, this approach is already failing…).&lt;/p&gt;

&lt;p&gt;I came up with the following sealed class:&lt;/p&gt;

&lt;pre&gt;&lt;code class=&quot;language-kotlin&quot;&gt;sealed class RecyclerViewExampleViewState {
  data class UsersListState(val users: List&amp;lt;DisplayedUser&amp;gt;) : RecyclerViewExampleViewState()
  data class ButtonLabelState(val numberOfUsers: String) : RecyclerViewExampleViewState()
  data class PossibleFailureState(val failure: Failure) : RecyclerViewExampleViewState()
}
&lt;/code&gt;&lt;/pre&gt;

&lt;p&gt;The ViewModel that does all the heavy lifting:&lt;/p&gt;

&lt;pre&gt;&lt;code class=&quot;language-kotlin&quot;&gt;class RecyclerViewExampleViewModel @Inject constructor(
  private val getUsers: GetUsers,
  private val displayedUserMapper: DisplayedUserMapper
) : BaseViewModel() {

  val viewState: LiveData&amp;lt;RecyclerViewExampleViewState&amp;gt;
    get() = _viewState

  private val _viewState: MutableLiveData&amp;lt;RecyclerViewExampleViewState&amp;gt; =
    MutableLiveData()

  init {
    getUsers()
    updateButtonLabel(0)
  }

  fun updateButtonLabel(checkedNumber: Int) {
    val label = if (checkedNumber &amp;gt; 0) &quot; ($checkedNumber)&quot; else &quot;&quot;
    _viewState.value = ButtonLabelState(label)
  }

  private fun getUsers() = getUsers(uiScope, UseCase.None()) {
    it.either(
      ::handleFailure,
      ::handleUserList
    )
  }

  private fun handleFailure(failure: Failure) {
    _viewState.value = PossibleFailureState(failure)
  }

  private fun handleUserList(users: List&amp;lt;User&amp;gt;) {
    val usersToDisplay = users.map { displayedUserMapper.mapToUI(it) }
    _viewState.value = UsersListState(usersToDisplay)
  }
}
&lt;/code&gt;&lt;/pre&gt;

&lt;p&gt;And the Fragment that updates its view on each state update:&lt;/p&gt;

&lt;pre&gt;&lt;code class=&quot;language-kotlin&quot;&gt;class RecyclerViewExampleFragment
: BaseFragment(), RecyclerViewRowClickListener&amp;lt;DisplayedUser&amp;gt; {

  @Inject
  lateinit var viewModel: RecyclerViewExampleViewModel

  lateinit var adapter: UsersAdapter

  override fun onCreateView(
    inflater: LayoutInflater, container: ViewGroup?,
    savedInstanceState: Bundle?
  ): View? {

    return inflater.inflate(R.layout.fragment_recycler_view_example, container, false)
  }

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

    progressBarLoading.show()
    setRecyclerView()

    viewModel = createViewModel(this) {
      observe(viewLifecycleOwner, viewState, ::renderViewState)
    }
  }

  private fun setRecyclerView() {
    prepareAdapter()
    recyclerViewUsers.layoutManager = LinearLayoutManager(this.context)
    recyclerViewUsers.adapter = adapter
    recyclerViewUsers.setHasFixedSize(true)
  }

  private fun prepareAdapter() {
    adapter = UsersAdapter(this)
  }

  private fun renderViewState(state: RecyclerViewExampleViewState) {

    when (state) {
      is UsersListState -&amp;gt; renderUserList(state.users)
      is ButtonLabelState -&amp;gt; renderButton(state.numberOfUsers)
      is PossibleFailureState -&amp;gt; renderPossibleFailure(state.failure)
    }
  }

  private fun renderUserList(users: List&amp;lt;DisplayedUser&amp;gt;) {
    progressBarLoading.hide()
    adapter.submitList(users)
  }

  private fun renderButton(selectedUsers: String) {
    buttonDoStuff.text =
      getString(R.string.button_label_do_stuff_with_users, selectedUsers)
    buttonDoStuff.isEnabled = !selectedUsers.isBlank()
  }

  private fun renderPossibleFailure(failure: Failure) {
    // TODO computer says no
  }

  override fun onRowClicked(item: DisplayedUser, position: Int) {
    val checkedNumber = adapter.currentList.filter { it.isChecked }.count()
    viewModel.updateButtonLabel(checkedNumber)
  }

  override fun onDestroyView() {
    super.onDestroyView()
    recyclerViewUsers.adapter = null
  }
}
&lt;/code&gt;&lt;/pre&gt;

&lt;p&gt;Let me walk you through the code. When the ViewModel inits, it immediately tells the repository to fetch the users (GitHub API). It then updates the button label. The Fragment uses the renderViewState method to observe the LiveData. For each different state update, renderViewState will trigger a different method. The Fragment also implements the RecyclerViewRowClickListener interface. This interface allows us to react to clicks on RecyclerView items. The Fragment does this in the onRowClicked method.&lt;/p&gt;

&lt;p&gt;This is the result:&lt;/p&gt;

&lt;p&gt;&lt;img src=&quot;assets/images/how-not-to-use-sealed-classes-and-livedata-for-state-management-1.png&quot; alt=&quot;&quot; /&gt;&lt;/p&gt;

&lt;p&gt;Everything seemingly works as I expected, except for one small (but important) detail. As you may have noticed, the onRowClicked method filters the user list. The filter counts the number of checked rows. Why? Because I can’t use this approach to update state based on a previous state. In other words, because each sealed class is independent. To me, this is the worst disadvantage of using a single LiveData to handle all these state classes: when I create a state update with a certain value, I lose access to it as soon as I set it as the LiveData’s value. Of course, I could always verify the LiveData value on the next state iteration. Unfortunately, I cannot guarantee that the previous update was the one I need. Suddenly, a simple class with the whole state just like Kaushik has seems worth it. Either that or I would need a different LiveData for this specific piece of state. This would also solve the internal RecyclerView state problem I talked about earlier.&lt;/p&gt;

&lt;p&gt;Anyway, since the use of another LiveData would solve this, I decided to press on. I wasn’t ready to give up on this sealed classes idea. This time, I rotated the screen. And then this happened:&lt;/p&gt;

&lt;p&gt;&lt;img src=&quot;assets/images/how-not-to-use-sealed-classes-and-livedata-for-state-management-2.png&quot; alt=&quot;&quot; /&gt;&lt;/p&gt;

&lt;p&gt;Dammit. Why?&lt;/p&gt;

&lt;p&gt;Well, I forgot a very important aspect of LiveData. Each new observer that subscribes to a LiveData receives its &lt;strong&gt;latest&lt;/strong&gt; value. Here, the Fragment gets destroyed on rotation, and a new Fragment starts observing the LiveData. The last value emitted by the LiveData was the button label update. That’s why the label is correct, but the list is empty. If I rotate the phone before clicking on any rows, the list will appear since the getUsers API request is async and finishes after the updateButtonLabel call. On the other hand, the button label will show the placeholder text instead of the correct value.&lt;/p&gt;

&lt;p&gt;So, ways to solve this. One possibility is, again, different LiveData variables for each sealed class. This is not the most desirable solution though. If we keep adding new LiveData variables, both code maintenance and testing complexity might increase. This was one of the motives between Kaushik’s architecture, if I recall correctly. Another, more sane possibility is to trigger view state updates in the Fragment’s onResume method or similar. Suddenly, events make sense. The third option I can think of breaks my heart: use a class for the whole state, instead of sealed classes (Sorry Kaushik, I will never doubt your work again).&lt;/p&gt;

&lt;h3 id=&quot;final-thoughts&quot;&gt;Final Thoughts&lt;/h3&gt;

&lt;p&gt;I ended up using a single class to the whole state . With the LiveData and sealed classes setup, I got to a point where I had a different LiveData for each sealed class, which defeats the purpose of the whole thing. I even had to stop ignoring the RecyclerView’s internal state, since it gets reset on configuration changes.&lt;/p&gt;

&lt;p&gt;I’m also using events, although there was no functional need for them in this case: since LiveData will always emit the latest global state for the view, I don’t need to cause an explicit state update on configuration change. Regardless, they do make the code look more structured to me. I like having all state changing events going through the same method. It feels like this should help in keeping things more or less simple on a more complex UI. In the end, the architecture became a simplified version of the one presented in the Fragmented podcast.&lt;/p&gt;

&lt;p&gt;Although redrawing the whole UI seems exaggerated, the process is actually very smooth. While this might not hold for a more complex UI, it should be able to handle most cases.&lt;/p&gt;

&lt;p&gt;You can find all the code (in its final state) in my &lt;a href=&quot;https://github.com/rcosteira79/AndroidMultiModuleCleanArchTemplate&quot;&gt;multi module clean architecture template&lt;/a&gt;, in the &lt;code&gt;RecyclerViewExample&lt;/code&gt; module.&lt;/p&gt;

&lt;p&gt;As I said before, this is not an architecture recommendation. While this might work for some cases, other alternatives such as databinding or multiple LiveData variables managed by a MediatorLiveData (&lt;a href=&quot;https://medium.com/@Zhuinden/if-there-are-many-events-id-just-combine-them-together-with-a-mediatorlivedata-or-with-rx-a0494953a578&quot;&gt;as suggested by Gabor Varadi&lt;/a&gt;) might even be a better fit. I’m a fan of this approach, but it’s up to you to figure out what’s best for your specific case.&lt;/p&gt;

&lt;hr /&gt;

&lt;p&gt;Thank you very much for reading the article. I really hope it was worth it! Do you have any ideas? Would you do something differently? If so, please leave a comment or reach out on Twitter. See you next time!&lt;/p&gt;</content><author><name>Ricardo Costeira</name></author><category term="Android" /><summary type="html">A few months ago, I was washing my dishes while listening to episode 148 of the Fragmented podcast. In this episode, Donn Felker and Kaushik Gopal talk about architecture. To be specific, about an MVI-like architecture that Kaushik has been using.</summary></entry><entry><title type="html">Encapsulate and abstract for future proof software</title><link href="https://ricardocosteira.com/encapsulate-and-abstract-for-future-proof-software" rel="alternate" type="text/html" title="Encapsulate and abstract for future proof software" /><published>2019-04-22T11:00:00+01:00</published><updated>2019-04-22T11:00:00+01:00</updated><id>https://ricardocosteira.com/encapsulate-and-abstract-for-future-proof-software</id><content type="html" xml:base="https://ricardocosteira.com/encapsulate-and-abstract-for-future-proof-software">&lt;p&gt;Change will always affect your software. No matter the domain, the uses cases, the developers, or even the users. Change is the one constant in software development.&lt;/p&gt;

&lt;p&gt;This is one of the first topics addressed by the authors of the renowned &lt;a href=&quot;http://shop.oreilly.com/product/9780596007126.do&quot;&gt;Head First Design Patterns&lt;/a&gt;. They approach it as one reason for the importance of design patterns. As they say in the book:&lt;/p&gt;

&lt;blockquote&gt;
  &lt;p&gt;“No matter how well you design an application, over time an application must grow and change or it will &lt;em&gt;die&lt;/em&gt;.”&lt;/p&gt;
&lt;/blockquote&gt;

&lt;p&gt;Along with design patterns, the authors also introduce a bundle of design principles. While the patterns are outside the scope of this article, I want to focus on the first two principles:&lt;/p&gt;

&lt;ul&gt;
  &lt;li&gt;&lt;strong&gt;Encapsulate what varies.&lt;/strong&gt;&lt;/li&gt;
  &lt;li&gt;&lt;strong&gt;Program to interfaces, not implementations.&lt;/strong&gt;&lt;/li&gt;
&lt;/ul&gt;

&lt;p&gt;The first principle is the basis for all design patterns, and most of them also make use of the second one. The first one dictates that if you have code that keeps changing, pull it out and isolate it. The second principle complements this through the use of interfaces.&lt;/p&gt;

&lt;p&gt;Now, a word of caution. As &lt;a href=&quot;https://medium.com/@techyourchance&quot;&gt;Vasiliy Zukanov&lt;/a&gt; explained in &lt;a href=&quot;https://medium.com/@techyourchance/i-havent-read-head-first-design-patterns-yet-but-i-heard-that-it-s-a-worthy-book-b53f72e9b495&quot;&gt;this comment&lt;/a&gt;, this “interface” does not refer to the interface construct seen in some OOP languages. Well, it can refer to it, but it has a broader meaning. Here, “interface” refers to a component’s external point of interaction. It is what other components can use to interact with the specific component. So, this “interface” can be an interface, an abstract class, a normal class or even a function. It can be anything as long as it serves as a communication point with the component. With it, we need not know the inner details of the component. It lets us &lt;strong&gt;abstract&lt;/strong&gt; from the component’s implementation. So, whenever there’s a change, you only need to refactor the corresponding code. The outside code will never even notice it. The purpose of the principle is indeed to focus on &lt;strong&gt;what&lt;/strong&gt; the code does, and not &lt;strong&gt;how&lt;/strong&gt; it does it.&lt;/p&gt;

&lt;h3 id=&quot;a-ticking-time-bomb-android-libraries&quot;&gt;A ticking time bomb: Android Libraries&lt;/h3&gt;

&lt;p&gt;The Android open source community is awesome. No matter the complexity of what you need, a library implementing it is likely to exist already. This not only makes our jobs easier but also lets us focus on the true business logic problems.&lt;/p&gt;

&lt;p&gt;Yet, things change (I know). Libraries become obsolete. Sometimes, new versions introduce breaking changes. Requirements change, and we no longer need a library. External changes force us to change our code. We’re left with a huge codebase full of deprecated dependencies or code built around them. This is where the design principles mentioned above come in handy.&lt;/p&gt;

&lt;p&gt;Suppose that you need to store/retrieve a Configuration object on/from disk in JSON format. You have experience with Gson from previous projects, so you use it. You defined Configuration as:&lt;/p&gt;

&lt;pre&gt;&lt;code class=&quot;language-kotlin&quot;&gt;data class Configuration(
  val aNumber: Int,
  val somethingWithCharacters: String)
&lt;/code&gt;&lt;/pre&gt;

&lt;p&gt;You first start by creating an abstraction for Gson. Here, a simple class will do (unless you’re using &lt;a href=&quot;http://blog.cleancoder.com/uncle-bob/2012/08/13/the-clean-architecture.html&quot;&gt;Clean Architecture&lt;/a&gt;: in that case, you would probably have this class implement an interface):&lt;/p&gt;

&lt;pre&gt;&lt;code class=&quot;language-kotlin&quot;&gt;/** Imports */

class ConfigurationStorageHandler {

  private val gson: Gson

  // ...

  fun read(): Configuration {
    val jsonConfiguration = /** Get json string from disk */
    return gson.fromJson(jsonConfiguration, Configuration::class.java)
  }

  fun write(configuration: Configuration) {
    val jsonString = gson.toJson(configuration)
    /** Store jsonString on disk */
  }
}
&lt;/code&gt;&lt;/pre&gt;

&lt;p&gt;Then, you use it along with the rest of your product:&lt;/p&gt;

&lt;pre&gt;&lt;code class=&quot;language-kotlin&quot;&gt;class MagicBusiness constructor(
  private val configurationStorageHandler: ConfigurationStorageHandler
) {
  // ...

  fun doMagicAccordingToConfig() {
    val config = configurationStorageHandler.read()
    /** use config for magic */
  }

  fun saveConfigForLateNightMagic(configuration: Configuration) {
    /** 10x programmer magic */

    configurationStorageHandler.write(configuration)
  }
}
&lt;/code&gt;&lt;/pre&gt;

&lt;pre&gt;&lt;code class=&quot;language-kotlin&quot;&gt;class MagicActivity : AppCompatActivity() {

  // ...

  override fun onCreate(savedInstanceState: Bundle?) {
    // ...
    val storageHandler = ConfigurationStorageHandler()
    val magicBusiness = MagicBusiness(
      configurationStorageHandler = storageHandler
    )
    // ...
  }

  // ...
}
&lt;/code&gt;&lt;/pre&gt;

&lt;p&gt;Time goes by, and your abstraction gets sprinkled throughout your code. One day, you come across this hip library called Moshi, that also deals with json parsing. Moshi seems to be faster, more flexible, and works like a charm when used together with Retrofit. You got to use it.&lt;/p&gt;

&lt;p&gt;Luckily, you saw this coming. You use Gson everywhere in your code. But since you have it encapsulated, you can swap it with Moshi almost for free!&lt;/p&gt;

&lt;p&gt;Simply replace Gson with Moshi:&lt;/p&gt;

&lt;pre&gt;&lt;code class=&quot;language-kotlin&quot;&gt;/** Imports */

class ConfigurationStorageHandler {

  private val moshi: Moshi

  // ...

  fun read(): Configuration {
    val jsonConfiguration = /** Get json string from disk */
    val adapter = moshi.adapter(Configuration::class.java)

    return adapter.fromJson(jsonConfiguration)
  }

  fun write(configuration: Configuration) {
    val adapter = moshi.adapter(Configuration::class.java)
    val jsonString = adapter.toJson(configuration)
    /** Store jsonString on disk */
  }
}
&lt;/code&gt;&lt;/pre&gt;

&lt;p&gt;And you’re done — all the code that used Gson now uses Moshi. Just by changing this class.&lt;/p&gt;

&lt;p&gt;You can later change libraries again. You can even ditch json and use something else. As long as you create the proper abstraction (which is actually the hard part), you’re good to go. Your code is now robust and flexible, and your future self will be proud.&lt;/p&gt;

&lt;p&gt;Note that the codebase is further improved by injecting the dependencies. Even if you don’t use Dagger or any other framework — the dependency injection itself is what matters. This way, you keep your classes decoupled and set yourself up for easy testing. Here, if you inject a mock or fake storage handler, you can test &lt;code&gt;MagicBusiness&lt;/code&gt; in isolation.&lt;/p&gt;

&lt;h3 id=&quot;conclusion&quot;&gt;Conclusion&lt;/h3&gt;

&lt;blockquote&gt;
  &lt;p&gt;“Abstractions Live Longer than Details“ — The Pragmatic Programmer, chapter 7, page 209&lt;/p&gt;
&lt;/blockquote&gt;

&lt;p&gt;I showed you an example of how you can create boundaries around your code. These boundaries protect your code from external dependencies. Still, it goes much deeper than this. Recipes like design patterns or architectural patterns such as Clean Architecture are great. They’re battle tested, and their usefulness is more than proven. Using these design principles is one reason for their greatness. You can (and should!) apply these design principles even if you don’t use external code. Use them with caution, though. We know that design principle abuse increases code complexity. It’s a commitment you must consider, and balance with care.&lt;/p&gt;</content><author><name>Ricardo Costeira</name></author><category term="Android" /><summary type="html">Change will always affect your software. No matter the domain, the uses cases, the developers, or even the users. Change is the one constant in software development.</summary></entry></feed>