Note: This was originally published on HackerNoon and written in 2019.

Working in front of a screen doesn’t change based on location. Medellín is a great place because of the opportunities to try food, the outdoors, work from amazing cafes, and the opportunity to meet diverse people.

I traveled to Medellín, Colombia, both to explore for a week on vacation and then to immerse myself in daily life while working remotely as the creator of Coinverse, the first cryptocurrency news audiocast app.

The high standard of living is great for productivity.

• Commuting: Convenient and safe, the metro has been running since 1995.
• Places to work: Choose a new cafe every day, and you’ll still not see all of them. There are plenty of coworking options too.
• Food: Eat locally and affordably, or choose international options.

Coffee culture

Unlike the states, adding cream to coffee is doing your taste buds a massive disservice. The coffee is flavorful, ranging in levels of sweet, fruity, bitter, chocolate, vanilla, and creamy flavors. Espresso is the default. Learn to ask for “cafe filtrado” if seeking drip coffee.

Important factors for cafes are the coffee and atmosphere for working and hanging out. I was concerned with the availability of power outlets and the internet and discovered this was not an issue. The most expensive coffee was $2, and many places have a full food menu.

These are my three favorites in El Poblado, where I spent most of my time.

• Hija Mía: It is small, friendly, and comfortable. You have to try the hardy version of avocado toast. This cafe has many travelers.
• Urbania Café: Each cup is served with a piece of smooth dark chocolate. They offer a full-day coffee experience on home brewing and experimenting with flavors.
• Pergamino (Carrera 37, Calle 10b): Although it’s a chain, the coffee is great. I prefer the newer Calle 10b location as it has an open second floor which is quiet and great for focusing. They offer great gift wrapping for beans bought as gifts, too.

I spent time at other great cafes in El Poblado, too.

• Pardo: This doubles as a clothing store and restaurant with big healthy salads for lunch. The iced coffee was my favorite.
• Cafe Velvet: High-end and comfortable.
• Starbucks Coffee Milla de Oro: This location is open the latest, 10 PM most nights, and 11 PM on Friday and Saturday.

In Laureles, I enjoyed Café Zeppelin, with a rock and roll vibe and a great spot for meeting up, and Rituales Compañia de Café, a small and trendy spot.

These come highly recommended from Anthony Castrio and Jeff Ander’s Cafe Grind Rankings, which organizes the best cafes based on factors such as atmosphere, food, wifi, etc.

Laureles

• Café Cliché
• Quiero Café
• Naturalia Café
• Café Revolución

Envigado

• Vizzto
• Café Apasionado

See cafes map

Coworking

A coworking space is great for increasing productivity. Spaces range from backpacker to upscale tech company vibes.

Selina

Selina is part of a hostel and has a grassroots feel with an affordable monthly rate compared to traditional office space. It contains both a cafe and a restaurant. Their weekly events like yoga, happy hours, live shows, etc., are a great time to meet people.

WeWork

WeWork feels like a Google office with cafes, amenities, stunning views, and a variety of work areas. After lunch, people found their favorite spot to close their eyes for an afternoon siesta.

See Coworking map

Communities

There is most likely a community here for you based on your professional interest. I’ve met salespeople, marketers, designers, programmers, wellness professionals, etc. here.

Begin by searching on Meetup.com. I found the Medellín Android group. The majority of the first talk I attended was in Spanish. Once the event was over the organizers Cristián Gomez and Carlos Daniel introduced themselves to me with a smile.

After speaking with them I felt welcomed and they invited me to give my own talk. I gave a talk there on Android architecture patterns. The one feature I still actively use Facebook for is finding local groups to learn from by searching for “Digital nomads in {city}”.

Healthy eating

Street food is tasty. However, in order to feel good and be productive, eating healthy is important. Although more expensive, there are great options from around the world.

Fast casual

• Mediterranean options like Falafel Time
• German Street Food’s salads
• Tacohouse chains: Identical to Chipotle in food and price
• Saludpan: Salads

Sit down

• Burdo: For lunch or drinks
• Pardo: Cafe with healthy food options
• Betty’s Bowls: Build your own protein bowls
• Zaaika Indian: Indian food
• Bárbaro Cocina Primitiva (El Poblado, Laureles): Great and affordable steaks
• Mezzaluna: Salads

See food maps

If you’re interested in “Why Medellín?”, the best local flavors, and activities to experience, read the following.

Medellín — The nomad’s hidden gem

Medellín — A taste of classics and the best cacao

Medellín — Discover the local appeal

Adam Hurwitz enjoys sharing travel open info and is a researcher and product consultant.

Note: This was originally published on HackerNoon and written in 2019.

During his travels, author and podcaster Tim Ferriss mentioned on comedian Ari Shaffir’s podcast that the first thing he likes to do in a new city is to take a bike tour. I followed that move, taking a walking tour my first few days after arriving to get a sense of the areas, following that up with experiencing local marketplaces, bars, and nightlife.

I traveled to Medellín, Colombia, both to explore for a week on vacation and then to immerse myself in daily life, while working remotely as the creator of Coinverse, the first cryptocurrency news audiocast app.

Tours

Whether your interest is history, marketplaces, art, or coffee, there is something for you. I have always avoided what I thought of as “traditional tours.” After experiencing RealCityTours “free” city walking tour, where you pay with a tip, it is an experience I will actively seek out on future trips. The free tour was led by a local who was an interactive storyteller.

It’s best to base your tours on personal recommendations and/or online reviews. I got suckered into a “transformation tour” through a popular hostel chain that was advertised as educational to learn about the positive evolution of neighborhoods.

In actuality, it was a drive to three different tourist spots to look around and spend money with the tour guide’s friends.

I’ve had a great experience and received excellent in-person feedback on the tours below.

• freetour.com
• Real City Tours: Free walking tour, Exotic fruits tour, and Transformation tour
• Comuna 13 Medellin Graffiti Tour
• Urban coffee tour

Markets

Marketplaces refer to anything from “mom and pop” merchants where everyday people or businesses buy groceries, to hubs with restaurants from around the world. Both are worth exploring. The former lends itself to more adventure.

Traditional Marketplaces

• Plaza Minorista
• San Alejo 1st Saturday of the month
• San Fernando Plaza
• Market Square Envigado
• Central Mayorista de Antioquia
• Placita de Flórez
• El Pulguero Llanogrande Limited to a few times per year

Restaurant Hubs

• Mercado del Río

Resources

• Markets map
• The Best Markets in Medellín, Colombia by CultureTrip
• The Best Street Food Markets in Medellín by CultureTrip

Social scene

Through the handful of nights I went out, I experienced the variety the city offers. I explored a battle of the bands at the Selina hostel, danced to Reggaeton till 4 AM on my birthday at Buena Vista, stepped on a few toes at a local salsa joint, El Tíbiri, helped host a rooftop morning yoga and dance party, and saw a new friend DJ.

My social circle grew through roommates, informal events friends hosted, tech meetups, etc.

One of my favorite experiences was Calle 66a. A local friend introduced me to this street where you walk up to a bodega, drink beer, and hang out on the street. People are here every night, and I hear it can get rowdy into the early morning.

If looking for the hostel party scene, there are well-known “party hostels” like Selina and the Purple Monkey. For bars and clubs, the two main spots are around Parque Lleras in El Poblado and Carrera 70 in Laureles.

An alternative to the bar scene is language exchanges like El Social (Wednesdays), and Café Ondas (Wednesdays and Fridays). Locals and travelers meet in order to practice speaking, listening, and hanging out.

Outdoors

Within a quick trip from downtown, you can be in the jungle jumping into a waterfall or overlooking the cityscape. The proximity of the locations and range of difficulty in accessing these sites make the samples below easy to get to from downtown.

I’m happy I did Cuevas del Higuerón last minute. I chose this because it was a decent workout, thanks to the ascent, a view of the city, and the opportunity to jump in the waterfall. The waterfall was cold, surprisingly not as cold as Yosemite National Park’s waterfall in California during the summertime.

You can take Uber or public transportation to the trailhead at Cuevas del Higuerón — Camino Ancestral — Camino Real La Ayurá.

Next time I’d love to do El Cerro De Las Tres Cruces because of how easy it is to access and the citywide view. The hike up lasts only 30–45 min. To get to the trailhead, take an Uber to Casa de los Bernal which will take you to the start point.

Here are more great outdoor adventures.

• La Ruta hiking Facebook group
• Parque Arví bike
• Parque Arví hike
• Parque Arví night hike
• ATV tour offered by Rango Hostel
• Mountain bike descent offered by Rango Hostel

Spas

After a week of exploring, it is nice to wind down with a massage on the rooftop of the Diez 10 Hotel. It took me a while to book the full body massage because I had a hard time understanding what I was ordering due to my Spanish, or lack thereof. The massage was good, costing $50 per hour, about half the cost compared to the states.

If you decide to go to Diez, the following descriptions of the menu will save you my confusion.

• Masaje terrenal: Full body using hot stones
• Masaja tropical / nuez de coco: Using coconuts
• Masaja de caña: Using bamboo
• Masaja atardecer llanero: Using hot wax

For a less fancy and highly rated experience, Sports Massage is $40 per hour.

Lastly, I explore how to work effectively.

See Medellín — Work remotely

If you’re curious “Why Medellín?” or for the best local flavors, read the following.

Medellín — The nomad’s hidden gem

Medellín — A taste of classics and the best cacao

Adam Hurwitz enjoys sharing travel open info and is a researcher and product consultant.

Note: This was originally published on HackerNoon and written in 2019..

Anthony Bourdain taught us there is no better way to explore a place than through people and food. I traveled to Medellín, Colombia, both to explore for a week on vacation and then to immerse myself in daily life while working remotely as the creator of Coinverse, the first cryptocurrency news audiocast app.

Despite eating mostly vegetables and protein, it is important to experience the local cuisine. Most of my research was compiled at 3 A.M., thanks to the au pair in the adjacent seat on my red-eye who was also unable to sleep.

Must try

Classics

• Bandeja Paisa
• Empanadas
• Arepa Paisa
• Sopas
• Hot dogs

Empanadas

They have a major difference from the Mexican variety, made from corn instead of flour, theoretically healthier if not deep-fried. Empanadas are available everywhere. The ones below came recommended by Empanadas Envigadeñas.

Sopa

Sopa de Mondongo is moreso a hardy meal. I believed I was having chicken but later discovered that it was more ‘exotic’, the stomach of a cow or pig.

Here are places to check out for classic stews.

• Asados Doña Rosa
• Restaurante Mondongo’s El Poblado

Hot dogs

“Hot dogs” is an understatement. Nothing about the Perro Malvada Pequeña was pequeña. After some cerveza and tasting Aguardiente (the national tequila), this was a fine idea. Alone and overwhelmed with the menu, I rolled the dice and told them I’d have what the person in front of me was having. This puts the Philly Cheesesteak to shame. Towards the weekend, this food stand is open at the intersection of Carrera 43A and Calle 7D.

Chocolate

I prefer chocolate with high amounts of cacao, which Medellín is known for. Below are a few of my favorite cacao-rich chocolates.

Store-bought

1. Lok, bought at Cacao Brunch, from Arauca. This is exactly what I had been looking for, pure 100% cacao. It contains an initial bitter punch, then a dark, smooth, and rich aftertaste. I bought sweeter chocolates for gifts and stocked up on Lok for myself.

2. Tilín Tilín, bought at Tilín Tilín Chocolate Factory, from Tumaco. This is my favorite gift for others. Each variety has a distinct flavor. Rooibos is one of my favorite teas containing sweetness, making the 69% cacao Rooibos & Roses bar my top pick. Rooibos & Roses provides instant sweetness with a hint of tart.

Pro-tip, the longer you talk with the chocolate tender, the more free samples you’ll be rewarded.

3. Tibitó, bought at Cacao brunch, from Meta, Putumayo, Tumaco, and Arauca. All four are smooth and creamy, tasting similar to milk chocolate. I could not identify major flavor differences between each.

4. Cacao Hunters, bought at Urbania Café, from Tumaco. The 82% cacao bar is dark, smooth, and simple. Sold at one of my favorite cafes, Urbania pairs a sample of chocolate with their coffee.

5. Moctezuma, bought at Fruta Provenza, from Guatapé. This has a homemade feel, loosely wrapped in tin foil within the box. It was good, but it had no distinct flavor due to the overpowering of sweet jam at the bottom.

The store Fruta Provenza is fantastic, selling healthy food not found at most grocery stores. During my chocolate haul, I made an impulse purchase of almond flour baked bread.

6. Kalu, bought at Fruta Provenza, from Pereira. The flavor was mild and chocolate fairly smooth, but nothing stood out from the peanuts, raisins, blueberries, and coconut.

7. Jet, bought at any grocery store, from Rionegro. I could not find dark chocolate, but had to try the milk chocolate. It’s a classic from 1920, and what you’d expect from a standard milk chocolate without the depth of a Tilin Tilin or Tibitó.

I ran out of time to find Chocolate Suagu. According to their team, they are sold at Éxito de Envigado, Unicentro Shopping Center, Viva Laureles, and at the Sol Verde in the Oviedo mall.

I could not find the following which have stores in Bogotá.

• Cacao y Más Cacao
• Chuculat
• Carlota Chocolat

See 7 Colombian Chocolate Brands You Need to Know About by CultureTrip

Ceremonial cacao

The best cacao was at a private cacao ceremony I attended. Check with your health professional before trying as this cacao affects blood pressure. My roommates planned this experience, and I enthusiastically joined.

I only heard of cacao ceremonies at yoga studios and through a 2016 story of Berlin clubbers having cacao instead of alcohol and drugs. I envisioned sipping the hot drink in a relaxed setting, which it was, but it was also much more.

The master of ceremony was a nice woman named Sandy, who had studied these types of ceremonies throughout Latin and South America for many years. She informed us this ritual has been shared for thousands of years by the people across the Americas.

Before European conquests, cacao was used as currency and sacred medicine. Ceremonial cacao has a strict and specific selection process compared to store-bought cacao.

Beginning the first cup, I was warned to take my time. A few sips in, and I felt a strong sensation in the top left of my chest where a large vein was. I slowly continued feeling a strong yet relaxed buzz spread to my head and the rest of my body. The final effect was mental clarity and relaxation without any caffeine jitters.

See What is a cacao ceremony? by USA Today

Next up, I explore the local activities and how to work effectively.

Medellín — Discover the local appeal

Medellín — Work remotely

If you’re curious “Why Medellín?”, read Medellín — The nomad’s hidden gem.

Adam Hurwitz enjoys sharing travel open info and is a researcher and product consultant.

Note: This was originally published on HackerNoon and written in 2019.

As I decide to enjoy deep breaths of the warm ‘eternal spring’ air after my all-nighter on the plane, I notice a man running towards me.

Before my first solo trip, my friend Waj, a seasoned traveler, imparted upon me that the best part of travel is the people you meet. In Medellín, you feel welcomed by the people who live here, which becomes contagious amongst travelers, creating a small-town feel in an international city.

Due to my lack of sleep, or poor Spanish skills, I was waiting in the airport parking lot for my Uber. The man running is Juan, from Uber. I realize as Juan and I run through the parking that he has abandoned his car in the pick-up loop. In most cities, an Uber would drive away after a short wait, and an unattended car would be confiscated by police. Not here, Juan came to find me.

Why here

This marks my first solo adventure. My last trip abroad was with a group in Israel eight years ago. I read Tim Ferriss’ The 4-Hour Workweek (T4HWW) when I was 20. During a college job, standing in the weight room waiting to spot frat bros, I vigorously annotated T4HWW.

Long-term travel being possible and affordable while working was a mindset shift. Tim’s podcasts led me to Rolf Pott’s Vagabonding, a book with practical advice, anecdotes, and insight on viewing the world was the launch pad for my travel.

Being stressed with work leading up to the trip, I thought about a favorite stand-up comedian and podcaster, Ari Shaffir, and his global stand-up adventures. I asked myself, ‘What would Ari do?’, allowing me to take the leap.

For reasons such as its accessibility from San Francisco, Medellín is a great choice for my first solo adventure out of the wealth of places I haven’t visited. My plan was to explore for a week, and then work remotely as the creator of Coinverse, the first cryptocurrency news audiocast app.

Reasons to come here

Balance of city and nature

Sitting on the beach is great for a few days, but I prefer an active approach to exploring via running, hiking, eating, drinking, and wandering. Medellín is a balance of a vibrant city with unique culture and history, nested in the valley, between the mountains and rainforest.

Parts of the city, like El Poblado, contain natural greenery and flowing streams throughout the neighborhood, while hiking opportunities are only a short rideshare away.

Culture

Everyone I know who has traveled here shares how welcoming and joyful the people are. It’s inspiring how Medellín has transformed in the last two decades. There are many markets to explore for food, crafts, and art, as well as unique buildings spanning many time periods and outside influences.

Tech

Theoretically, I can work on Coinverse from anywhere. However, Medellín has growing nomad and local developer communities. These communities are easy to access with platforms such as Meetup and Facebook.

Once connected to a few like-minded individuals, you begin discovering other groups. For example, after working at Selina coworking for a week, I was part of an informal lunch club with a diverse group of people.

Affordability

Medellín is relatively affordable compared to most cities in the US, especially San Francisco, where a meal in a restaurant may cost one-half to two-thirds more.

The city of coincidences

As Juan drove down into Medellín, he sensed my excitement as the panoramic views of the city emerged from the valley. Without asking, he stopped three times in order to take my picture.

A less-than-rigid schedule leads to opportunities to make unique connections where you may meet someone and end up talking for hours. I planned my trip not knowing anyone in Medellín.

Right before leaving, I saw a post from someone I met twice, Mary Evans, looking for a roommate starting the day I left the hostels. This set the theme for the coincidences.

The second week, at Urbania Café, I saw a potentially familiar face. Derek Pankaew is the co-founder of one of my favorite Kickstarters. After Derek caught me studying his website on my laptop, he introduced himself, and we had lunch, brainstorming ideas for hours.

Discovering how cryptocurrency is having real-world impacts is important to me. I had not found such projects online when a guest of the apartment arrived my second to last week. I mentioned the project I’ve been working on.

This led to my new friend teaching me about how Medellín is a major city for crypto, using Dash, a project creating financial freedom for everyday people. As I continued to ask questions, we talked the whole day, and I was invited to dinner with a developer working on Dash, which led me to meet other people in the Dash community.

Lastly, when shopping for pull-up rings, I was confused when Google led me to a residential building. Upon realizing I accidentally went to Sports Fitness’ corporate office rather than the store, I assumed they would send me away.

After communicating my desire to acquire $30 pull-up rings, we talked for over an hour, and I left with an offer I couldn’t refuse, free pull-up rings in trade for sharing e-commerce insights.

Originally, I planned to be in Medellín for a month and then ended up extending it to two and a half months. You’ll see why in my posts on the best food, local activities, and working remotely. Follow me to stay tuned.

Next up, exploring the classic foods, activities, and how to work effectively.

Medellín — A taste of classics and the best cacao

Medellín — Discover the local appeal

Medellín — Work remotely

Adam Hurwitz enjoys sharing travel open info and is a researcher and product consultant.

Originally posted on Hacker Noon.

With how volatile the crypto market is, in order to achieve success it’s vital to find projects that are positioned for long-term success. Given how useful 1inch is to the DeFi community and its potential, the goal of this is to understand the governance around minting new tokens, and not as a “gotcha”.

After a user on Reddit called out that there is a function in the smart contract allowing the team to create unlimited tokens, I became interested in looking at the max token supply of 1inch.

My interest increased when a moderator on 1inch’s Discord denied the existence of this feature in the code. Being skeptical that no one has had already looked at this given 1inch’s popularity and success, I reluctantly went traveling down the wormhole of learning how to deploy the code onto the testnet to see for myself.

Unlimited 1INCH Token Supply

What are the governance mechanisms around minting more tokens? This creates implications for many of the 1inch.exchange services that rely on the value of the 1INCH token if the token can be inflated just like fiat currency.

With often having one of the best values for swapping between ERC-20 tokens and the best selection of tokens, 1inch quickly gained popularity and value. In January 2021 the 1INCH token was worth ~$1.00 and grew over 300% to now in May 2021, even after this market cycle’s largest pullback yet.

Currently, DeFi Pulse has 1inch at the eighth-largest decentralized exchange (DEX) in terms of USD total value locked, right under ~$82m, down from $1.5b at the end of Q1 2021.

1inch offers more services than most standalone DEXs, from aggregating other DEX prices, offering earnings via staking in liquidity pools and liquidity mining, and rewarding users for holding 1inch’s governance tokens, 1INCH. This is where it becomes important to understand the 1INCH token and its maximum supply, or lack thereof.

As Cointelegraph reported on December 25, 2020, there is a claimed total token supply of 1.5b 1INCH. 1inch is built on top of OpenZeppelin’s set of Solidity smart contracts.

As smart contract developer Zachary Fogg (@zfogg) explains, typically, tokens with a limited supply built with OpenZeppelin, call the renounceOwnership function after the initial token creation in order to limit the ability to create or mint more tokens.

On line 1119 of 1nch’s smart contract, there is an external “mint” function that allows for the creation of new tokens. This functionality is removed by calling the above renounceOwnership function. According to all of the functions called in 1inch’s smart contract, renounceOwnership has never been called.

Governance

The main question is what is the governance for the 1inch Gnosis multisig wallet?

There is an OwnershipTransferred event to a Gnosis multisig wallet. This could be tied to a governance model around token creation. However, the 1inch team has not confirmed this via Discord, a Reddit post, and Twitter post.

An admin on the 1inch Discord denied the existence of the external “mint” function, but it is unclear their relationship to the 1inch core team. In addition, the question was posed to 1inch investor, Pantera Capital, during a conference call and via email, and their clarification is being awaited.

Minting New Tokens

Creating new 1INCH tokens is tested by deploying the 1INCH smart contract on the Ethereum Ropsten testnet. First, the initial 1.5b 1INCH tokens are created. Then, using the external mint function, we can create however many new tokens are desired. In this case, 3b new 1INCH tokens are created.

With a compelling product offering many services, it will be great to understand if there is a reasonable explanation in regards to the new creation of 1INCH tokens.

The best-case scenario is that there is a governance system set up around the Gnosis multisig wallet and that this system defines when and how new tokens are created.

Follow me on Twitter to stay connected.

(Disclosure: I own a small amount of 1INCH tokens)

Local unit testing using JUnit 5 and MockK

You’ve spent too much time testing if you have had to reconfigure a feature’s code to make it testable or have debugged the ordering of actions/events and the resulting test output. Using the Model-View-Intent pattern (MVI) provides the ability to test built-in to the pattern following the best practice of Test Driven Development (TDD).

If you’re not familiar with MVI, the pattern structures how information is shared and how views are created and updated. MVI defines a clear contract between the view and business logic with an interface that is a one-way, immutable, unidirectional data flow (UDF) pattern. The structure of MVI grants the ability to implement with any reactive framework, such as Kotlin Coroutines, RxJava, and LiveData.

The last post, Android Model-View-Intent with Kotlin Flow, provides a comprehensive overview of the MVI pattern used in the Coinverse cryptocurrency news app. It compares MVI to a forest transferring information via its’ highly structured fungi network. If MVI 🌲 ️is like an intelligently designed forest’s ecosystem, then the unit tests 🐝 are the insects that feed off the fungi network and know whether it is poisonous, or in our case, contains errors.

Coinverse code

AdamSHurwitz/Coinverse

Also available on the Play Store.

Overview

Advantages

Implement

Summary

Advantages

🙋🏻 Why Local Unit Tests?

Local unit tests with JUnit 5 can be run quickly prior to writing a feature and regularly to ensure code quality and mitigate regressions of features’ business logic. These tests do not require dependencies on the Android system. This covers the majority of code for most apps making it a great first step for testing. These local unit tests can be expanded into integration tests for more thorough testing of the data layer, such as network requests and local databases, and for instrumented tests including the UI components.

🥼 Built-in testing

Once modularized properly, the business logic model, in this case Android’s ViewModel component, and the view interface contract used in production are also used for local unit tests without modification to test the given intents that the model uses to generate the expected view states.

MVI defines the intents driven by the Android system and user actions that the model processes to create the view states. Because the ViewModel business logic component observes the intent actions and creates the final persisted data of each view state, a local unit test makes use of the existing ViewModel and view interface contract.

🏎️ More efficient code

Creating intents and view states with MVI reduced the test code by more than 50% compared to the previous implementation using the UDF and emitting many streams of data simultaneously.

100% of FeedViewModel.kt is covered in local unit tests in Coinverse with MVI comprising 306 lines of code in the FeedViewTest.kt class, compared to 753 lines of code across four test classes covering mostly the same code prior to the MVI refactor. In the pre-MVI pattern, UDF was implemented to separate the view, business logic, and data layer. However, many sources of data were emitted from the ViewModel to the View making the tests harder to read, write, and created issues with the order of data being emitted. By knowing exactly what view state should be emitted based on each intent with MVI, it makes the tests more reliable, quicker to build, and more concise.

Implement

📚 Libraries — Step 1 of 5

• JUnit 5 with parameterized tests — Reuse the tests with a stream of many test cases.
• MockK — Creates components involving the Android system or classes handling data requests like a repository or database, returning data that would be expected to be returned in the loading, success, and error states.
• Kotlin coroutines — Initiate intent actions and observe view state changes with StateFlow.
• AssertJ — Evaluates the actual vs. expected states.

build.gradle (Module)

build.gradle (App)

Releases/Versions

• JUnit 5
• MockK
• Coroutines
• AssertJ

💼 ViewModel — Step 2 of 5

A. Define how components are injected

In order to use the same business logic in production and testing, all components that rely on the Android system or data requests are injected into the ViewModel so that test instances can be used in the local unit tests.

See: Android Model-View-Intent with Kotlin Flow > Model — ViewModel > ‘CoroutineScope and CoroutineDispatcher’ and ‘Dagger 2 Dependency Injection for ViewModels with AssistedInject’

FeedViewModel.kt

1. CoroutineScope — With the custom extension function,getViewModelScope, for production no scope is injected and the Android’s viewModelScope is used by default. In testing the TestCoroutineScope is explicitly injected.
2. FeedRepository — Data requests made to the network and local database will be mocked requiring a test instance of the repository to be injected.

B. Create the test components to inject

FeedViewTestExtension.kt

1. TestCoroutineDispatcher and TestCoroutineScope are created in a JUnit 5 test extension. The dispatcher is necessary to ensure coroutines run on a test thread and the scope defines the lifecycle that the coroutines runs within.
2. The ArchTaskExecutor is required for LiveData to return the PagedList.

See: Android Unidirectional Data Flow — Local Unit Testing > 1a. Configuration — Extensions

FeedViewTest.kt

1. The mock repository is initialized and passed into the ViewModel along with the TestCoroutineScope created in FeedViewTestExtension.kt above.
2. The repository method getMainFeedNetwork's response is mocked to return test data. In the full sample code this emits a Flow of PagedList data. With the Paging 3 library this can be simplified removing the dependency to mock LiveData asPagedList and return a PagingData response with Kotlin coroutines. See StackOverflow for Paging 2: Convert List Into PagedList With Mock DataSource.Factory
3. The FeedViewTestCaseStream is a Stream.of(...) FeedViewTestCase defined in a data class and represents different scenarios such as loading, success, and error states. The stream is passed into the test making the test reusable for all of the states defined.

🌉 Interface — Step 3 of 5

Bind the view interface contract to the ViewModel

1. The majority of logic tested is defined by implementing the view interface and binding it to the ViewModel. The interface represents the intent/actions sent from the view to the ViewModel, and the view states rendered by the ViewModel back to the view. See: Android Model-View-Intent with Kotlin Flow > Intent — View Interface
2. The view’s StateFlow intents are defined in FeedViewIntent for organizational purposes. See: Android Model-View-Intent with Kotlin Flow > View — Activity/Fragment
3. The test view interface observes emissions from the intent Flows and the test view interface renders a view state sealed class as it would in production.

FeedViewTest.kt

🖼️ Intents and View States — Step 4 of 5

1. Call the intents/actions that initiate the business logic to generate a view state, in this case, loadFromNetwork intent is emitting a true value which initiates the FeedViewModel to create the Feed state. Then, observe that the actual view state of type Feed matches the expected state.
2. isEqualToComparingFieldByField is used to compare the properties of the actual and observed Feed view state emitted. Feed is a class rather than a data class so that each instance of Feed has a unique hash code and can be properly emitted by the model.

FeedViewTest.kt

🔬 Verify and Confirm Method Calls — Step 5 of 5

1. The MockK verification coVerify confirms that the method getMainFeedNetwork is called within the test.
2. confirmVerified checks that all method calls in the test are verified/expected to be called.

See: Android Unidirectional Data Flow — Local Unit Testing > 5. Verify Tests

FeedViewTest.kt

Summary

⚠️ UDF Without MVI

From Step 3 of 5 — Interface section above when a view state is rendered, we can see how much more complicated this is compared to UDF emitting many data types simultaneously. In this case, loading the feed data is done by observing two emissions of data, the view state, and a one-time view effect to update ads. This also creates ugly code nesting, and is harder to read vs. creating one view state with all of the view’s final persisted data contained.

See: Android Unidirectional Data Flow — Local Unit Testing > 4. Make Assertions

FeedLoadContentTests.kt

🌊 Alternatives to Kotlin Flow

The Kotlin Flow implementation is powerful and concise in handling threading, lifecycle scope, and allowing for mutable and immutable flows.

MVI also works well for testing with other reactive frameworks as well.

• RxJava’s Subject or Relay are also solid options for MVI in the data, view state, and view layers.
• LiveData can be used to achieve the tests above for the view state layer using MutableLiveData and LiveData. It is not recommended for the data request repository layer as LiveData is tied to a view’s lifecycle scope and some data requests may need to be decoupled from the UI.
• Callbacks could work in theory, but run the risk of becoming overly complicated with both the view and the ViewModel implementing listeners to send actions from the view to the ViewModel and rendering view states from the ViewModel to the view.

Whichever tool is chosen, the MVI pattern separates the view, business logic, and data requests as well as modularizes the various features into view states make initiating the user and system actions and testing the generated view states from the model accessible.

🌱 Next Steps

Now that local unit tests are created for the business logic using the MVI pattern, there is a foundation to expand upon for integration and instrumented tests.

• Integration — Components the app is dependent upon such as network requests and local databases. Retrofit requests can be tested using MockWebServer and a Room database can be tested by creating a database with a test app context using Robolectric.
• Instrumented — End-to-end behavior of a real device or emulator. UI tests can be incorporated with Espresso.

Explore Coinverse on the Google Play Store or the open-source code. Please clap if you like the above. The longer the clap button is pressed the more claps. 👏🏻

📝 Notes

• MockK
• JUnit Tests
• Model-View-Intent

I’m Adam Hurwitz, writer of code and more. Follow me on Twitter.

Android Model-View-Intent with Unit Tests was originally published in ProAndroidDev on Medium, where people are continuing the conversation by highlighting and responding to this story.

Update from Unidirectional Data Flow with LiveData

You may think of ‘magic mushrooms’ when you hear ‘fungi network’. However, just like the Model-View-Intent (MVI) pattern, the forest’s organized fungi network of a connected info sharing system, like Model-View-Intent’s pattern, is indeed not magic.

The Unidirectional Data Flow (UDF) pattern does a great job to ensure information is sent in one direction from the view to the business logic, is retrieved, and processed in order to build the view. UDF alone does not organize how the data processed. The Model-View-Intent pattern structures the design of how information is shared and views are created. MVI defines a clear contract with the view and business logic using UDF. MVI🌲 ️is like an intelligently designed forest’s ecosystem vs. a one-way wave of info and events with UDF 🌊 used by itself.

Coinverse code

AdamSHurwitz/Coinverse

Also available on the Play Store.

Overview

Advantages

Components

Implement with Kotlin Flow

• Model — ViewModel
• View —Activity/Fragment
• Intent — View Interface

Alternatives

Summary

Advantages

UDF

By itself, the Unidirectional Data Flow provides organization and performance benefits.

• 🌊 Linear flow — View initiates events from the user and system to generate and return immutable data.
• 📡 Async event control — Set the lifecycle and threading for the creation of the view data in the business logic.
• 💼 Reusability — Utilize common business logic across multiple views.

MVI + UDF

Model-View-Intent builds upon Unidirectional Data Flow, better organizing the UI and business logic into view states and creating a clear contract between the UI and business logic with an interface.

• 🖼️ UI modularization — Define the final UI results emitted and rendered in an interface contract and view state.
• 🏗 ️Scaling — Reuse code with clear organization.
• 🥼Unit test simply —Build tests by observing the existing view state results from the business logic.
• 🐛 Debug quicker— Examine the current view state emitted to determine the root cause.

Kotlin Flow

• 🏎️ Quick setup — Requires fewer libraries compared to Rx.
• ♻️ Lifecycle management — Inherently controls the lifecycle of the operation upon launch.
• 🧵 Threading management — Can be handled in one place when the flow is launched rather than each time data is observed. Additional customization can be added if needed.
• 👻 Avoid nesting nightmares — The callback style pattern is harder to work with and creates the need to initialize instance variables within a function to retrieve information from within nested logic.
• 🎨 Customization — The core c lasses, methods, and inherited classes and interfaces are clearly readable making it possible to edit or add functionality with extension functions.
• 🚦 Ease-of-use — It is easy to learn new topics via reading the good ol’ documentation. The docs provide interactive examples.

Components

By implementing Model-View-Intent with immutable intents and observing immutable state data, the architecture takes advantage of a Unidirectional Data Flow pattern.

Note: ‘Intent’ is used as a naming convention for events or actions in an app and is not the same as Android system level Intents.

Model

• Implement with a ViewModel, also referred to as a Presenter in other implementations.
• Observes the requests for new actions or data requests from incoming intents and processes the business logic from the intent requests
• Creates the view states
• Stores the view state data on lifecycle changes
• Emits an immutable state

View

• Implement with an activity/fragment.
• Displays the view state
• Initiates events/actions by the user or the Android system

Intent

• Implement with a view interface.
• Defines the contract between the UI and business logic
• Creates the immutable intents that return an observable object from the view to the ViewModel
• Creates the method(s) to render the view state(s) from the ViewModel to the view

Implement with Kotlin Flow

Model-View-Intent can be implemented with any reactive framework. StateFlow and MutableStateFlow’s introduction in Kotlin coroutines’ 1.3.6 release makes Flow a fantastic framework from the view to the repository level. Mutable data can be updated privately as instance variables within a class and observed publicly as an immutable value.

Add the kotlinx.coroutines library with the latest version to build.gradle.

Model — ViewModel

FeedViewState.kt

1. A Sealed class defines the view state group FeedViewState
2. Each UI module in the view state, Feed and OpenContent are defined as a sub-class. If there is a state that emits the same data values, but represents a unique event, use a class as a data class will consider these classes’ hash code equivalent, and not emit the state. For example, when the same info can be returned more than once consecutively.

To re-use the ViewModel for more advanced use cases, the ViewModel can handle multiple types of sealed class view states.

FeedViewModel.kt

1. The view state is a private MutableStateFlow. Values can only be added from the ViewModel ensuring only the ViewModel can create/update the state.
2. The FeedView defines the intents and the contract between the model and view. It is passed into the ViewModel through a public function bindIntents that initiates observing all of the view intents. The intent Flows loadFromNetwork and selectContent are observed with onEach or the custom extension method onEachEvent for one-time events, described below.
3. The state is created or updated based on the Resource.kt status LOADING, SUCCESS, and ERROR of the data request.
4. The view state changes are observed in the initState intent Flow and sent to the Fragment via the FeedView interface render function.

One-time Events

One-time events don’t persist and include navigation, dialogs, or errors. To handle this with Flow, an Event.kt wraps one-time Flows and is emitted with the custom extension function onEachEvent. LiveData with SnackBar, Navigation and other events (the SingleLiveEvent case) by Jose Alcérreca explains this issue well in a discussion about LiveData. The event concept applies to all reactive frameworks.

CoroutineScope and CoroutineDispatcher

For JUnit tests, it is important to manually pass the CoroutineScope into the ViewModel and use the custom getViewModelScope function to return the appropriate scope inside the ViewModel.

The same thing goes for the CoroutineDispatcher which is not used in this example but can be implemented with Craig Russell’s DispatcherProvider included in ViewModelUtils.kt.

Dagger 2 Dependency Injection for ViewModels with AssistedInject

Gabor Varadi’s Dagger Tips article provides a clear implementation guide. Moving forward, Dagger Hilt will simplify ViewModel injection once released in production.

View — Activity/Fragment

FeedViewIntent.kt

Private mutable intents can be initialized directly in the view or abstracted to a class like in FeedViewIntent.kt that defines the intents and data classes used.

1. Intents the Fragment will use to pass Flow data to the ViewModel through the FeedView interface.
2. Data classes the intents use to pass info.

FeedFragment.kt

1. Initialize the mutable intents stored in FeedViewIntent.
2. Bind the FeedView interface to the ViewModel in onViewCreated to begin observing the intents defined and emitted from FeedView.
3. Implement the functions defined in FeedView that emit Flow data to the ViewModel by overriding the interface functions.
4. Emit Flow data intents. a)initState returns a true Flow by default as it is responsible for binding all of the view states in the ViewModel when the view is created. b) loadFromNetwork occurs when the view is created for the first time. c) selectContent emits when an item in the newsfeed is selected by the user in FeedAdapter.kt.
5. render binds the view state from the ViewModel to the view. The state values are used to create the UI as one would normally build and bind UI views.

Intent — View Interface

The view interface is the connective network of Model-View-Intent, as it defines the contract of how the view and business logic interact, shares intents to the ViewModel, and renders the view states to the UI.

1. initState, loadFromNetwork, and selectContent are functions that return a flow emitted from the view to the ViewModel.
2. render binds the view state emitted from the ViewModel to the Fragment. FeedView manually injects states into the view from the ViewModel vs. observing many pieces of data in different places liked done before in the Unidirectional Data Flow.

Multiple render functions can be defined if more than one view state sealed class is needed.

Alternatives

RxJava’s Subject or Relay also work well with MVI. LiveData can be used too but will add undue complexity.

LiveData

Prior to utilizing Kotlin Flow, LiveData was the reactive framework in both the repository responses and ViewModel view state in version one, Android Unidirectional Data Flow with LiveData.

Not a good fit for Repositories — As outlined in Android Unidirectional Data Flow with LiveData — 2.0, ‘LiveData Can be Problematic in the Repository’ because its’ subscription is tied to a view lifecycle. LiveData is not relevant for non-UI related transformations where data needs to be processed in the Repository or ViewModel prior to populating the view state.

Adds view state complexity — After refactoring Flow to replace LiveData in the Repository, LiveData is still used in the view state. Additional complexity remains due to the need for a mutable and immutable view state class. Again, because LiveData is bound to a view’s lifecycle, a mutable view state cannot be initiated and observed in the ViewModel as with Flow or RxJava. As a workaround, the mutable view state adds values in the ViewModel, and the immutable view state is observed directly by the view instead of being emitted in the ViewModel through an interface contract like withFeedView.

With Flow, the ViewModel observes state changes bound to the ViewModel as seen above where getViewModelScope sets the lifecycle to viewModelScope. With the release of StateFlow, Roman Elizarov, Kotlin Libraries Team Lead, also recommends to consider using MutableStateFlow as a MutableLiveData replacement.

RxJava

For a comparison of Kotlin Flow and RxJava strengths see Android Unidirectional Data Flow — Kotlin Flow vs. RxJava. Spoiler, Kotlin Flow requires less setup than RxJava, manages the lifecycle by default, handles threading cleanly, avoids nesting, allows customization with extensions, and is relatively easy to use. Rx is still a great and powerful option as it has been battle-tested over the past six years and at the time of this post, holds the vast majority of market share in adoption for Android reactive frameworks.

Summary

The Unidirectional Data Flow 🌊 is a great initial step. With the addition of Model-View-Intent 🌲, and considering well-defined view states, it improves performance, read, and testability for the Coinverse beta app. Best yet, as MVI was originally popularized in JavaScript’s Cycle.js, this pattern is effective across languages, frameworks, and platforms.

View Contract

The biggest takeaway for me is the view interface intents contract, FeedView. The FeedView contract is a concise map of all of the functionality between the view and the ViewModel. This concept was introduced to me by Yigit Boyar on the core Android team at the 2019 Android Dev Summit during an ‘office hours’ style session and took me time to realize how to refactor UDF into MVI + UDF properly.

Unit Tests

With the initial UDF Coinverse local JUnit 5 tests I spent too much time to debug the order of events fired and values observed. MVI will simplify this because instead of observing many individual values, each view state is observed as the direct result of an intent. Follow me on Medium for updates on using MVI for local Junit 5 tests.

This pattern is largely inspired by Hannes Dorfmann’s epic eight-part series, Reactive Apps With Model-View-Intent using RxJava. Hannes is also the creator of the Android MVI library Mosby. The series is summarized in episode 103 of the Fragmented podcast with Kaushik Gopal and Donn Felker. I highly recommend these resources. Also, thanks to Michael Huh for our discussions on your team’s version of MVI. It took me multiple times to fully digest the concepts so it is worth taking your time.

Explore Coinverse on the Google Play Store or the open-source code. Please clap if you like the above. The longer the clap button is pressed the more claps. 👏🏻

📝 Notes

• Model-View-Intent
• Kotlin Flow
• Dagger Dependency Injection

I’m Adam Hurwitz, writer of code and more. Follow me on Medium.

Android Model-View-Intent with Kotlin Flow was originally published in ProAndroidDev on Medium, where people are continuing the conversation by highlighting and responding to this story.

Android Unidirectional Data Flow — Kotlin Flow vs. RxJava

The network, database, and view states

One of the many great things about the Unidirectional Data Flow (UDF) to organize an app’s logic is that it works with any reactive programming pattern, whether it be Kotlin coroutines Flow (Flow), ReactiveX (Rx) based RxJava/Kotlin, or LiveData. Kotlin coroutines version 1.0 was released at the end of 2018 and anecdotally has quickly been gaining adoption, alongside functionality. However, a large portion of apps have been built pre-late 2018 and rely on Rx. This makes both Flow and Rx important tools to be equipped with when working on a diverse set of codebases.

Spoiler — Kotlin Flow requires less setup than RxJava, manages the lifecycle by default, handles threading cleanly, avoids nesting, allows customization with extensions, and is relatively easy to use.

CryptoTweets sample code

AdamSHurwitz/CryptoTweets

Previous

Android Unidirectional Data Flow with LiveData — 2.0

Overview

Recap

Additional setups required

Data layer

• Retrofit network requests
• Room database with Paging library

View states

Summary — Advantages of Kotlin Flow and RxJava

Recap

🏗 UDF Structure

1. The view creates events initiated by the user or Android lifecycle.
2. The ViewModel requests data from the repository layer.
3. The repository returns data from the network/database.
4. The ViewModel creates/updates the view state, comprising the UI, and effects, which are one-time events like navigation or error-handling.
5. The view observes the view states/effect changes.

💪🏻 UDF Strengths

• Linear flow of app logic with events initiating the data returned
• Control UI & async events
• Pre-defined test structure
• Quicker debugging

Additional setups required

In addition to implementing the core libraries for Retrofit, Room, and the Paging tools below, additional setup is required for Flow and Rx.

Core functionality

🌊️️️ Flow — Add kotlinx.coroutines

• When creating a new project in Android Studio select Kotlin as the language under the Configure your project step.
• For creating/updating the view state and effects, in addition to Flow, the kotlinx.coroutines library, starting with release 1.3.6, provides StateFlow and MutableStateFlow similar to LiveData’s immutable and mutable variants.

⛓️ Rx — Requires two additional libraries

• RxKotlin library for standard Rx functionality including RxJava
• RxAndroid library for Android-specific functionality like using the main thread with AndroidSchedulers.MainThread

Retrofit network requests

🌊 ️️Flow — Works out of the box

⛓ Rx — Add RxJava adapter to Retrofit.

• There are different RxJava adapter libraries based on the RxJava version number, as outlined in this StackOverflow post.

Room SQL database and Paging library

️🌊 Flow — Requires two additional libraries

• Room ktx extensions to enable Room to handle background threading
• LiveData lifecycle to convert the LiveData PagedList into a Flow using the asFlow extension method

⛓️ Rx — Requires two additional libraries

See: Room 🔗 RxJava

• Room database rxjava2 for local SQL data storage
• Paging rxjava2 to connect the Room database to a RecyclerView

Additional setups summary

In addition to the normal Retrofit, Room, and Paging setups, Flow requires fewer libraries compared to Rx.

build.gradle(:someModule)

🌊 Flow

⛓️ Rx

Data layer — Retrofit network requests

Being able to handle both one-time requests and constant streams of information from the network are key capabilities of reactive programming.

Request return type

The type required for Flow, of a List, is simpler than using an Observable. Flow’s functions are slightly more complicated requiring the suspend modifier. However, this modifier allows Retrofit to handle background threading by default, as opposed to explicitly defining the threading when the Flow is launched. Also, returning a list is useful to handle information more easily as we’ll also see in the Check response status section below.

FeedService.kt

🌊 Flow

⛓️ Rx

Backpressure

The sample in CryptoTweets showcases a simple one-time request. However, it is worth mentioning more advanced cases in which Flow and Rx have the ability to handle constant streams of data that may lead to backpressure. Backpressure is when there is an ongoing and incoming stream of data that needs to be processed. For instance, this can be from a web-socket type network request that maintains a constant connection. Managing backpressure requires processing the incoming data without causing issues such as slowing down the UI, crashing the app, or losing important information.

🌊 Flow

Coroutines handle backpressure by default with the flow/collect pattern by managing data streams synchronously. Flow by default performs sequentially. The code runs one emission from within the source flow, then one collection is run. This process continues until all of the data is processed.

You would not see any code that explicitly handles back-pressure, because it automatically happens behind the scenes due to the support for suspension that is provided by Kotlin compiler. — Roman Elizarov (Kotlin Team Lead), Reactive Streams and Kotlin Flows

Coroutines offer further strategies to handle backpressure and improve the speed of which data is processed.

• buffer — Runs the source data concurrently. If the collector is slow the data inside the source can still be pre-processed or manipulated so that when the collector is ready the data can be returned faster than if the source data was processed sequentially by default.
• conflate —This speeds up returning data by only returning the latest value, thus not returning all of the data from the source.
• collectLatest — Slow collectors are cancelled and restarted each time new data is emitted to increase the speed of data returned.

⛓️ Rx

By default, an Observable will not manage backpressure. If there is an existing source emitting data, and then is later observed, the data prior to the observation/subscription will not be processed. Instead, Rx handles backpressure using a Flowable which defines the strategy to handle backpressure.

• BackpressureStrategy.BUFFER — Allows the source to hold the data until the subscriber can consume it, similar to what coroutines do by default
• BackpressureStrategy.DROP — Discards events that cannot be consumed in time by the subscriber.
• BackpressureStrategy.LATEST — Overwrites previous data with new data if the subscriber is behind. This is most similar to coroutines’ conflate, because conflate skips intermediate values, but does not explicitly remove or drop them.

See: RxJava 2 — Flowable, Baeldung

Check response status

After receiving information from a network request, doing a quick check on the status of the information is often required.

🌊 Flow

Because the threading and lifecycle are defined at the initialization of the flow as shown in the Process data section below, the tweetsResponse may simply be checked for emptiness.

FeedRepository.kt

⛓ ️Rx

This requires subscribing to to the data and defining the threading in order to do a basic check, like whether the data is empty.

1. subscribeOn — The thread that will launch the process
2. observeOn — The thread the data will be returned on.
3. subscribe — Returns the data. This pattern also creates a layer of nested code.

FeedRepository.kt

Process data

🌊 Flow

When the Flow is initialized the lifecycle is defined with launchIn. The viewModelScope lifecycle inherently defines the Dispatchers.Main.immediate thread for data to be returned on. The lifecycle is automatically managed by the Android ViewModel using viewModelScope, and will be destroyed when the ViewModel is destroyed. Returning data on the main thread is appropriate because the the view state and UI are being populated/updated.

The logic within initFeed performs Retrofit and Room database tasks which if configured properly handle background threading by default. In other cases, flowOn needs to be defined explicitly before launchIn. i.e. flowOn(Dispatchers.IO) since the IO thread is appropriate for network and database tasks.

FeedViewModel.kt

Side note — The difference between Dispatchers.Main.immediate and Dispatchers.Main, as Craig Russell explains in Launching a Kotlin Coroutine for immediate execution on the Main thread, is Dispatchers.Main requires a check first to ensure it is on the main thread, whereas Dispatchers.immediate assumes it is on the main thread and performs right away.

⛓️ Rx

1. The threading is defined with the same methods as in Check response status above.
2. CompositeDisposable — Manages the Observable lifecycle. By adding the Observable to a CompositeDisposable, all of the created Observables can be cleared in the view activity/fragment onDestroy method by calling the public method in the ViewModel clearAndDisposeDisposables.

FeedViewModel.kt

Data layer — Room database with Paging library

Inserting and querying data from the DAO

🌊 Flow

Both use a DataSource.Factory in the data access object in order to insert and query data from the Room SQL database. Flow utilizes the suspend modifier in order for Room to handle background threading by default. Again, this is opposed to explicitly defining the threading when the Flow is launched.

⛓ Rx

FeedDao.kt

Creating a PagedList

🌊 Flow

1. getAllTweets — The FeedDao queries for data and the extension function toLiveData builds LiveData of type PagedList. toLiveData handles threading on an IO background thread.
2. asFlow — Converts this into a Flow of type PagedList bringing the data back onto a Main thread.
3. tweetsQuery — Data can be collected using collect and emitted using emit to the ViewModel which initiated the repository data request.

Additional threading management could be added using withContext if further processing is required on other threads. Otherwise, the threading has already been defined when this method was initiated in the ViewModel above.

FeedRepository.kt

⛓️ Rx

1. The process here is similar, but using toObservable extension function to convert the query directly to an observable instead of to LiveData first.
2. Threading is managed twice, first off in the ViewModel when building the view states and effects and initializing the repository request, and secondly here in the repository when processing the data.

FeedRepository.kt

View states — States + effects

Regardless of the reactive implementation for the view state, (Flow, Rx, LiveData, etc.), there are both view states and effects to update in the ViewModel that create the user experience observed in the view, (activity/fragment).

• View states — Final persisted data of a screen that is displayed continuously to the user
• View effects — One-time occurrences that don’t persist such as errors, dialogs, and navigation actions

View state

🌊 Flow

1. lifecycleScope — Handles threading by default with lifecycleScope, returning the UI data onto the Dispatchers.Main.immediate thread the same as viewModelScope above.
2. MutableStateFlow — Sets and updates the view state data in the ViewModel with a private mutable data class.
3. Flow— Updates the public non-mutable view state that is observed by the view, in this case a fragment. The view effects follow the same pattern.
4. filterNotNull — Allows the view state to be initialized as null when the ViewModel is created without emitting null values to the view.

FeedViewState.kt

FeedViewModel.kt

FeedFragment.kt

⛓️ Rx

1. BehaviorSubject — Rx Subjects are both an Observer and an Observable, allowing their data to be mutated and observed. BehaviorSubject is a great fit for the view state and effects because the most recent value is emitted to the observers, and then any new values added during the lifecycle of the subscription are also emitted. The original design of the Rx view state in this sample used a ReplaySubject. All values are added to a ReplaySubject are emitted to its’ subscribers. With ReplaySubject, past values could potentially update the view state that are outdated. The Subject type used depends case-by-case.
2. All observers in the fragment must be cleared too in addition to clearing and disposing of the CompositeDisposable in the ViewModel above. With LiveData and Flow, the lifecycle is handled by default. This is a tradeoff if deciding between LiveData and Rx because LiveData handles lifecycle by default, whereas Rx allows specific emission strategies by default.

See: Exploring RxJava in Android — Different types of Subjects, Anitaa Murthy

FeedViewState.kt

FeedViewModel.kt

FeedFragment.kt

View effects

The issue with any reactive programming pattern for one-time events is that they will be re-observed by the subscriber after the initial one-time event has been emitted. Jose Alcérreca describes the SingleLiveEvent case in the context of LiveData. Both the issue and solution based on an event wrapper pattern can be applied to any reactive pattern.

For reach reactive pattern the type contained within the reactive object will be wrapped in an event. You can test this out by subscribing to a one-time event multiple times after emitting it once in the ViewModel and logging the value before and after implementing the Event.

Event.kt

🌊 Flow

The view effect is similar to the view state with the only difference being the Event wrapper class.

FeedViewEffect.kt

FeedViewModel.kt

It is easy to create customized utility functions with Kotlin. The one-time event is a perfect use case. Instead of manually checking in the view whether the event has already been emitted with getContentIfNotHandled from the Event class, this is performed automatically in a custom utility function onEachEvent, customizing the coroutines’ Transform.kt onEach extension function.

OnEachEvent.kt

FeedFragment.kt

⛓️ Rx

FeedViewEffect.kt

The same Event class is used as the BehaviorSubject type.

FeedViewModel.kt

FeedFragment.kt

getContentIfNotHandled manually checks to see if the event has already been observed.

subscribe is written in Java and cannot be created as easily as the onEachEvent extension function for Kotlin Flow. I’m open to pull requests if you’d like to customize subscribe. Good luck.

⚖️ Summary — Advantages of Kotlin Flow and RxJava

In cases working with legacy code or teams not yet onboard with Kotlin Flow, it is important to be able to write well structured code with Rx so that all of the developers working on common code adopt a similar strategy. Given the opportunity to create a new app/feature, Kotlin Flow has a short learning curve, built-in integrations with Android components and widely adopted open-source libraries, and expanding it’s use cases rapidly.

🌊 Flow

• 🏎️ Quick setup — Requires two fewer libraries compared to Rx.
• ♻️ Lifecycle management — Inherently controls the lifecycle of the operation upon launch.
• 🧵 Threading management — Can be handled in one place when the flow is launched rather than each time data is observed. Additional customization can be added if needed. This results in cleaner and simpler code.
• 👻 Avoid nesting nightmares — The callback style pattern is harder to work with and creates the need to initialize instance variables within a function to retrieve information from within nested logic, like when creating the PagedList above.
• 🎨 Customization — The core classes, methods, and inherited classes and interfaces are readable and easy to understand the existing features in order to edit or add functionality with extension functions.
• 🚦 Ease-of-use — It is easy to learn new topics via reading the good ol’ documentation. The docs provide interactive examples for almost every topic to test, iterate, break, and understand. Does anyone truly understand the marbles diagrams in Rx? 🤔

⛓️ Rx

• 🧑🏽‍🏭Mass adoption — Most apps built pre-2018 use Rx.
• ⚔️️Battle tested APIs — Kotlin Flow contains many experimental APIs, indicated by@ExperimentalCoroutinesApi, which is temporary as the libraries mature.
• ⚙️Larger selection of operators — In CryptoTweets the data stream is simple, but in more complex cases, due to the maturity of Rx, there might be more advanced operators/transformations not yet available with Kotlin coroutines and Flow. For both CryptoTweets and the beta app I’ve published to the Play Store, Coinverse, I have not run into such cases where coroutines have not been able to do the job.

I’d love to hear in the comments below if there are operators you’ve come across for RxJava that are not yet available for Kotlin coroutines/Kotlin Flow.

Thus far, Andrey Bolduzev has pointed out Rx’s distinct operator for filtering only unique values for an entire subscription’s stream as outlined here.

Thank you to Roman Elizarov for the feedback regarding Kotlin StateFlow and Andres Rubiano Del Chiaro with RxJava! 🙏🏻 Please leave claps if you liked the above. The longer the clap button is pressed the more claps. 👏🏻

I’m Adam Hurwitz, writer of code and more. Follow me on Medium.

📝 Notes

• Kotlin Coroutines
• Kotlin Flow
• RxJava
• RxKotlin

Android Unidirectional Data Flow — Kotlin Flow vs. RxJava was originally published in ProAndroidDev on Medium, where people are continuing the conversation by highlighting and responding to this story.

Optimizing Android ViewModel with Lifecycle 2.2.0

Initialization, passing arguments, and saved state

The Lifecycle 2.2.0 update including simplified initialization with by viewModels(), by activityViewModels(), and by navGraphViewModels(...) syntax for the ViewModel (VM) component is great for quickly creating VMs. What about re-using the VM instance throughout fragments, passing arguments/parameters into the VM while also enabling saved state? With a bit of customization, the above can be achieved as I recently shipped in the latest version of the Coinverse app.

Sample Code

AdamSHurwitz/Coinverse

Setup

Initializing the ViewModel for Reusability

How to pass Arguments/Parameters to ViewModels

Enabling SavedState with Arguments/Parameters

Resources

Setup

To take advantage of the latest VM component, declare the most recent Lifecycle dependencies in the build.gradle (Module: app) file for lifecycle-viewmodel-ktx and lifecycle-livedata-ktx. The jvmTarget also needs to be defined in order to implement the by viewModels syntax we’ll use below.

If the navigation component version of the VM is being implemented, the navigation components’ libraries, navigation-ui-ktx and navigation-fragment-ktx are required.

Initializing the ViewModel for Reusability

As the ViewModel documentation outlines, a major advantage of utilizing VMs in an activity/fragment is the ability to save view state data that comprises the user interface. Otherwise, large portions of data would need to be reloaded every time there is a configuration change, or when the app temporarily goes into the background.

The documentation shows initiating the VM in onCreate as a method level var, and then later on as a class level val. Creating the VM in onCreate requires reassigning the variable on the class level in order to use the VM throughout the activity/fragment. For this reason, it’s preferred to create the VM as a class level val.

Rather than creating a lateinit var instance variable, declare a VM immutable val. The VMs values can only be accessed after the activity is attached to the application.

🔎 Differences between by viewModels, activityViewModels, and navGraphViewModels

• Use by viewModels when the activity/fragment creating the VM will be the only activity/fragment accessing the VM’s data.

Behind the scenes viewModels is an extension function applied to either an activity/fragment that returns a VM with a lifecycle tied to that activity/fragment. A VM factory may optionally be defined which can be used to pass parameters/arguments as we’ll see below.

• Use by activityViewModels in fragments, when the fragment is sharing data/communicating with another activity/fragment.

This is useful for sharing information between views. activityViewModels is an extension function applied to a fragment that returns a fragment’s parent’s activity’s VM. A VM factory may be defined here too.

• Use by navGraphViewModels(R.id.some_nav_graph) in a fragment where the VM benefits by being scoped to a specific navigation graph or nested graph.

This is useful for managing the business logic of features organized in a nested graph to ensure sure data is not leaked to other parts of the app, and that the lifecycle is handled properly. A VM factory may be defined here as well.

See: ViewModel and Jetpack Navigation : NavGraph with a ViewModel

📦 Storing view state data

The VM is a great location to store cached view state data using an observable data structure such as LiveData, Coroutines, or RxKotlin.

• Use immutable public values to observe data.
• Use mutable private variables to edit values in the VM.
• Use a pattern that allows the readability of the values in the VM, such as LiveData’s transform or Coroutine’s collect.

♻️ VM lifecycle overview

• Created the first time an activity calls onCreate
• When an activity is recreated, it receives the same VM instance.
• When the creating activity/fragment is finished/detached, VM’s onCleared is called

How to pass Arguments/Parameters to ViewModels

The advantage of passing data into the VM upon creation is that an important process may begin upon VM initialization, such as retrieving data to populate a view, rather than the process being tied to the fragment/activity lifecycle. This is important because as Lyla Fuijwara, a Google developer advocate explains, the VM instance is created once inside the activity/fragment. Then, the VM is stopped only when a user closes the view holding the VM, closes the app entirely, or if the Android system needs to clear the memory while the app is in the background.

If an initialization process is tied to an activity/fragment lifecycle event, it may unintentionally occur if the activity/fragment is recreated. When the process runs in the VM’s init{..} function, it will be tied to the VM lifecycle.

See: ViewModels: Persistence, onSaveInstanceState(), Restoring UI State and Loaders

🤷🏻‍♂ Can’t we just use AndroidViewModel (AVM)?

AVM is an Android architecture component after all and allows one to pass parameters while providing application context. This seems tempting at first, however, it is problematic for unit tests. Unit tests should not deal with any of the Android lifecycle, such as context.

☝🏻 Data not to pass to the ViewModel

• Context, views, activities, fragments, adapters, Lifecycle, observe lifecycle-aware observables or hold resources, drawables etc. This information should be handled by the view and tethered to the view lifecycle.
• Don’t load resources, instead pass resource ids, and load in view. See: Locale changes and the AndroidViewModel antipattern

Enabling SavedState with Arguments/Parameters

The saved state module is a lifecycle component enabling saving data in the VM that will persist when the VM is stopped by the Android system. This may replace the functionality of saving data inside onSaveInstanceState (OSIS) using the activity/fragment bundle. Lyla also highlights the differences between onSaveInstanceState and SavedState (SS) in detail. The main difference with SS is that the data is stored within the VM instead of in the activity/fragment with OSIS.

OSIS and SS are meant to serve the same use case, saving small amounts of information required to restore the view state of the screen. The majority of data in the VM is meant for saving larger amounts of data that make up the view state. Therefore, SS may replace OSIS in order to organize both the smaller and larger view state data in one place, the VM.

See: How do I use ViewModels to save and restore UI state efficiently?

With the Lifecycle 2.2.0 release, the saved state module comes standard with by viewModels or by activityViewModels syntax, without needing to create a ViewModelProvider.NewInstanceFactory. However, if setting default values for the saved state module or passing arguments/parameters to a VM, an AbstractSavedStateViewModelFactory factory is required, as the documentation notes. The factory class must handle the saved state owner, default values, and custom parameters.

🚦DefaultArgs

The Bundle defaultArgs is recommended to pass into the ViewModelFactory, as the values will be used as defaults in the SavedStateHandle if there is not a value for the given key being requested by the saved state.

See: Public constructors of the AbstractSavedStateViewModelFactory

💾 Saved State

An Int is saved with the method saveSomeInt, in the SavedStateHandle to represent important information that needs to survive the VM being cleared. Then, someInt may be retrieved when needed. Because a default argument is defined for the key SOME_INT_KEY, the saved state will always have a value to work with for that key.

Resources

• 🏞 Check out the Coinverse app in the wild!

Coinverse - cryptocurrency news, bitcoin, ethereum - Apps on Google Play

• 📝 ViewModel notes

I’m Adam Hurwitz, writer of code and more. Follow me on Medium and Twitter.

Optimizing ViewModel with Lifecycle 2.2.0 was originally published in ProAndroidDev on Medium, where people are continuing the conversation by highlighting and responding to this story.

MockK, JUnit 5, and AssertJ

When I started building the Unidirectional Data Flow (UDF) with LiveData pattern, I did not have testing experience. Working on a small/fast moving startup team, Close5, owned by eBay, and building Coinverse from scratch, I had not been required, nor did I allocate the time to develop tests. One of the touted advantages of UDF is optimizing the architecture for testing. This made for a great opportunity to develop testing fundamentals explored in the Coinverse code below.

Previous:

Android Unidirectional Data Flow with LiveData - 2.0

Sample code:

AdamSHurwitz/Coinverse

Strategy — UDF + JUnit 5

Local unit tests are a great beach head to start with if you’re new to writing tests. With the UDF flow the test cares are already organized. Local unit tests provide a good base to build from, as you can then expand to integration and instrumented tests.

• Unit — Test independent code modules containing business logic, also used for integration and instrumented tests. Mocking components the module is dependent on is required.
• Integration — Test components app is dependent upon, i.e. Repository.
• Instrumented — Test end-to-end behavior of a real device or emulator, including UI (Espresso) tests.

To create local unit tests the UI (view), business logic(ViewModel), and data requests (Repository) will be modularized, so that they are independent of each other. Then, the ViewModel's business logic can be tested using JUnit 5.

Tools 🧰

JUnit 5

• ♻️ Reusable tests with dependency injection and extensions (rules in JUnit 4)
• 🏷️ Updated lifecycle naming
• 🏎️ Faster core library updates

MockK

• 🥇 Kotlin first
• 🌄 Native coroutines support
• 🛰 ️Great for mocking Repository object, top-level functions/values, and static Java methods

AssertJ

There are many great assertion libraries so there is more flexibility of options here. Because UDF organizes the final persisted data (view) into a state object and one time navigation events into an effects objects, AssertJ tests the view state/effect values.

Now that the tools are laid out we’ll use them by creating view events with JUnit 5, mocking the data request responses from the Repository with MockK, and testing the correct data is returned with AssertJ.

Modularize Components

We’ll create components independent of each other so that the code not being tested is able to be mocked. For example, we want to avoid situations within the ViewModel where a Repository instance is created, or inside of a Repository where a database instance is created. If these dependancies exist it complicates running the code in the local unit test environment because the environment does not have the same level of access to the Android system.

Dependency Injection

To keep things simple I implemented Singletons to initiate commonly used components on the application level. As Coinverse scales a dependency injection/service locator library may be implemented.

Modularization has been a hotly contested topic in the Twitter + ReddIt(verses). At the 2019 Android Developer Summit Google announced increased focus on Dagger2 dependency injection, including better Kotlin support. There are debates regarding dependency injection vs. service locators.

See Gdoc notes — Dependency Injection / Service Locators.

Jake Wharton on Twitter

@HariOfSpades @lime_cl @KaenDagger I think I need to prequel that with a "The Android documentation is teaching you terrible architecture practices" which is the underlying cause for most of the pain around testing, DI, and a bunch of other fundamental things.

Singletons

To create Singleton module instances on the application level we can override the Application class and create an instance of the component(s) to be used throughout the lifecycle of the app.

The Repository is created as a Singleton object instance. We can use the global database instance created in the Application class to access the database independently inside of the Repository.

Because the Repository is also a Singleton we can cleanly call it from within the ViewModel. This allows us to create the ViewModel moving forward in tests without requiring on dependencies from other components like the Repository.

Test Implementation Steps

Now that the ViewModel does not have dependent components created inside of it, we can setup the test configuration.

1a. Configuration — Extensions, JUnit 5

• Coroutines + LiveData
• Component injection

1b. Configuration — Parameterized tests, JUnit 5

2. Mock components, MockK

3. Create view events, JUnit 5

4. Make assertions, AssertJ

5. Verify tests, MockK

Creating the configuration and mock components, steps 1–2, is 80% of the work. Initiating the view events, testing the view state/effects, and verifying the methods is easier, steps 3–5.

1a. Configuration — Extensions

Extensions are a new feature of JUnit 5 allowing for modularization and re-using components across tests to improve speed and efficiency. In JUnit 4 rules allowed similar functionality. The JUnit team indicates extensions improve upon rules by creating the ability to provide more frequent improvements because extensions can be updated easier.

I took advantage of extensions to re-use the logic for the following.

• Test lifecycle methods
• Injecting common components withParameterReslolver

The test class implements an extension with the ExtendWith annotation, and injects the components of type CoroutineDispatcher and ViewModel.

The extension can access lifecycle methods and ParameterResolver for injecting components.

Coroutines + LiveData

In order for Coroutines and LiveData to work outside of the Android framework in the JUnit 5 local unit tests, we need to set a test CoroutineDispatcher and LiveData executor.

1. In thebeforeEach test lifecycle method the CoroutineDispatcher and LiveData executor are created before each test.
2. In afterEach the CoroutineDispatcher and LiveData are reset and cleared after each test.
3. We’ll look at the usage of getStore in the next Component Injection section to reuse components.

CoroutineDispatcher — Handles launching new Coroutines within tests

• Replaces main dispatcher with test dispatcher
• Creates mock thread pool for testing
• See Providing an explicit TestCoroutineDispatcher (Kotlin documentation)

ArchTaskExecutor — Update live data immediately (don’t post value)

• Don’t update live data on the main thread
• See JVM unit tests don’t know anything about the Android main thread. (Jeroen Mols)

Component Injection

Reusing components in JUnit 5 cleans up code and improves efficiency. ParameterResolver is implemented in ContentTestExtension.kt (Step 1a), then supportsParameter and resolveParameter are implemented to check for the type of component being requested for injection in FeedLoadTests.kt. Lastly, appropriate component is returned to the test.

1. FeedLoadTests.kt requests a CoroutineDispatcher and ViewModel object in the class constructor.
2. supportsParameter checks for the type of object being requested for injection.
3. resolveParameter returns the corresponding object based on the requested object type.

See Inject Parameters into JUnit Jupiter Unit Tests (Baeldung)

Store Objects

To reuse components for injection that have already been created JUnit 5’s getStore is used to save and retrieve components.

4. getTestCoroutineDispatcher and getViewModel retrieve the object based on the key/value stored using get. If the value is null in resolveParameter a new instance is created, otherwise the existing instance is returned from storage.

5. saveAndReturnTestCoroutineDispatcher saves the object based on a key/value using put.

See 5.8.1. Before and After Test Execution Callbacks (JUnit 5 documentation)

1b. Configuration — Parameterized Tests

Parameterized tests in JUnit 5 make testing error responses, empty/null data, and other edge cases easier by creating a stream of test objects modeling different scenarios that are run with the same test logic. This is important to avoid unintended consequences in production.

2. Mock Components

As the tests are focused on the ViewModel's view events, state, and effects, the components and data responses from the network and local database need to be mocked, as they will not be tested directly.

Objects

ContentRepository.kt is a Singleton object, responsible for returning data responses from the network and database requests to the ViewModel business logic, that updates the view state/effects.

1. Mock object creation.

Since the Repository is used for every test it will be created once in the ContentTestExtension.kt with MockK’s mockkObject method, before all of the tests run. Then, the Repository will be returned to its’ original state after all of the tests have completed with unmockkAll.

2. Define mock return values.

Within the test, the mock components used are initiated before the view events are fired or assertions made.

mockComponents will return the mocked Repository data in the same format it is returned in production in order to test the ViewModel's business logic (view/effects).

1. The exact method in the Repository, getMainFeedListis defined inside coEvery so that MockK can listen for this method to be called, and return the corresponding test data instead of using the production Repository.
2. coEvery is used for Coroutines here, otherwise use every

See Convert List Into PagedList With Mock DataSource.Factory (StackOverflow)

Static Methods

Coinverse’s written code is 100% in Kotlin, however libraries included contain Java static methods that are called within libraries implemented in the Repository and require mocking.

Production

Test

To mock FirebaseRemoteConfig’s static method, mockkStatic is used. Because we’re not testing FirebaseRemoteConfig.class, the class is returned empty using relaxed = true.

Constant Values

Production

To mock static values mockStatic is also used, but the package name that Java converts the Kotlin code into is required for Mockk to properly read the value called in the test and return a test value.

Test

3. Create View Events

We begin testing the ViewModel by calling the view event FeedLoad, a Kotlin Sealed class of type ContentViewEventType.

Test

Production

Within the ViewModel this will populate related view state and effects.

4. Make Assertions

After the FeedLoad event is called in the ViewModel we test the view’s persisted data (view state) containing the main feed content, and the corresponding view effects initiated.

In AssertJ the actual value resulting from the test is passed into assertThat, and the expected value is passed into isEqualTo.

1. To run Coroutines synchronously testDispatcher.runBlockingTest is used.

See kotlinx.coroutinesrunBlockingTest (Documentation)

2. Both the view state value pagedList and view effect UpdateAds are being observed and tested with the utility function getOrAwaitValue.

See Unit-testing LiveData and other common observability problems (Jose Alcérreca)

3. I’ve also created utility extension functions for observing LiveData from the view state and effects with feedViewState, viewEffects, and observe.

Error

When a JUnit 5 parameterized tests fails with AssertJ, Android Studio produces the test conditions for the failure and the expected/actual result in order to debug the test.

5. Verify Tests

The last step in testing is to use Mockk to verify that all of the expected methods are called and also that all of the methods called during the tests are expected.

1. coVerify is used for code containing Coroutines, otherwise verify would be used.
2. The verification confirms that the method getMainFeedList is called within the tests.
3. confirmVerified checks if all method calls fired in the tests are verified/expected to be made.

Errors

Two common errors with verification are methods called in the tests that aren’t verified, and methods that are expected to be verified, but never called in the tests.

Method called in test, but not verified

This could either occur when you forget to include a method in the verification, or if an unexpected method is being called in the test that should not be.

Method not called in test, but should be verified.

This indicates the test code is likely not running as expected as the method should be accessed, but is not.

Recap

Using the modular approach with local unit tests, 96% of the lines of code for the ContentViewModel are covered.

Takeaways

1. Modularity improves testability.
2. 80% of work consists of configuration (Coroutines, LiveData, component injection, test cases) and mocking.
3. Ensure view state/effects are tested in the correct order they occur in production.
4. Ensure emission of all of the view states/effects scenarios are tested.
5. Be careful one test does not break the following parameterized tests.

Next Steps

1. 🧪 Expand local unit tests to the entire app.
2. 🏗️ Integrated (dependent components) tests, i.e. Repository.
3. ⚙️Instrumented (e2e) tests, i.e. View, ViewModel, Repository.
4. 📱Espresso UI tests, i.e. View.

Resources

• Check out Coinverse on the Play Store:

Coinverse - cryptocurrency news, bitcoin, ethereum - Apps on Google Play

• Explore and run the Coinverse code:

Sample App — Android Unidirectional Data Flow

• Slides:

• Notes: MockK, JUnit 5

A big thanks to DroidCon for providing the opportunity to share the above at the 2019 San Francisco conference! 🙏

I’m Adam Hurwitz, an Android consultant + developer. Follow me on Medium for more on Android and connect with me on LinkedIn.

Android Unidirectional Data Flow — Local Unit Testing was originally published in ProAndroidDev on Medium, where people are continuing the conversation by highlighting and responding to this story.