https://kotlinlang.org logo
#android
Title
# android
w

withoutclass

02/05/2018, 4:21 PM
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
d

dave08

02/07/2018, 9:51 AM
You use android architectural components, or just a simple presenter? How do you manage lifecycle?
w

withoutclass

02/07/2018, 4:16 PM
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
d

dave08

02/07/2018, 4:18 PM
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...
w

withoutclass

02/07/2018, 4:19 PM
Sadly no, all my code I’ve written for it so far has been client code.
This is the blog that inspired me to give it a go with channels
I pretty much follow that blog, just instead of using RX, I use channels
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
One key difference I did, was to use
sealed class
for my events
d

dave08

02/07/2018, 4:25 PM
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..
w

withoutclass

02/07/2018, 4:26 PM
yea I am sick today I should write something up xD
d

dave08

02/07/2018, 4:27 PM
Why
sealed class
? A click is simply
Unit
, etc... like RxBinding lib?
w

withoutclass

02/07/2018, 4:29 PM
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.
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
d

dave08

02/07/2018, 4:36 PM
I tend to avoid locking presenter logic w/ platform implementation details.. I'd rather have a
val onSubmitRequest: ReceiveChannel<RegistrationRequest>()
...
But I know there's more technical problems I didn't yet figure out like handling closed channels and lifecycle...
w

withoutclass

02/07/2018, 4:40 PM
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.
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