Arrow: Add Kategory example to googlesamples/android-architecture

[pakoito]

Add an example of how to build an FP architecture in Android to https://github.com/googlesamples/android-architecture

[pakoito]

@JorgeCastilloPrz is this something you'd be excited about? I can also lead to integrations with ArchComp & Room.

[JorgeCastilloPrz]

Definitely. I'll open the first required issue asking for "permission" to build it. 🎉

[JorgeCastilloPrz]

Here it is @pakoito . Please provide any further comments that you find important on the issue, if I forgot to mention anything!

Also, take into account that this would be the "formal approach" to start the development flow over that repo, so we need to wait for them to give permission.

Hooray!

[JorgeCastilloPrz]

Ok. @JoseAlcerreca gave green light to implement it and let them know when it's ready. The idea is to take a look at the resting samples and try to implement something equivalent using Kategory. Architecture samples seem to be quite basic but understandable enough, so the main concern is to make the sample readable and didactic.

I can take care of it.

[pakoito]

Cool, let's have a chat later with @raulraja about which style we'd like to have represented.

[JorgeCastilloPrz]

One question. I guess the most basic and didactic approach could be a stack of transformers? Not sure if going further for tagless final or Free is a good idea for a blueprint. Ideas?

PD: Ok looks like we typed both comments at the same time :)

[JorgeCastilloPrz]

Also, feels like they don't integrate all the PRs but mainly link to them as "external samples". Not sure if then we might want to push it under the kategory org or what. Mostly following this. I asked them about this and waiting for an answer.

[JorgeCastilloPrz]

Ok they clarified now: Separate repo to link it from README.
https://github.com/googlesamples/android-architecture/issues/461#issuecomment-343681827

So it would be time to discuss what the sample should be showcasing, and if we want to write a new one under the kategory org, or we might just use my sample KotlinAndroidFunctional repo to keep the work over it (which already provides different approaches and docs by medium posts) and may be provide an additional branch / gradle module on it with the required sample following their required specs from the already existent samples as they requested.

I am ok with any choice.

[pakoito]

I'd rather it was within the org, so I can work on it too (legal requirements etc)

[JorgeCastilloPrz]

No problem with that. Let's work on it here.

[raulraja]

I think the Monad transformers style with a thin wrapper over the typealias based on extension functions is what it would be easier for users to understand. I'd preffer tagless but given how complex the inline reified biz is at the moment for type classes it's gonna be easier to do a :

typealias Result<A> = Kleisli<EitherTKindPartial<IOHK, CharacterError>, Config, A>

fun Result<A>.raiseError
fun Result<A>.flatMap

where each extension exposes the API the user needs to operate and hides any explicit instances required by Kleisli and friends.

[JorgeCastilloPrz]

Sounds good 👍

[JorgeCastilloPrz]

@kategory/maintainers the repo is ready to start working on top of it.

Some basic but key things to notice (those are already described in the readme, but I'll paste them here):

• We want to cover the same use cases and replicate the same screens from the original repo (already implemented on this one by Google but under a basic Kotlin style). So we basically need to port those to a different architecture using kategory.
• We are completely free to remove/add layers, levels of abstraction or whatever, to compose the architecture the way we want. We just need to keep the user visible features as they are in terms of usage.
• We must think about readability and clarity since the goal is to create a base blueprint for the android community to give them a point to start. We don't want to go for super fancy things or styles to showcase how powerful is kategory, but instead for a "base functional android architecture" for reference. That would be my advice on this, after taking a deep look on what other samples are covering and the scope of the blueprints repo.
• We must cover the same use cases on tests.
• A good way to iterate over is to pick one activity and iterate over it, leaving the resting ones untouched. Once we agree on a given approach, we can move forward and port that to the resting activities. We can easily start by a leaf node on the navigation tree, like the AddEditTaskActivity which is used to add or edit an already existent task on the todo app.

[aballano]

@JorgeCastilloPrz Is this ticket still valid (if so, we might need to update it) or can we close it?

[JorgeCastilloPrz]

This got totally outdated. We never managed to get the blueprint for Android 100% ready (that's how my personal project started) so I'd wait for it then think about this again. We can close the issue for now. I've also removed the sample repo I created in the arrow org that was never iterated. Noticed now it was still there.