Fluid UIs

Okay, so rather than attack Fluid Uis from the state immutable part I revamped an approach where we attack the fluid Ui problem from moving stuff off the UI-thread.

Backgound: When RecyclerView was first released it sheppard in a new way to do things and have view holder by default enforced. Well, it changed things in that the adapter no longer did just adapting compared to the old ListView. The Adapter now did not only adapting but also binding to the view.

Binding is okay on the UI-thread, BUT the adapting part as since its not bound to the view should not be on the UI-thread but on the NON-UI Thread. Most of you wrap the http calls in the asynchtask and that is not enough.

And we can in fact separate the adapting from the binding and put them on different threads. And the trick is to do it with only one application wide thread pool and provide enough debugging hooks so that when one uses this framework one can keep track of whether their app arbhcitecture regresses in performance on this set of issues.

AND, yup thee is an and, be flexible enough that I do not dictate what Android App Architecture pattern you want to use to make use of this framework.

So the project with the new approach is:

GWSFluidx

https://github.com/shareme/GWSFluidx


First release is in  September.

I have been through enough code to know most android devs are not doing this. Even the Google IO app demo does not do this, WTF?