Hey there! First of all, congrats on the job!

A have a little question about architecture stuff.
How would you handle with some observable use case (RxJava or LiveData) on the domain layer?

For example, there is some service updating the data on Room Database, those updates must be sent to the UI.

So basically we have ViewModel connected on some UseCase that is observing the Repository that is observing a Room query.

How would you do these kinds of connection between the layers once the Domain layer is an only Kotlin module, without android dependencies?

Thanks!!

We should evaluate age as an alternative to GPG to drive locally encrypted files. This for sure has impact in both local/CI environments, but eventually drives also a simpler setup for dealing with such files

Before you open an issue:

Related to #79

Figure out why Turbine is not compiling even with the latest Kotlin set

hi I know you've moved to processor recently

 when (interaction) {
            is QueryDefined -> {
                processor.process(
                    CommandTrigger(::save, interaction)
                )
            }
            else -> {
                interpret(interaction)
                    .let { transition ->
                        machine.consume(transition)
                    }
            }
        }

your impl is quite hard to understand. with QueryDefined you use processor, else you use machine.consume(transition). what are the reasons behind?

This issue lists Renovate updates and detected dependencies. Read the Dependency Dashboard docs to learn more.

Repository problems

These problems occurred while renovating this repository. View logs.

• WARN: File contents are invalid JSON but parse using JSON5. Support for this will be removed in a future release so please change to a support .json5 file name or ensure correct JSON syntax.

This repository currently has no open or pending branches.

Detected dependencies

• Check this box to trigger a request for Renovate to run again on this repository

Steps to reproduce:

1. Emulator API 30
2. Open and run project build
3. Click "search" icon when app is ready

2021-01-24 20:07:22.019 6280-6280/? E/AndroidRuntime: FATAL EXCEPTION: main Process: io.dotanuki.demos.norris.debug, PID: 6280 java.lang.IllegalStateException: LifecycleOwner io.dotanuki.norris.facts.FactsActivity@807bd3e is attempting to register while current state is RESUMED. LifecycleOwners must call register before they are STARTED. at androidx.activity.result.ActivityResultRegistry.register(ActivityResultRegistry.java:120) at androidx.activity.ComponentActivity.registerForActivityResult(ComponentActivity.java:666) at androidx.activity.ComponentActivity.registerForActivityResult(ComponentActivity.java:675) at io.dotanuki.norris.navigator.Navigator.navigateForResult(Navigator.kt:21) at io.dotanuki.norris.facts.FactsActivity.goToSearch(FactsActivity.kt:70) at io.dotanuki.norris.facts.FactsActivity.onOptionsItemSelected(FactsActivity.kt:62)

Context

Seems that AGP 4.1.x introduces some breaking changes this project should catch

• #74 (by Dependabot)
• #69 (by Dependabot)
• #71 (by Dependabot)

Goal

• Investigate why this happens and make this project compatible with the latest stable AGP
• Make sure that Detekt and Ktlint are also working with the latest stables

Context

Investigate the options to avoid things like

• #67
• #73

References

• https://dependabot.com/docs/config-file/
• https://docs.github.com/en/github/administering-a-repository/configuration-options-for-dependency-updates

Acceptance Criteria

Dependabot follows strictly major.minor.patch for updates on Dependencies

After Github introduced better visibility / management to storage used by CI caching, constantly we have to handle messages like this one

In addition to that, frequently we blow the 10GB budget, which is a source of cache misses. This is happening due 2 main reasons

• #651, which doubled the consumption of cache storage based on JDK versions
• poor cache management, although we are making the most we can of actions/cache

Two solution can contribute to improve the situation

• stick only to jdk17 when driving CI build
• replace action/cache with gradle/gradle-build-action, which delivers an implementation that avoids caching by branching and sticks with cache updates / invalidation at default branch level

Right now we use a couple of CLI tools and have their version hardcoded in a couple of scripts.

We'd like to extract such hardcoded versions and manage them via a proper .tool-versions file, as per defined by asdf. We could manage with adsf itself or with a compatible tool like rtx

Note that we'd need to implement the support of emulator.wtf-cli and maestro-cli for such versions managers, eventually as new plugins.

My understanding is ComposeSearchOptions, FetchCategories, FetchFacts and ManageSearchQuery are UseCases. Can you add the postfix UseCase to make its name more meaningful?

We could leverage Gradle java toolchains to automatically drive JDK the setup both at CI and local machine, standardizing both the JDK used for builds and the vendor that supplies the OpenJDK distribution.

As an additional benefit, that would allow us to get rid of jenv

References

• Gradle Java toolchains reference
• Java toolchain support for Kotlin Gradle Plugin

private fun interpret(interaction: UserInteraction) =
        when (interaction) {
            OpenedScreen, RequestedFreshContent -> ::showFacts
            is NewSearch -> {
                currentQuery = (interaction as NewSearch).query
                ::showFacts
            }
            else -> throw UnsupportedUserInteraction
        }

    private suspend fun showFacts() =
        usecase.search(currentQuery)
            .map { FactDisplayRow(it) }
            .let { rows ->
                FactsPresentation(currentQuery, rows)
            }

with the current arch the app is using. Is there anyway to pass parameter to showFacts like
showFacts(query: String). Look at the code, you have to keep currentQuery as a global field. I don't think that looks good

After some recent changes, we removed Leak Canary from release builds.

We should figure the proper way to drive memory leak detection on CI. The approach should just work for tests driven either locally or via a device farm.