Wednesday, December 30, 2015

The Marketing Draft, LAUNCH THEIR LIVES

So now I took part of the working tagLine and did a draft of some ad copy about Android Application Development:



Mobile Applications are very different from Web Applications. Web Applications and Google Searches are about the INTENT to do SOMETHING.

Mobile Applications are more EMOTIONAL  in that LAUNCHING and RETELLING someone's LIFE in terms of THEIR HOPES, DREAMS, and ASPIRATIONS and steps and tools to obtain those things is what the MOBILE APPLICATION is all about. YOU WANT THEM to feel that the MOBILE APPLICATION they just downloaded and or bought gives them some steps and tools towards REALIZING THEIR DREAMS, HOPES, AMBITIONS, and ASPIRATIONS. If you do that in your Android Application than you will have those mobile application users for LIFE as far as them using your application on a monthly basis.

The other IMPORTANT aspect of LAUNCHING THEIR LIFE is that by transforming data to a new use or service one can provide resources in the form of tasks and steps that TRANSFORMS ones LIFE in doing a set of tasks of an activity.

But you need a structure of code that combines with a visual stunning GUI using HUMAN PSYCHOLOGY and HUMAN BIOLOGY that provides a framework that in little steps LAUNCHES THEIR LIVES in steps towards REALIZING THEIR DREAMS, HOPES, and AMBITIONS.


ANDROID and iOS are of course different mobile application platforms. ANDROID has some distinct advantages if you are in need of a fast way to do a POLISHED GUI MOBILE APPLICATION in fast amount of time. Some brief background into this area.

The C computer language was designed for constructing Operating Systems because programmers were tired of using Assembly Language that had to be optimized per CPU as C is CPU agnostic. With C++ the added more stuff to the C for OOP use.  ObjectiveC, which iOS uses, and Swift are still just layers on top of a COMPUTER LANGUAGE that is still oriented toward the Operating System creation way of doing things. Its still quite a bit in-flexible and not fast in code creation as far as creating Applications.

In ANDROID's case it uses the Java Computer Language which was designed to make it easy to build OOP applications without the in-flexible HEAVINESS of Systems Operating Programming C-way of doing things. This is one-half of the core reasons why I can take a 4-month estimate of completing an iOS application and state that the Android edition of the same mobile application will only take 2 to 3 months to develop.


The other HALF of DOING IT FASTER THAN iOS has to do with understanding that GUI mobile application have a-lot of boilerplate code to them and that one can build up a GUI and Mobile Application set of libraries to reduce, SIGNIFICANTLY, the amount of boilerplate code that has to be created. This goes to the heart of the GROTTWOKRSHOP difference in that I can create the Android Application faster than any iOS developer you can get to create the iOS application and that Android Application is structured in a way to assist the Android Mobile Device User to LAUNCH THEIR LIFE.

By LAUNCHING THEIR LIFE you can LAUNCH your start-up. By LAUNCHING THEIR LIFE you can LAUNCH that increase in productivity that saves your enterprise money. WILL YOU NOT TAKE THAT STEP TO LAUNCH THEIR LIVES?


It still needs some word-choice, word repetition and length tweaking. But its getting to the point of what one hopes to accomplish as far as a start-up or enterprise in asking some one to develop a mobile application for them.

SIDE NOTE: This marketing draft is somewhat in my tone and voice so copying it to attempt to use for yourself will not produce good results.  You need to do the work of figuring out a marketing hook for yourself and than the work of writing the ad copy.

Tuesday, December 29, 2015

Launch Their Life

I have been trying to come up with a way to describe why mobile applications are different than web applications on a more marketable level.

Launch Their Life...

So this is the first part of the tagLine I came up with as that is really what every firm or start-up hopes to accomplish with the mobile app that they have someone build. Its not just consuming something but empowering THEM to Launch their own Life one moment-at-a-time.

Monday, December 21, 2015

Google, I Being to Wonder About You

Google, I begin to wonder about your firm when one of your inside recruiters contacts me as has no idea what the Google current Gradle Android plugin is or what the old brittle one that I worked on is in mentioning my Linkedin Profile highlighting such a thing.

Do us a favor for all the hard working developers out there, have your inside recruiters look at github  and bitbucket profiles instead..PLEASE!

Thursday, December 17, 2015


Yes, that is what you eventually end up with if you start using Google DataBinding with MVP, a structure of View View-Model and Presenter.

Tuesday, December 15, 2015

Visual Design vs OOP Dev Best Practices

Most design folks get this wrong.  Visual Design is what triggers the impulse of the mobile user to download a mobile app to try it.

OOP Dev Best Practices is what takes the feature set of the android application and allows the developer to make a set of architecture choices that make a intensively highly stable app which than moves the monthly user retention curve for that android application upward. As choosing the right Architecture choices gives the developer a flexible framework to evolve the app-user-work-flow to impact and move the monthly user retention curve upward.

If you do not start with a strong android java developer you will not get that highly stable android app container to inject the visual design into for that first impulse download or buy. Thus, you will get instead a high initial download rate but somewhat poor user retention curves.

I have to state it this way due to past experience at a Music Start-Up last year. In that they used an outside firm to tell them that social media impacts the user-retention-curve, well not it does not impact the user-retention-curve but instead like visual design impacts the first user impulse to download that app and try that app.

The reason why this is important is that start-ups only get funding past speculation when the user-retention-curve data indicates a sticky product as far as high monthly amounts of users using the mobile app.

Monday, December 14, 2015

MVP and MVVM Design

I am now at where the agile dev design process of developing a MVP and MVMM patterns libraries. But how to implement this as certain choices have un-intended consequences.

Such as what? The choice of what to bound generic types by for example.  In view models and models to be precise you could bound the generic type to the android class, Parceable.  Nothing wrong with it as the JVM junit test side of things on Android as the android.jar has the methods as stubs on the jvm junit testing side.

So what is the un-intented consequence?  Guess. You have to create ParceableTester to mock the Parceable class.

But, probably the pure POJOs folks will disagree, with the new Google strategy of having a test JVM Junit style android.jar with the test flavor in a project one can use Parceable in model objects in both MVP and MVVM as long as one remembers to construct a ParceableTest class to mock the Parceable class.

Not too bad as its only one small extra class.

Saturday, December 12, 2015

New Agile Build Process

So I am on the last step of my new agile build process which is integrating the debug overlay tools I have into each app module gradle flavor. It than is a snap to say run anew product flavor build and get when the installed apk runs the debug  overlay that is focused on that scope whether its design checking assets loaded or even checking the database or viewing debug log on the device.  Speedier as the old way is to load the apptool to device turn on its service and than install and run the app-in-progress.

Thursday, December 10, 2015

Duz App

So while I am at I should do a demo app that takes less time to develop than the GWSMusiKal app.  My thinking was maybe to mix wikinotes with todo list feature set with cloud storage.

I seem to have a mind block as far as naming so I guess the name will be GWSDuz.

Wednesday, December 9, 2015

MusiKal-GoogleCast and AmazonFling

Last year in working for the Music Start-up they never got that the Android Device and Software ecosystem is different from the Apple iOS ecosystem.  One of the differences is how you cast audio to all the different devices.

In the US Market both Amazon and Google have usb cast-type dongles for devices and accessories for casting to different speaker rigs. And we have to consider this as that is the 2nd most popular environment to listen to music from a mobile device, ie the home.

And at the same time in the Android ecosystem we have those who customize their own ROMs. We do not want to shut those particular android device users out.

Than we have the differences in App Store and Service approaches of Amazon and Google.  Amazon, because they are the underdog, wants AmazonFling to work on all android devices whether they have Amazon store installed or not.  Google has limited GoogleCast to PlayStore Android devices.

Side note, for those not in the know Google does a Play Services stub lib for developers which developer link to but when that is compiled it actually points to the downloadable playServices apk that the user is prompted to download before using the full play services of the app.

Thus in GWSMusiKal I have to set it up so that with the Google Play Store edition having two cast libraries both googlecast and amazonfling along with providing the additional whisperplay jar lib dependency as whisperplay is already installed on Amazon devices but not Android PlayStore-enabled devices.

Where it gets a little tricky is that I have to instruct ROM-customizers to only use the PlayStore app and in Amazon's AppStore I have to instruct users to only install the Amazon AppStore app on FireOS devices. Why?  Because Amazon does not have or has not implemented their own package-manifest style filtering as they use the one that AOSP has come up with. So I do little cautions in the app descriptions and some detection of a FireOS device and etc to do a user caution if they downloaded the wrong edition.

Side Note: I do not know at this point whether I should implement a way to play music files from the cloud services of Amazon and Google. On one hand its probably very important as it may be a in-popular-demand-feature that users might expect. On the other hand if it competes with Amazon or Google services it might get the app pulled and ban from Amazon's and Google's app stores. And I do not think Amazon or Google has public android-intents for their music locker and play services from cloud-apps which means I cannot integrate in that way of starting up those apps.

But, its something to check on to see if they made public intents or private ones. Obviously, if they are public than I can integrate by having those apps start-up when the app user needs that functionality. Of course, that means that we set it up so that MusiKal can replace the default music player to get the full-feature-rich experience of music listening.

Tuesday, December 8, 2015

MusiKal-The App Structure

Okay, so the app name is probably MusiKal and hopefully I can span both the Google Play Store and the Amazon Store and devices without too much pain. But the app structure is not something that can be quickly hacked together but instead requires some planning.

The AndroidTV UI stuff is accessible at 17 via the support library called leanback but AndroidTV is actually 21 api. Android Auto is 21 or higher. And Amazon Fire TV uses different stuff than AndroidTV. But since LeanBack Support lib is not using the native part I can do one combined UI as module library that spans both Google Android and Amazon Fire.

The fly-in-the-soup is Android Auto which is 21 or higher. So on the Google side of things I have to one app that spans 17 to 19 and than another app edition that spans 21 to 23 that includes Android Auto. The app that spans 21 to 23 would have two library UI modules as dependencies one that is the common UI and one that has the Android Auto specifics.

Android Wear is its own separate app and there are NotificationCompat classes in the support libs for the phone/tablet side of things.

On the Amazon side its a little easier one app for both phone/tablet and tv.  Still have to find a Google cast replacement though.

I will be using the MVP approach as with AndroidTV UI its Presenter based. And I will be using Dagger2. I am keeping using package names to identify the domain layers.

On a side note, the audioFX new apis start coming in at api 17 and 18 anyway so its a chance to use those as well as the default music player in android OS does not use them for some odd reason.

If you are a Github member and do a follow of me you will see the github repo for this pop-up as the name GWSMusiKal:

GWSMusiKal Repo 

So that is generally the approach to it..Sort of different than the Google approach with that Universal Music App sample as on a lot of stuff they just punted..well its simplistic sample what do you expect?  It does look backwards in that most of the app is in gradle subproject modules which had to be implemented that way to so that I could implement apps both for Google Play Store and Amazon Store.

Monday, December 7, 2015

Music App-In-Progress

Last year, I did some work for a music start-up. So I wanted to get back to some of the development puzzles I encountered last year and take another direction in solving them.

So I broke down things, first was to break down the back-ported UI feature libs into those I know I had to use but also audit them and clean them up so they work as advertised.

Second, was getting a reliable set of gradle build scripts that sort of match the development workflow I was implementing. App has several product flavors for debugging both code and design.

Third, was working out a implementation strategy as music apps like some android applications has many different devices and with the re-introduction of AndroidTV it gives me a chance to work out how to handle something that along with Amazon store and devices might have 3 to 5 different apps.  My idea is to implement the music player BO's in a separate library.

That way I can vary the UI of the two UI components of the player across devices and apps and I can have an adaptable UI that spans well the different aspects of android TV, auto, wear, etc.

So rest of December this blog will be filled with screen shots, code, etc of that music app in progress.

Why I Ask Freelance Inquiries To Email

Maybe you do not have a clear idea of what a freelancer developer does on a daily basis. You see I have this list of short-term things and this list of long-term things and I on a daily basis complete tasks from both lists.

When you contact me asking if I am interested in a project with no details except that has an aggressive schedule, what am I to do but to ask that you email me the details of the project to me. If instead of doing that you instead insist on requiring me to call you, well that convinces me that there might be some problem with you following directions.

Please respect the freelancers time as they are doing many things during day besides what you hope they do for you.

Wednesday, December 2, 2015

Fast Prototype Prep

So, I am on my last phase of developing a fast prototype system with the goal of being able to do a 2-week spring on the core feature of an android application and than be able to do some market validation analysis.  Very different from the broken water-fall system.

What is different is the amount of up-front preparation I had to complete to get some type of system both in android libraries already prepared and revamping my gradle build process to have the debug tools integrated and design debug tools integrated. But it is still flexible enough that as new processes and tools dev, I can than add those to the full system.