https://github.com/MrHadiSatrio/Journal3/blob/30ff779807a5e171d9b86fb0d8e463836fa27039/app-android-journal3/src/main/kotlin/com/hadisatrio/apps/android/journal3/story/ViewStoriesActivity.kt#L52

Could we do the same as BackgroundExecutingUseCase for the Presenter?

https://github.com/MrHadiSatrio/Journal3/blob/30ff779807a5e171d9b86fb0d8e463836fa27039/app-android-journal3/src/main/kotlin/com/hadisatrio/apps/android/journal3/story/ViewStoriesActivity.kt#L48

This decorator's name suggests something like this:

class BackgroundExecutingUseCase(
    private val coroutineScope: CoroutineScope,
    private val origin: UseCase
) : UseCase {

    override fun invoke() {
        coroutineScope.launch(Dispatchers.Default) { origin() }
    }
}

So far we've only been handling user-sourced cancellation events (through BackButtonCancellationEventSource). We should also channel such events on appropriate lifecycle state change (e.g., Activity#onDestroy()) lest we'd end up with leaks.

An implementation of it could look like so:

class LifecycleCancellationEventSource(
    private val lifecycle: Lifecycle
): EventSource {

    private val events: Flow<CancellationEvent> by lazy {
        callbackFlow {
            val observer = LifecycleEventObserver { source, event ->
                if (event != Lifecycle.Event.ON_DESTROY) return@LifecycleEventObserver
                trySend(CancellationEvent("system"))
            }
            lifecycle.addObserver(observer)
            awaitClose { lifecycle.removeObserver(observer) }
        }
    }

    constructor(activity: ComponentActivity) : this(activity.lifecycle)

    override fun events(): Flow<Event> {
        return events
    }
}

Post that, it's only a matter of ensuring all use-case declaration would have that as one of their event sources.

What has changed

Router has been deprecated since #14. This PR will completely remove it from the codebase as well as README. Its replacement comes in two forms:

1. ActivityRoutingEventSink (which has been expanded to cover more Event types) for forward navigations, and
2. ActivityCompletionEventSink for backward navigations

Why was it changed

I believe ActivityRoutingEventSink plus ActivityCompletionEventSink provides a more idiomatic way to trigger navigation. It can be supplied as part of the global sinks which alleviate UseCases from having to explicitly depend on a dedicated routing object.

What has changed

It is now possible to tag geographical data (places) onto moments. In order to facilitate this feature, a number of things has to be added/changed.

Deprecation of Router

This is the first time we ever had to model cross-Activity interaction (see SelectAPlaceActivity) and it made me realize the flaw in Router-based navigation. While it's true that it allows use-cases to direct the flow of screens, at the same time it also invite the assumption of a structure; of a multi-screen application in this case.

Another problem comes from the fact that with Router modeling activity "callbacks" felt clunky because of its fire-and-forget nature.

The current approach I'm taking now is to deprecate Router in favor of event-driven navigation. Use-cases should simply sink events that are outside of their scope. At the same time, a global EventSink would react to such events and navigate to a proper component (i.e., activity). Meanwhile, the "callback" aspect of it relies on the fact that all use-cases would have the global EventHub as one of their EventSources. Meaning they can "resume" their work basing on the same event.

This approach alleviates the need of coupling the event stream from the inherently Android-specific concepts of activity navigation.

Deprecation of Coroutines

I've been met with a lot of inconsistencies that seemed to come from our Coroutines-backed decorators. I didn't really spend time to dig in deep, rather tried to implement alternative decorators backed by Executors instead. And the problem disappeared. (Maybe #5 has something to do with it.)

Probably will revisit the "why" later on. But for now, it works. And because we don't actually need a lot of features Coroutines offer, I don't see any harm of going ahead with Executors for now.

Handling of CancellationEvent within use-cases

This is a bug that have been there for a while (as raised in #13) but the introduction of Executors made it more apparent. As we're setting a conservative limit on the number of threads (via Runtime.getRuntime().availableProcessors()) these zombie use-case instances literally blocked the app from functioning after a short period of usage.

The solution for now comes in the form of LifecycleTriggeredEventSource, set to emit CancellationEvent upon Lifecycle.Event.ON_DESTROY. Plus change in use-case classes to ensure the event is handled properly.

CurrentActivity behavior

In its original form CurrentActivity would throw an exception when there are no "current" activities. However, I don't feel like it paints the correct picture. When you're interested in knowing something that is "current", would you stop looking when it's not there yet?

The behavior now is changed to simply block the calling thread when no such activities are there. I believe this is fine as we're running close to everything on background threads. Another plus side is that this would allow downstream requirements (e.g., like the one added within PermissionAwareCoordinates) to behave correctly even in edge scenarios.

Adoption of Ktor

Nothing to elaborate on this, really. This project is inherently a KMM one, so Ktor is our best bet for facilitating network I/O.

Why was it changed

To see how this project structure would fare when pitted against network I/O (HERE API), sensor-reading (GPS, on Android through LocationManager), and Runtime Permission requirements.

What has changed

This project is now configured to be analyzed by SonarCloud.

Why was it changed

To ensure that the quality of this project won't degrade overtime.

What has changed

Moments shown in the story detail screen are now sorted, in descending order, according to their timestamp.

Why was it changed

To make it easier to read back written moments from the past. Unless they are sorted in some way, the user won't be able to make sense of the timeline in which their moments took place.

What has changed

In RecyclerViewItemSelectionEventSource, ACTION_MOVE in between ACTION_DOWN and ACTION_UP would no longer prevent a click event from being emitted.

Why was it changed

On a real device, it's unlikely that ACTION_DOWN would be immediately followed by ACTION_UP; there's almost always a small ACTION_MOVE in between. This behavior is reproducible almost every time on a Google Pixel 5 running Android 13.

What has changed

Added a new use-case to alert users if they haven't recorded any moments after a certain duration had passed (currently set to 3 hours). On the Android app, this use-case would be run on top of the WorkManager API and would talk to a notification-backed presenter; resulting in a periodical notification setup.

Why was it changed

Because I need this feature to help keep my journaling habit in check.

Related issues

• N/A

What has changed

Added two new domains: One to show individual stories (including their moments) and another one to edit moments.

Why was it changed

Because otherwise users won't be able to write down their thoughts and use the app as intended.

Related issues

• N/A

What has changed

We're now depending on JsonPrimitive#content to obtain raw string values within JsonFile.

Why was it changed

JsonElement#toString() will attempt to surround content with ", which we don't want. Simply removing those surrounding quotes manually is error-prone.

In https://github.com/MrHadiSatrio/Journal3/issues/14#issuecomment-1345552827, Sonar reported 0% coverage for all the newly-added code, which is not true (see https://github.com/MrHadiSatrio/Journal3/pull/14/commits/da2090b499b9ef6f472154e4aa3813e8908f2dc8).

Most probably this is a configuration error. We need to take a second look at the setup and get this fixed.

https://github.com/MrHadiSatrio/Journal3/blob/30ff779807a5e171d9b86fb0d8e463836fa27039/app-kmm-journal3/src/commonMain/kotlin/com/hadisatrio/apps/kotlin/journal3/story/ShowStoriesUseCase.kt#L50

Allow me to query more detail about the usage reason of runBlocking here. AFAIK, the official documentation only encourages runBlocking in main functions and tests. It could be dangerous if we run this usecase on a single thread dispatcher like Dispatchers.Main.

The same document also mentions "should not be used from a coroutine", meanwhile we decorate ShowStoriesUseCase using BackgroundExecutingUsecase that internally launches a coroutine.

As you have stated that UseCase is a representation of business requirements/features, is it necessary that we should only have 1-to-1 mapping between Activity/Screen/Feature and UseCase?

I know you've clearly stated that you don't intend to apply any kind of architecture to Journal3, but if you do "PURE" would be a great name for this 😄 Presenter-UseCase-Router-Event.