is there a channel to talk about hexagonal arch de...

# android-architecture

[juliocbcotta]

is there a channel to talk about hexagonal arch details ? Not necessarily in the android context?

[Esat Hamzaj]

How would that work in Android?

[juliocbcotta]

As it work in any other place? You define ports and adapters... which would mean... ports usually are interfaces and adapters implementations of those interfaces... so you can plugin different adatpers in the same port... you can thing of it, for instance... your project uses Gson, but you want to migrate to Kotlin serialization, if you have an interface to your remote data source... you can keep both implementations on your code with a feature flag... but you see... you need two retrofit instances, and different model classes for your request/responses to keep things isolated... this is easy to see right ? You avoid possible regressions and can turn of the new code if crashes happen...

[juliocbcotta]

but to follow hexagonal arch... your UI should also behave like that... you should be able to change your UI implementation (activity, fragment, compose) without having to change your port ( conrtroler, presenter, viewmodel)... does it make sense to you? Well, what I want to know is... shouldn't I be able to change my port( controller, presenter, viewmodel) without the need to change my UI ? To be able to do that... I think we would need to define an interface for that too... so you would make your VM implement a port interface to communicate with the UI...

[juliocbcotta]

well, this is not kotlin but kotlin colored

[Joel Denke]

I can just say it is possible with well defined or maybe custom Kotlin DI framework, combined with decoupled SDK specific things. As of example would need to get rid of all lifecycle things in Compose code if using that, that including libraries doing it.
If you have a single activity structure and never using Fragments and such, its much easier to achieve this.
Example framework kind a doing this the right way imo is Circuit from Slack company.

Everything has to be well defined interfaces and enforced small modules everywhere 🙂 In the end in an app not sure if it works 100%, as also causing a lot of overhead and complexity doing this if doing it to much kind a 😛

Importance here if using Gradle, use a lot of small modules and convention plugins 🙂 Then stuff like inject feature modules in runtime with Androids feature plugin tool, will make the app less large as well. In reality very hard doing this imo.

[juliocbcotta]

nothing of what I said is particular to any kotlin DI framework or Compose... Yes, modularisation/plugins would be important though...

[Joel Denke]

UI layer vs DI framework impacts the way you need to declare everything, compared different solutions. Cant decouple them in same way 🙂

[juliocbcotta]

You could use the same VM with Compose or with Views... It may be harder to integrate, but the contract of your VM should not change... you could even say that you are going to use a Presenter without config changes support and it should still work...

[Joel Denke]

Depending which VM variant using, maybe not supporting all state changes, retain config states and such and differs in Compose vs Views as of example.
Depending how implemeting UI layer for that kind of things, its could be tricky to do the "still work" part. Especially when doing cross platform for example, when this hexagonal thinking becomes extra important 🙂 Then cant deal with SDK specifics really, it need to be decoupled outside both UI and DI layers in many cases.

[Joel Denke]

Imagine having Context usage in VM level, it will not work 😄

[juliocbcotta]

well, sure, but if your VM ui state is not in sync with your UI.. it is a bigger problem... From the VM there is no difference in retaining the state... You use SavedHandle...

[Joel Denke]

I mean the concept of SavedHandle, Context, serialized state in Android doesnt even exist in iOS or any other platform, need to move all that away.
What I mean it impacts the entire infrastructure how to decouple all SDK platform specifics being modular.
Given what Google did in many androidx libs its not always possible 😄

[Joel Denke]

In many cases cannot move that into isolated modules.

[juliocbcotta]

So you should abstract that

[Joel Denke]

Google not allowing that in all scenarios 🙂 Like in some cases the solution is to NOT using MVVM at all 😛

[Joel Denke]

Like avoid some androidx libs.

[Joel Denke]

Cant abstract the lifecycle as of example, or well partly.

[Joel Denke]

Lifecycle of Fragment, Activity, ViewModel etc I mean.

[Joel Denke]

The solution imo is to go away from MVVM in hexagonal arch, as not compliant kind a from my point of view. Decouple the ui states, navigation, lifecycles, presenters etc, so everything is composition patterns and injectable through interfaces in all scenarios.
Like inject the entire Application or Activity lifecycle processes is not really supported fully yet from what I know of.

[juliocbcotta]

you can use collectWithLifecycle() and collectAsState() in compose, right ? So you can abstract it for multiplaform for instance with collectWhileAlive() with each platform delegating it to a different function

[juliocbcotta]

anyway, the topic here was not to talk about KMP, it was supposed to be about a pluggable arch... there are many other problems that are not multiplatform UI/navigation

[juliocbcotta]

of course, a good arch would allow you to use the same Presenter on Compose and in SwiftUI

[Joel Denke]

Yeah sorry, any examples of the pluggable arch refer to? 🙂

[juliocbcotta]

well, many archs are pluggable, I think what you want is a sample project that implements something plugable, no ?

[Joel Denke]

No, was more curious about the topic and any particular arch variants how to plug everything.