Monday, July 18, 2016

We Are Doing RxJava Wrong

So RxJava is all the rage of Java and Android Application development. But, what has bothered me is obviious question never gets answered by java developers.

Why Does It Make Sense To Give Away Half the Beneifts of RxJAvA By Insisting On Integrating It Into Our Mutable OOP Patterns?

You Do Realize That MVC/MVP/MVVM And All Their Hybrids Are In-Fact Mutable, Right?

Yeah! Do You Feel Stupid?

If I insttead use an OOP Compound Pattern than makes data immutable with the data control in functions, than I get both Composition-Over-Inheritance and Immutable with the full responsive app features instead of half of them with RxJAva.

For those following along, its similar to FaceBook's Flux:



except we are not using Reactive bindings for views but the Android OS framework components and when we do need the Director component we are using RxJava to provide that functionality.

NOTE FOR PURISTS: If I wanted to be pure the views would be recreated when updating, instead I use the Android Framework machinery and update views. And of course I am not using pure POJOs in the Domain but those with that are Parceable.

Okay, okay..to be fair when the NetFlix RxJava project started we were still dealing with those Android Devices with low Ram memory. Because everything is immutable it takes a little more Ram for this approach.

But, at API 18 and beyond we are no longer dealing with any Android Devices having low Ram and from api 16 to api 18 there is only one market where Android Devices with that low of Ram are still prevalent in the marketplace, China. Since most of us are not dealing with the China market it might make sense to switch now to this new way of Architecting an Android Application.

And by accident I found the hook to differentiate me from other Android Developers to obtain android app development gigs. As I can emphasize Huge gains in Android App responsiveness by architecting the android app in this way.



But, what to name it?

SoidumReactor?

SodiumFlux?