Tuesday, September 27, 2016

Demo and Book progress-the reorg

Okay, so I am doing some android app demos that show a certain gradle build work-flow style and a certain android java app work-flow. I have re-organized them from what they were you may at least want to check out the gradle set-up:

GreenAndroids  
RedAndroids
BlackAndroids

GreenAndroids is the Task app demo. RedAndroids is the WikiNote app demo. BlackAndroids is the Wizard Form App demo in the them of an online SandWich Shop Ordering App.

The whole idea as far as work-flow is that I can show the advacne android dev book readers the demo apps as examples of an advance gradle android app workflow as far as development.

The two android dev books are getting re-organized into two git repos:

BeginningWayOfAndroid

AdvanceWayOfAndroid

I had to do that as GitBook tooling only recognizes one book per repo at a time. But, if any of you are thinking about using GitBook tooling for documenting a project you might want to take a look at the set-up.

The whole set of ideas in concept with these projects is that I want to present a Strong Set Of Signals to potential clients that they are conversing with an Android App Developer Expert. I somewhat disagree with the lazy DesignShop approach of just listing their top clients as the set of strong signals.

As side benefit me producing code samples and apps fro both development books and updating those samples after each new edition of Android OS means that I am at the exact same level of expertise such as Mark Murphy of CommonWare LLC and BusyCoder's book series fame.

Sure I regularly score in the top 10% at StackOverflow but that is just not enough as far as strong signals to use as marketing my skill-set.

The side benefits is that it forces me to come up with some tools such as full debug drawer and a full spec overlay tool for enforcing UI design specs.

Wednesday, September 21, 2016

Right UI

It does not look like much a bunch of projects over a few months, re-starts, failed experiments. But, now the pieces are somewhat clear in how they fit.

The right UI comes from the right UI experimental failures, the right changes in app architecture patterns, and somewhat some luck and a little innovation.

Yes, some app demo videos in October.

Tuesday, September 20, 2016

Demos Apps to Write

I still have to figure out what other demo apps to write for the dev books I am writing. I am writing my own Todo App but its an actual very lite application with none of the bells and whistles one would expect in a todo application.

The thought has occurred to me that I could take some Google Demo apps from say when Android SDK 1.5 was released and maybe revamp them for the new UI features, etc.

Monday, September 19, 2016

GWSFluidArch and book progress

So I evolved GWSFluidx to GWSFluidArch, which is at:

https://github.com/shareme/GWSFluidArch

The app patterns enabled by the Library are MVC, MVP, MVMM, Flux, and Redux.Soon, you will find app demos using a todo apptemplate demo-ing the app patterns.This way everyone can see the pros and cons of each pattern.

Turns out that I am developing a preference towards Redux or Flux. They seem
easier in the sense that once I fully develop the middleware one will be
able to see replays of action and state as a debugging tool. And, the
amount of boilerplate seems to be less.

How did I handle device orientation changes with Redux or Flux? Rather than try to project some View-Model implementation since I do not want to violate the One State class rule of Redux or Flux I instead use the project icepick to allow me to just simply include the state and save it without very much boilerplate. Some time later I will figure outhow to group the view-state in the one global class so that I can flow the icepick stuff through a middleware hook and than all the state stuff will be together in one state class.

The book series is being re-organized at:

https://github.com/shareme/GWSWayOfAndroid

Turns out that to have the book popular enough, both of them need to be about 24-25 chapters.That is not counting the 7 extra chapters per book. The first one is an introduction to android application programming with the second book covering AndroidAuto, AndroidTV, AndroidWatch, and some advance android application development subjects such as functional-reactive programming, app arch patterns, etc.

The chapters have been decided, now the cranking out the outlines and code demos and the chapter content begins. At times I will re-purpose the content as medium articles as I progress in the book writing. The books and code examples in raw form will be downloadable from github and as soon as I find a publisher that accepts pdfs to print the hard-copy books I will note it in the project readme and project website.

Saturday, September 17, 2016

GWSFluidx, Evolving It

Turns out when you implement the view-model as per adapter item and tie that to the adapter that its too tightly coupled to domain, data, and presentation layers and other things. Thus, I am evolving it to GWSArch.

GWSArch will have components for MVP, MVC, MVVM, and Flux. This way other developers can see why you might say start with MVC but than end up converting to MVP, MVVM, or Flux. The code repo will go up on Monday.

Do I have a preference? Currently, although I do like MVP I am leaning towards Flux. If you know of a start-up in your geographic area that is seeking a remote android dev than email me.


Thursday, September 15, 2016

If I separate out Binding

If I separate out binding from the adapter in GWSFluidx beyond what I have into something that accepts different view types, than it would seem that I be able to offer equal  hooks to Google DataBinding and other binding solutions.


Wednesday, September 14, 2016

The Real Fun part

Now, comes the real fun part as I want the adapters in the GWSFluidx framework to support multiple view types but I do not want to rewrite the adapters. I probably have to separate out binding more than I have, well hopefully.