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?