Re-architecturing library

[hadiyarajesh]

I've been thinking to re-architecture flower library to prepare it for modern requirements and better code quality and maintainability.

I'm planning to work on following features.

• Use data class for Success and Error instead of enum class as a Status of Resource class to provide correct information in resource status
• Change networkBoundResource function to dbBoundResource as we have a separate function called networkResource specifically for network requests.
• Change fetchFromRemote function to makeNetworkRequest as fetchFromRemote is not ideal name when we're making network request to upload data, or calling POST/PATCH API.
• Change shouldFetchFromRemote function to shouldMakeNetworkRequest for similar reason.
• Use ApiResponse<REMOTE> return type instead of Flow<ApiResponse<REMOTE>> in fetchFromRemote function as I'm not seeing much benefit of using Flow for network request (Not sure if this would be possible).
• Rework the sample app to use modern architecture and remove un-necessary code

These are few things I've in my minds. Of course, it's not final and i welcome all the suggestions and contributions. You can also provide more features/changes if you've them.

[DatL4g]

Sounds good to me, first of all. Additionally I have over plans.

I'm trying more and more to shift from pure Android to as much Kotlin Multiplatform as possible.
The current solution for network requests is Kotlins KTor Client, however I like the approach of Retrofit more by a lot.
There is a library that aims exactly that purpose of having the same on Kotlin Multiplatform, called Ktorfit.

My (thought of) goal of this re-architecture is NOT to completly shift it over to Kotlin Multiplatform with this library, instead more like make it compatible with it.
This will require the following changes:

• make the Project and the base module ("Flower") to Kotlin Multiplatform
• (I would rename the base module "Flower" to "flower-core")
• create another module ("flower-retrofit") which is fully compatible with Retrofit (this will be an Android module as Retrofit is Android only)
• create another module ("flower-ktorfit") which is fully compatible with Ktorfit
• shift the gradle-nexus-plugin to vanniktech:gradle-maven-publish-plugin (as the gradle nexus plugin is not Kotlin Multiplatform compatible (yet))

I have experience with Kotlin Multiplatform projects, so I'm available to help and do this migration.
(An easy example for learning purposes can be viewed here: JsUnpacker)

My plan would be as follows:

1. Migrate to Kotlin Multiplatform
2. Shift to a core module
3. Apply your suggested changes
4. Create a Retrofit module (as we have the code already)
5. Create a Ktorfit module

[hadiyarajesh]

Sounds good.
I like idea of flower-core and other modules and new gradle plugin (used it for another project, and yeah, it's better than gradle-nexus plugin)
But we also have a Room DAO requirement on Android. Did you expected multi-platform support for it? Additionally, I've no experience on multi platform projects, but curios to learn it. I can make changes on Android side when time permits and then we can move for multi-platform support.

[DatL4g]

There is no Room requirement right now.
The only android specific requirement in the current "core" module is Retrofit.
The android example is completly encapsulated in it's own module.

That means we will migrate the current Flower library to multiplatform, remove the Retrofit dependency and replace them with a generic implementation which we do in the separate implementation modules.
The android example can stay the way it is right now.

[DatL4g]

I started the migration https://github.com/DATL4G/flower
It's currently in an early WIP state

[DatL4g]

First steps done #15

[DatL4g]

I think I did everything necessary, the modules are working and are ready to be published.
The compose-app should be removed I think as it works "around" the library, it has nothing to do with this library, as it not even uses the functions.
As mentioned in the PR, the publication needs to be tested, I think I configured it correctly, the POM description could be changed.

[DatL4g]

@hadiyarajesh

As we change the networkRequest type from Flow<ApiResponse<*>> to ApiResponse<*>, I would like to re-add Flow support as soon as https://youtrack.jetbrains.com/issue/KT-51107/Stabilize-overload-resolution-by-lambda-return-type is done.

There might be use cases (e.g. doing and handling requests yourself) the Flow<ApiResponse<*>> in networkRequest is useful.

For the meantime I would like to introduce another function, so well call the "main" one (ApiResponse<*>) dbBoundResource and the "old" one (Flow<ApiResponse<*>>) dbBoundResourceFlow

[hadiyarajesh]

@DatL4g I would like to understand more about "doing and handling requests yourself" and how "Stabilize overload resolution by lambda return type" can help in this situation.

[DatL4g]

Easy, let's say someone wants to do an API call but relays on active polling (this is quite common)

So he makes a network request and 10sec later again and again, etc.
The easiest thing for him to use Flows to keep track of new data.

Another use case would be if he doesn't use Retrofit or Ktorfit, so he uses the core library and his data fetching method relays on Flow again.

[hadiyarajesh]

Got it. When I started developing library, I thought the same (inspired by twitter, fetching likes in real time). But then I thought most people aren't using it. So, I proposed api without Flow. Anyway, we can have two functions, one with ApiResponse<*> and another with Flow<ApiResponse<*>>