Architecture-samples: New Sample: Model View Intent

[kanawish]

New sample proposal

I'd like to create a new sample to illustrate the Model View Intent pattern. Full Android examples for MVI are hard to find. It's a pattern that has seen wide adoption in the Javascript and .NET world. Target audience include, but not limited to:

• Developers making the pivot from an imperative to declarative style of programming.
• Developers looking for best-practices in functional or reactive programming on Android.

Here are some articles/examples explaining the core principles of MVI and unidirectional flow:

• http://hannesdorfmann.com/android/model-view-intent
• https://cycle.js.org/model-view-intent.html
• http://thenewstack.io/developers-need-know-mvi-model-view-intent/

Proposed stack

I'm hoping to use specific libraries to achieve this in the cleanest possible way. A requirement with the android-architecture samples is to use accepted industry standard. A few of these libraries are new as of this year, but I believe they still fulfill that requirement. I've taken the time to establish a small 'pedigree' for each.

The following are battle-tested libraries. Battle tested here means that they have documented use, in production, at major companies with a large user base. Places such as Square, Groupon, Trello, Shopify, etc. One notable exception is RxJava2. RxJava 2 has major community backing, and will see a production release later this month.

Also, the following all have well-know, senior maintainers with established track records. Below a detailed list with rationale/credentials:

• RxJava 2
  
  
  
  • Great talk by Jake Wharton outlining usage & benefits
  
  
  • Observable and Flowable clears up the muddled semantics around Backpressure in RxJava 1.
  
  
  • Better type safety.
  
  
  • Improved Subscriber model.
  
  
  • Currently RC4, General availability planned for 29/10/2016
  
  
  • Contributors include Jake Wharton and David Karnok
  
  
  • IMO deprecates RxJava 1.
  
  
• Retrofit
  
  
  
  • Battle tested, used in other samples.
  
  
  • RxJava 2 adapter currently available, built by JakeWharton.
  
  
• Toothpick
  
  
  
  • Lightweight DI library.
  
  
  • Full-featured, runtime based, but reflection free, implementation of JSR 330.
  
  
  • Performant and much less code overhead / complexity than Dagger 2.
  
  
  • Great presentation outlining usage & benefits.
  
  
  • Audio for the talk
  
  
  • Primary maintainer is Stephane Nicolas, senior engineer at Groupon.
  
  
• Retrolambda
  
  
  
  • Lambdas are necessary for readable functional / reactive code.
  
  
  • Retrolambda routinely used in production for big projects (Square, Trello, etc.)
  
  

[JoseAlcerreca]

How is this coming along?

[kanawish]

To be honest, I've only starting working on this last week. Since I wrote this proposal, I spoke at 3 conferences, and spent a week in Mountain View for the GDE summit + Workshops.

I'm hoping to get an initial PR up sometime next week-end. I might appreciate earlier feedback, I'll reach out on Slack once my base pattern is close to something I feel happy with.

[VisheshVadhera]

@kanawish @JoseAlcerreca Are you guys still working on this one? I would be happy to take this one up.

[kanawish]

It's been slow, but I'm still invested on this one. This January, Hannes Dorfmann updated his blog series on the pattern. That prompted me to drop my original approach.

@VisheshVadhera Would you be open to tag teaming? There's a fair amount of work on this, and it would be nice to have someone to PR along with.

[VisheshVadhera]

@kanawish I would love to! Let me how we can take this forward.

[kanawish]

Please do! I'm busy with Chicago Roboto coming up, and this one is next on
my list. [Re: following comment]

On Fri, Apr 7, 2017 at 9:45 AM Vishesh Vadhera [e-mail]
wrote:

@kanawish https://github.com/kanawish Hey kanawish, I have forked the
repository and am thinking of starting work soon on this one. I'll ping you
on this thread before starting. Cheers

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/googlesamples/android-architecture/issues/215#issuecomment-292540146,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABYeksi66uARnB2Lasx6-82vxaIxmLryks5rtj39gaJpZM4KV-AF
.

[VisheshVadhera]

I think I accidentally deleted my last comment. But never mind I have forked this project and will start the work soon, will ping you before starting.

[kanawish]

@VisheshVadhera I started a fork as well, with the main idea to discuss and document our approach via issues and github Project. I invited you as a collaborator, anyone else interested in pitching in drop me a line I'll add you.

First step I'd like us to do is add some 'meat' on the current issues to come up with an agreed upon approach, then we can assign each other issues in the usual way, to make sure we don't dupe work, etc.

[VisheshVadhera]

Sounds good to me.

On Sat, Apr 8, 2017 at 8:44 PM, Etienne Caron [e-mail]
wrote:

@VisheshVadhera https://github.com/VisheshVadhera I started a fork as
well, with the main idea to discuss and document our approach via issues
and github Project. I invited you as a collaborator, anyone else interested
in pitching in drop me a line I'll add you.

First step I'd like us to do is add some 'meat' on the current issues to
come up with an agreed upon approach, then we can assign each other issues
in the usual way, to make sure we don't dupe work, etc.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/googlesamples/android-architecture/issues/215#issuecomment-292724174,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AD1DEHbtNum4wgOpLYCQFewgr52ra_Qbks5rt6RMgaJpZM4KV-AF
.

[sockeqwe]

If a helping hand is needed I will gladly contribute some code.

[kanawish]

@sockeqwe Oh awesome :) I added you as a contributor on the fork. Should we try to have a quick sync-up this week to split up the work? I'm going to have a bit of time over the next 2 weeks.

[sockeqwe]

@kanawish thanks for adding me. Sounds good to me. However, I would appreciate if you and @VisheshVadhera would take the lead on API / design decision because I already have built a working MVI library but I really would like to see how you implement MVI. I'm pretty sure that you have an entirely different solution in mind that maybe is better than the MVI implementation of my library (although my implementation is quite ok and used in production but I'm sure your MVI implementation will be different / better so that I can take over some implementation details to my library 😄 ).

Also I'm not sure if MVI really shines in this simple TODO app example, but we will see ...

[kanawish]

@sockeqwe Gotcha, sounds like a good approach. I share some of the concerns you're evoking. The vague plan I have is to first implement the pattern for only one 'vertical'. (i.e. one screen only) Then it should become clear if there is value in going forward.

I'm super jazzed about getting your feedback! It should make for a much stronger example if we then decide to go ahead.

[erluxman]

Sounds Interesting @kanawish.

[sockeqwe]

Oh I think it is worthwhile to build MVI example @kanawish . Statemanagement is super important from my point of view and something all the other examples in this repo miss entirely (as far as I know, no disrespect).
My "concern" is just that for this simple example / simple UI statemanagement may not shine and make the advantages of MVI over other patterns not that clear (i.e. not sure if a state reducer is needed here, nor are there complex UI states like pagination or pull-to-refresh where you can see the advantages clearly). Many developers new to this pattern may think that there is more code to write in MVI and in this simple TODO example that might look like (at first glance) but they hardly see / understand that you don't write more code, you just write more organized code that otherwise would have been spread through Fragments / Activitys, Presenters, RecyclerView Adapters etc. That is just my concern ... that the advantage is not that obvious at first glance, but it's still worthwhile to add a MVI sample to this repo.

So what are the next steps? I think we should stop spamming this repo's issue tracker and discuss this in the issue tracker of your fork or over slack or skype / hangouts?

[VisheshVadhera]

I think we can have it in the issue tracker of the fork. I am cool with
having it over slack as well, but using issue tracker for discussion would
certainly be good for us as well as others joining in much later as they
can always go back in time and see the thought process that went into while
creating the sample app.

Also wondering if we can have some sort of wiki, where we can maintain
references and design choices while coming up with sample app's
architecture and in this regard having discussions in the issue tracker
(single source of truth ;-) ) would certainly help. What are your thoughts
on this?

On Tue, Apr 25, 2017 at 3:20 AM, Hannes Dorfmann [e-mail]
wrote:

Oh I think it is worthwhile to build MVI example @kanawish
https://github.com/kanawish . Statemanagement is super important from
my point of view and something all the other examples in this repo miss
entirely (as far as I know, no disrespect).
My "concern" is just that for this simple example / simple UI
statemanagement may not shine and make the advantages of MVI over other
patterns not that clear (i.e. not sure if a state reducer is needed here,
nor are there complex UI states like pagination or pull-to-refresh where
you can see the advantages clearly). Many developers new to this pattern
may think that there is more code to write in MVI and in this simple TODO
example that might look like (at first glance) but they hardly see /
understand that you don't write more code, you just write more organized
code that otherwise would have been spread through Fragments / Activitys,
Presenters, RecyclerView Adapters etc. That is just my concern ... that the
advantage is not that obvious at first glance, but it's still worthwhile to
add a MVI sample to this repo.

So what are the next steps? I think we should stop spamming this repo's
issue tracker and discuss this in the issue tracker of your fork or over
slack or skype / hangouts?

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/googlesamples/android-architecture/issues/215#issuecomment-296832349,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AD1DEAy437-Jh_hjjuyZLvCJQMHVXIz4ks5rzRlDgaJpZM4KV-AF
.

[oldergod]

Since there seem to be no sample being worked on at the moment, I started to write one myself.
https://github.com/oldergod/android-architecture

[malmstein]

nice one, I'd like to help you out @oldergod !

[kanawish]

I ended up going rogue a fair bit from the original proposal. (To be fair, it was written a while ago.)

https://github.com/kanawish/android-mvi-sample

This is basically a complete re-write of the todo app in Kotlin. I'm importing the UI only from the original project. My first goal is to publish a series of video courses based off of this.

I'm not really looking to fold that specific sample back into the architecture repo right now. But if you have time [ @malmstein / @sockeqwe / @oldergod ], I'd really appreciate feedback.

[JoseAlcerreca]

https://github.com/oldergod/android-architecture added to external samples!