Wednesday, August 31, 2016

Fluid UIs V

Now for the interesting parts. I have to modify some interfaces and abstract classes so that the GWSFluidx framework is used properly.

One, I have to coerce 3rd party developers to initialize the id var in the View-Model with System.currentTimeMillis() so that each view-model has an unique id all set ready for RecyclerView stableIDs both for mutable view-models and immutable view-models.

Two, I should provide two additional base classes per new Adapting strategy that show how to set-up AsyncTaskLoader and CursorLoader in place  for times when its Network or SQLite data that is being retrieved.

And, of course publish a docs gh-pages website.

Tuesday, August 30, 2016

Fluid IV

So, I am in the process of the final re-write of the RxJava is Not AppResponsiveness article about  GWSluidx that will appear in Some interesting points:

1. How many are actually using the split up the RecyclerView Adapting and Bind operations and off-loading the Adapting ot the non_UI Thread? I very sure that with their past rewriting of ListView that Facebook is probably using the technique. Contrast that with start-ups like Airbn, which is not. Because we have to change things at the App Architecture level to implement that might be why more start-ups are not using it at the moment.

2. Naming confusion. I am still calling it an adapter, but I should change that as its no-longer the RecyclerView standard adapter with adapting and binding all in one operation. No idea what to change to will have to look at a thesaurus to find a better word choice.

3. Optimizations such as stableIDs and partial View-Model is not implemented in GWSFluidx yet. One could implement that via ViewTypes but I really do not want to tie View-Model to view as that messes up off-loading the creation of View-Model on the non-UI thread.

Saturday, August 27, 2016

Fluid UIs III

One of the problems in centering the App Architecture pattern around RecyclerView is that its tied to the Android Support Library edition of recyclerview and thus you cannot use all those great extensions to recyclerview.

In September, I will start work on GWSFluidxExt3ended which will link to an extended version of recyclerview with all the bells and whistles.

Thursday, August 25, 2016

Fluid UIs-The Correct Asynch Construct

I have to change my framework code as obviously AsynchTask is not the correct Asynch construct to use. It's not correct as the AsynchTask is not android lifecycle aware.

We want to use AsynchTaskLoader as its android lifecycle aware and does not hold a reference to any UI part. It helps prevent the Task from trying to communicate with a destroyed UI view such as in the case of the device orientation changing.

If it was known to be longer background task, its just formatting display data and populating the ViewModel or Presentation Model, than I would be using the FutureTask which provides an added feature of being cancel-able.

True I could break down and use RxJava's Observable, but my point is its not necessary to bring in Rxjava if you know the correct choices in your implementation of a fluid UI.

Monday, August 22, 2016

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:


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?

Thursday, August 18, 2016

RxJava is not App Responsiveness!

RxJava is not App Responsivenss! here are the two areas of App Responsiveness:

1. Use Immutables in all object models to reduce GC

2. Separate ViewState, ViewModel, AdapterModel, DataModel and wrap the adapter code in an AsynchTask to be done on the non-UI thread. If using a binding library that is the only thing that should be on the damn UI thread!

Now, how you handle the callbacks and data flows is up to you. But I do not believe that you need to use the heavy RxJava or agera to achieve that as you could make up your own monad and promise implementations.

The magic bullet towards app Resposniveness is not rxJava!
Its actually knowing how the Dalvik/Art VMs work and how the graphics UI pipeline in Android  works and changing things to minimize what occurs on the UI threads.

Monday, August 15, 2016

New App Achitectrue:GWSAdux

The repo is up to the new app architecture for Android, called GWSAdux. The very first alpha release will be in the next 10 days. Its focused on app Responsiveness.

Saturday, August 13, 2016

Its Probably Adux

Remember, I am completing an attempt at a new app architecture for android? Its probably going to be named Adux. Why Adux?

Well, when I looked at the redux implementations on android I noticed that they were all wrong in that the device orientation changes were not handled. But, when you make changes to implement that you get more than one State class so its than not really redux but Adux, get it?

More info coming this next week with the repo published this next week.

Wednesday, August 10, 2016

Sweet Immutable magic

Put an immutable collections container in a ViewModel, shocking magical. Okay, I being obtuse...ViewState container as an immutable collection, plus ViewModel with the inside container being an immutable collection object, and plus some other immutable collection data handling magic.. AND no effing need to even touch huge RxJava! :) damn!

Monday, August 8, 2016

Functional Programming is Fun

Well, its fun if you figure out a way to get Responsive Android Apps without resorting to use RxJava and its large learning curve.

Saturday, August 6, 2016

If using RxJava or Agera

If using rxJava or Agera could you please consider maybe understanding why using AutoValue objects in your models might be a good idea? One could use the Immutables annotation processing to auto generate such things:


Wednesday, August 3, 2016

New App Archtiecture

So expanding on View-State as Immutable is creating some new App Architecture Components that go with it. The problem is what to name it?

Its not MVC, MVP, or even MVVM. And its not even Flux or Redux as views are not recreated to update them.

Should I name it, FauxFLUX?

Tuesday, August 2, 2016

MVC MVP no View States?

In MVC and MVP you have this in-bred notion that if we include View-States that somehow its no longer MVC or MVP. At least the purists try to paint it that way.

But, in Android we are dealing with a semi-controlled controller which is something that on desktop and server the MVC and MVP patterns never originally faced.

Maybe we should be exploring View-State?