presenter fun just takes some number of channels f...

# android

[withoutclass]

presenter fun just takes some number of channels from the view and returns a view model that holds some number of channels the view needs to listen on

[dave08]

You use android architectural components, or just a simple presenter? How do you manage lifecycle?

[withoutclass]

so far not using architecture components. My view is my activity/fragment, it handles itself. When it pauses, I null out my channel references. When it resumes, it get’s a new set of channel(s) from the presenter fun

[dave08]

Do you have a sample out, or maybe a gist? I was also thinking along those lines, and would be interested in getting more details about your setup...

[withoutclass]

Sadly no, all my code I’ve written for it so far has been client code.

[withoutclass]

https://rongi.github.io/kotlin-blog/rx-presenter.html

[withoutclass]

This is the blog that inspired me to give it a go with channels

[withoutclass]

I pretty much follow that blog, just instead of using RX, I use channels

[withoutclass]

I am pretty excited about it. No dealing with view interfaces, no dealing with presenter interfaces. Testing the presenters is brain dead easy because the presenter fun takes some number of channels and returns others, so you can test fire events down your input channel and verify you get the correct event out of your output channel

[withoutclass]

One key difference I did, was to use sealed class for my events

[dave08]

Very interesting... thanks! If you have a chance to post a gist of the differences between rx and channel implementation, just the idea and main pitfalls... it would be great..

[withoutclass]

yea I am sick today I should write something up xD

[dave08]

Why sealed class? A click is simply Unit, etc... like RxBinding lib?

[withoutclass]

What I did was create sealed class like OnClick(). It has sub objects like object PositiveButton: OnClick() etc. So I have a handful of generic events that are easy and readable to pass in a channel, and clearly define what type of action occurred.

[withoutclass]

I think this makes it very clear what’s happening in the UI as well as clear for testing. When presenter fun receives a PositiveButton click event, expect presenter channel to return some expected event

[dave08]

I tend to avoid locking presenter logic w/ platform implementation details.. I'd rather have a val onSubmitRequest: ReceiveChannel<RegistrationRequest>()...

[dave08]

But I know there's more technical problems I didn't yet figure out like handling closed channels and lifecycle...

[withoutclass]

Well that’s why the events into the presenter are generic. Positive button, negative button, DialogPositiveButton, etc. The events out of the presenter are more specific to what actually needs to occur, which I think is fine considering that’s the role of the presenter anyways, at least in my view.

[withoutclass]

One way I could see decoupling more would be to also provide the presenter with an activityReference, then the presenter could actually send down code to be executed in the activity/fragment, or execute it itself. I kind of see that as tying the activity to the presenter fun as well, just in a different way