Friday, September 30, 2016

Demos and Book Progress IV

So now that I have GreenAndroids full data layer kind of in-place(upload tomorrow) I can focus on the two items for next week. The first is a debug drawer which of course is code focused.

The second item is a graphics Debug drwaer to put keylines and several other things into one drawer or toolbar for graphics debugging. Of course adding Jake Wharton's madge and scalpel libraries, etc. Than later on will separate into its own stand-alone library.

As far as the book, I am chugging away at Chapter0 for the beginning book and should have the first chapter and code samples finished by end of October.

Google Dumb Android Developer Documentation Errors by DUMB GOOGLE Engineers

Okay, this going to be an effing rant. Fair warning Google Enginners you wlll not like what I say. But, in the spirit for better android developer docuemntation for beginning android devlopers I must state it!

First let's travel to the beginning android developers mind. The Android SDK no longer distributes android app samples and the beginning android developer is suppose to get those from the the
google github account repos.  So the beginning android developer than is trained to expect that is android dcoumentation too. All good in theory, no? What could go wrong?

Now would it not be very bad if we had say Google app architecture samepls that in-fact do not compile but instead throw up android app dependency conflicts that could have been prevented if just the simple damn thing of just running a gradle build to test if the gradle script works?

Are Google Engineers this stupid? Want an example?


and its quite easy to correct as all I had to do was change some of the dependency lines to:




Hey Google effing run a damn effing build on your gradle scripts to make sure they work in the damn effing samples as you are making every aspiring android GDE candidate look very stupid, not to mention yourselves, and we prefer to not look that damn stupid!

Or does Google stand for God oh oh god Lazy Engineers?!

Developer Documentation should be damn effing Job_one not Job Last!

I once was what is called a corporate trainer back when STEEL in the US still had hope And the reason why the client corporation(A STEEL PRODUCER) liked me was that I GAVE A DAMN ABOUT THE STUDENT to such a point that the documentation for the class became very usefull to those students.

It sickens me when I see crap like this, the developer documentation both the docs and the code samples should not have IDIOT ERRORS LIKE THIS IN BUILD SCRRIPTS! And some stupid Google Engineer will state the excuse that well subject A was reviewed and changed in the code review and not in the Android Studio as if that is an appriopriate excuse, it is NOT!

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.

Tuesday, September 13, 2016

Lessons Learned, developing GWSFluidx

Lessons learned while coming up with a better Android App Architecture framework:

1. The average android developer may come up with a gem of an idea, but no-one finishes with Polish! And its not that effing hard, just start doing research on how to solve certain problems as you can either set up examples demo-ing what is wrong to develop a solution or ask google and stackoverflow.

In the case of GWSFluidx the original project by another android dev did not have the duplicate AsyncTask solved, nor the presenter being managed during device orientation changes, nor the base classes for data loaders,etc. And code was not split into binding and nonbinding modules for those who want to use Rxjava or Agera instead of the Google data Binding.

2. You can probably solve the duplicate AsyncTask by making a variable to store the Asynctask sub class and initialize it to null and than you can set your inner AsyncTask class to that  and than set the var back to null at the important partsin your inner AsyncTask. And geeze uh grab the Thread and set the effing name of the thread so you know what AsyncTask is executing! Just, that little more effort in polishing code that makes it easy to debug!

3. The Android Framework does not fail-safe to responsive fluid UI apps. You have to do some work. Hence, the library to eliminate some of the work.

4. As far as educating non-android people on the importance of things like this in android app development is still somewhat a tough nut to crack as most Start-Up co-founders do not have android devices or think that its their duty to try and find out about android app development even if they need an android developer. And some of those Start-Up co-founders due to that lack of knowledge often get screwed by the temp agency or recruiter despite the knowledge resource right in front of them that is somewhat free just by asking questions.

%. Redux and Flux are Reactive approaches to mobile web apps and really do not adequately fit what is needed for the android application environment.

6. Focusing on View-Model and coupling certain items to the RecyclerView Adapter gives us a more robust MVP pattern that happens to avoid coupling the Presenter to view, data-source, and user case models with the adapter serving as the interactor and only coupled to one data source.

7. With Google visiting my LinkediN profile regularly, Google Guys and Gals can you consider the GWSFluidx framework as maybe part of my submission to become certified as an Android GDE? You know from my LinkedIN profile that I am probably not moving to SV, its the least you can do.

8. Adding other RecyclerView extensions might not be as difficult as I imagined, hopefully. The trick is not  to do everything, but focus on those things that allow the 3rd party dev to easily implement their need by building on some basic building blocks.
Building blocks such as more than one type in the adapter(allows doing header and footer views for example), precaching pages/screens, and etc.

10. As far as a command layer I think I can just do a simple routing layer that allows both a multiple activities/viewgroups app and an activity/fragment combination. I do not think it will be that hard to come up with an implementation. And it should allow passing of EXTRAs ie the bundle extras that way its somewhat robust as what we can in fact do with the routing api.

11 The average app under either MVP or MVVM architecture patterns takes a significant number of 20 plus classes to implement clean architecture. Using GWSFluidx framework and the MVPVMor MVVM pattern I have got it down to 12 classes or less per usercase. A somewhat easier structure to understand at first glance. Which translates to get features out-the-door faster.

12 Prefetching pages with RecyclerView, evidently there is a hack. You have to subclass LinearLayout and override the protected getExtraLayoutSpace method and supply enough pixels to represent another page. Which  reminds me I need a screen height computation  method as I do not want to hard wire it at a fixed pixel amount like the original dev who came upwith the hack. Way different than what you had to do with ListView.


13 Its amazing the amount of crud boilerplate one can eliminate from implementing MVP and Clean architecture by coupling the app architecture pattern to the adapter. My estimates and experiments indicate that one can decrease the boilerplate classes by 40 to 70 percent per user case.


NOW, if you were say a Start-Up co-founder would you not want this in your new Android Developer?

Saturday, September 10, 2016

Polishing

Now, its the week-long polishing work on GWSFluidx. Things like:

1. Finish the RxJavaISNotAppResponsiveness medium.com article and publish it on medium.com
2. More code clean-up I found out how to prevent duplicate AsyncTasks so need to incorporate that into how I do my AsyncTasks and how I do my AsyncTaskLoader base classes.
3. Complete a wiki for the docs and gh-pages website for the framework.
4 Finish the nonbinding module as for those who want ot use RxJava or Agera as their binding implementation tool.

Kind of  accidental finding that my Presenters are fully decoupled from the data-source,view,and the usercase models. That is one of the benefits of coupling the view-model to the adapter machinery.

Thursday, September 8, 2016

Interesting Android Dev Myths

Interesting Android Dev Myths:

1. Retrofit 2.0 Asynchronous means we do not have to put  into a non-ui thread.

2. RxJava means app responsiveness is created by default just by using Rxjava.

3. You cannot use AsyncTaskLoaders with Presenters.

Tuesday, September 6, 2016

MVPVMA, oh the changes

I think the first thing to wrap your head around if you do use view-models and an adapter based pattern is that its so much simpler in that the view-model because its iterated per item in the list or grid is in vact the view-state by default.

Sunday, September 4, 2016

Why does GWSFluidx work equally on Android 4.x and Android 5.x?

So why does the trick of off-loading the adapter work of Recyclerview form UI thread to non-UI thread work equally well on Android 4.x which is only one UI thread and Android 5.x which has an UI thread and a RenderThread?

What is common to Android 4.x, Android 5.x, Android 6x, and Android 7.x is that the scrolling part of the UI process is on the UI thread. By taking the aapting part of recyclerview off of theUI thread I end up not blocking the process that does the scrolling.

Friday, September 2, 2016

FLuid UI Article Title

I do not think RxJava is not App Responsiveness is enough of a marketing title for the article behind the GWSFluidx library. Maybe a better article title from a marketing aspect would be:

iOS Fluid UIs, But its on Android!

That seems to fit my goals of my marketing push somewhat better.

Thursday, September 1, 2016

Fluid UIs VI

Now the gritty part of improving GWSFluidx. In the original code author's project that I am borrowing the code and concepts from he had hard-wired the display of the load times within the demo application.

Well, that really is not really compatable with what normally I put in a debug drawer to execute on the debug gradle build flavor to debug the app. Maybe its as simple as putting a set of tags around the timing log statements and than picking that up in the
debug drawer and displaying it?

Well, I did get two abstract AsyncTaskLoaders developed. One is for just simple loading data and one is the same thing but uses an Intent to broadcast. Still have the CursorLoader to deal with, however. Why one that broadcasts an Intent? Because I think may have to do that to support loading data from SQLIte or Realm as I do not want to double the methods of the library by doing the bonehead implementation of modifying the adapters to support SQLIte and realm.

On the article front, just finishing plugging in all the background information, etc to make it a polished Android dev article for my post on Medium.com. Should be published labor Day Weekend.