Tag Archive: agile

So those Agile Android Articles

At some point last year I stated that I wanted to teach android differently. Some of that is that you should start teaching certain things sooner such as Agile. Thus, recently I re-did the design of my gh-pages website. Not only is it now view-able on mobile but also I am starting to put up long articles there, such as the Contrarian View, DeviceID. Believe it or not a lot of assumptions about using ANDROID_ID and or deviceID are somewhat wrong and ill-advised, you probably should read the article.

For example, ANDROID_ID is null for Kindlefire, along with deviceID if its a WIFI only device and yo guys know hat googleTVs do not have deviceIDs, right? THe article offers new solution and the code to implement that solution.

As I go along during the year I will be filling out the article list with articles on agile.As a side note the trick of pinning the 2nd navigation bar upon scrolling is in the application.js and you can clone my github repo to get it along with a recent copy of twitterbootstrap2.0.

From time to time I get requests to ‘rescue’ a gig because some developer is leaving the  project. Which is fine,it happens but if I was leaving the project my last act wold be recommending a developer to take my place. But, in most cases its the middle company or end client makig the request.

But, that is not really the problem. Its a level of expertise used before not matching what could be implemented to save the end -client costs n the long-term while delivering a high quality look-and-fell mobile android application. For example, its common for me to use at least one class that is compiled to the highest device-target out in the android market simply because I am wrapping classes to target common UI features/functionality. In other word part-of-the-fell of that UI.

The other aspect is right now to avoid constantly updating an UI per OS release that comes down to end-user devices for apps that are distribute internally in a company you have to target  that compatibility library. Not only do you have to target it but you have to modify or customize it. Its real damn easy to see or analyze and determine fi some developer is not doing that even if you are only exposed to the project manager conversation.

By me asking for source-code and getting said source-code the project manager is communicating to me that they understand that I am reviewing(interviewing) them and they accept that I may make suggestions to improve their project situation and that the project manager understands that I will find out real quick if any miss-representations of the project quality/progress are being made and thus there is less risk of a project manager making material miss-representations.

Is it really that hard for a potential project manager not to understand that they are in-fact being interviewed if a project is loosing a developer?

Agile Android Dev in Anger

Some of you saw my AndrodCMWrench project go up yesterday, including a project dos site for the project. Do you realize that was just few hours to generate the website and complete ant script tool?

One of the problems every firm faces is that its the perceived notion that obtaining an android developer at premium prices means a slow development cycle. Google and OHA was kind enough already to make a choice of Java for Android Application Development which serves to somewhat halve the development time when com pared to a non-VM language such as Objective-C.Should we not take it rest of the way?

Imagine this,a complex android application getting down to its core features and a fast prototype in a week to two week period.  So, what are the areas left to improve/

Libraries can be heavily used to reduce development time. Not just one the application side as you can create jars that are used on the Android Instrumented Test Project side. It is also the tool-integration side.

If you look at source of my gh-pages branch of AndoirCMWrench you will notice that I did not use Github’s Jekyll. Why? Because I do not have an IDE Jekyll plugin so go with something that I have a plugin for. In the Android Application Development context since I have a nice plugin to make shortcuts of my ant targets, I can develop a nice tool that fires off execution of the MonkeyRunner scripts to run not only TDD/BDD unit tests but also regression testing right from the IDE.

This is what agile is, analyzing  your development work-flow to get better feedback and in shorter time periods to improve the stability and quality of what is produced.

There is a clown of a-Chicago firm(cough 4tegroup, cough quite spamming me folks) that thinks knowing how to write a Continuous Integration build script is agile, the only problem with that is that no-one in android development writes continuous integration scripts due to the differences between CI plugins and what we need to inject in certain ant stuff on how the android sdk tools operate. We tend to write a full ant build scrip  that integrates with the android sdk tools and our code metrics and than just have the CI server be pointed to run that instead.

So do not be that clown-of-Chicago firm be curious about your developer work-flow, the libraries you use, the tools you use,etc. And if you do not have time and want to borrow my tools and libraries, than just make sure that you follow my github account.

Okay, a small agile tool. Instead of counting on Google ot get the ant scripts right with every SDK release, just use your IDE and its android plugin and this small ant script(AndroidCMWrench) to run the the code metrics and javadocs after your IDE does an incremental build.

Shh, if you actually clone the project and look at the gh-pages branch you will have a nice simple example of how to use twitter boootstrap in your project docs.

In my quest for Agile with a vengeance I have been not only examining what to add to my instrumented testing tool box but also what other things in my developer workflow to change to squeeze every ounce of development time saving so as to be fast in two areas, prototyping and android app production. Why?

Because we know that Google will continue to put no-one in charge of developer acceptance testing the ant scripts provided with the sdk during each sdk release. For those that do not know, if you execute the targets in the Google supplied ant scripts from the android sdk you find the show stopping errors in the build.xml that will prevent you from using it un-modified, which means non-one at Google bothered to even test the item before any sdk release.

That is my former profession creeping in, I use to train corporate end users on computer software,which meant I had to develop the courseware. That involved inventing some techniques to ensure that the courseware was always right. That involved just taking the specific piece of software and attempting to use it in the exact way described in the courseware. Its not hard andnow its sort of a habit I cannot shake.

So we know we cannot count on Google to ever field test the ant scripts provided with the android sdk before each sdk release. Sure we could modify the sdk ant-scripts each time and than copy them into every project we have to build and than customize that to include our code reporting stuff. But, there is a better way. The IDE that we often use already does incremental builds.

Thus, if we only need to run code metrics after the build we can than move on to saving time both in the fast prototyping and app production cases of our development workflow as the Eclipse IDE has this neat feature where you can check under runs as ant build on the build tab build the project before running the ant script. So the projects i ened up with thus far are:



and AndroidCodeMetericsSetup to see where the Eclipse IDE stores the pmd, checkstyle, and classycle settings/reports. Unfortunately, each code metric plugin in Eclispe stores its reports or generates its reports indifferent formats and locations and so thus I had to come up with the plan to develop an ant script that runs after the project build and generates the javdocs and the codemetrics reports.

Now, its on to the next step in that I create a new project that combines AndroidDoclavaSetup with an ant script that executes the generation of javadocs using Doclava and the code metrics reports that is designed to be executed by the IDE that has a-run-after build setting in their run-as-ant-build feature. Than to polish that I will come up with a python script that you can put on path that will move those assets from abase-template folder to the newly created android application project.

Thus, what I end up with is that I can immediately be productive upon each new sdk release as I am not DEPENDENT ON GOOGLE’S OWN FUCKUPS in the SDK PROVIDED ANT SCRIPTS.

Why Agile In Android?

If you use OOP than this looks like your code:

and in Android it gets worse in the Activity and other classes with views boilerplate, etc mixed in. If we are willing to change our workflow, dev techniques, and toool integration we can have this:


Guess which is easier to analyze and maintain? Yes, its true you can get some development time savings by adopting to new tools like LessPainfull or other instrumented testing in the clouds android testing solutions. But, the amount of time savings is not that much because as your accuracy of test results increases so does its effective use which increases your dev time as you make sue of those results,ie you get a huge increase in QA quality for some inceases in devtime.

If you separate out the concerns rather than just inject them we should see a decrease in development time as code libraries are built up as some of the cost savings wil occur when you re-factor the libraries you are using to separate concerns. Iteration-wise it should allow any android developer to push out iterations of an android application faster than they have did such development work before by at least a2 to 1 factor.

Now, of course if you are a start-up you could get the android developer candidate that looks pretty on a resume for the HR department to gleam about or yo cold just maybe pay attention to technical and development debt and get the android developer that develops new techniques and processes and tools to solve both short-term and long-term problems.



The other aspect of agile is that you go through an evaluation process of your workflow and development tool chain. As we all know the docs on the android emulator are oblique in some areas.

To properly use BDD instrumented testing we have to improve the speed of the emulator. This is specific to those of us who have older PCs, if you have a brand new PC and can get set in your BIOS(assuming you do not run windows) the KVM speedups than you can get the latest android-x86 images and load that in VitualBox as your emulator. For the rest of us its these things:

1. AVD Device Ram size 768MB

2. AVD Cache Partion Size 556MB

3   LCD set to 240

4. Check use snapshot

Now, when you launch an emulator that launcher configuration is stored as the default for next time that you launch that AVD. For phones set the scale to between .54 and .84. Obviously, you can probably leave tablets set at say .54. And of course you also want to turn off the boot animation so in your IDE assuming that it has startup options box you wil enter:

-no-boot-anim -scale .64

Now, that does not take care of all the speed problems as we have a single-threaded qemu emulating arm stuff and openGL, etc but it helps quite a  bit to get it to a more tolerable level when completing instrumented testing.

Robolectric and similar projects have always complained that instrumented unit testing(yes, you can do both tdd an bdd instrumented testing in android development as the plain old unit test classes in the android framework are not loading the tested entity within the android framework system. if you doubt me look at the difference between ActivityInsgtrumentationTestCase2 and ActivityUnitTestCase classes. In Android all TDD unit style test classes have Unit in the class name.) takes more time.

Specifically, its the time to dex the classes and to start the emulator and install the application as when in in TDD mode you are writing the tests first before your application code. Is that that much difference between writing several unit tests for one class waiting more for those tests to finish in instrumented test,mode on the emulator or writing some unit tests for a class running the tests on the emulator while you write more unit tests for another class.

But design shops seem to have bought into less time is more impressive results even though as the android framework matures the results for JVM unit testing it get less and less effective as you cannot predict the behavior of member variables that have been exposed. But, you could speed up unit test writing.

You could use hamcrest matchers and you could build the test-assertions-android github project to get android style fest assertions for the android environment which would act not only to speed up unit test writing but would allow you be able to go back to several unit test results after they are executed and understand them as they are closer to plain English than a regular android unit test with those libraries not applied to a unit test.

This not the only concern however in testing. In Android Instrumented Testing no matter if run it for the IDE or the ant script or from a monkeyrunner python script you have three testing areas; Unit tests, Functional tests, and Performance tests. now lets look back at android sdk build script. Notice in the test-helper-runner macro you do not see an value for running junit runner in multi-file mode. What does multi-file mode do? Well if you use an alternative android -junit-runner with multi-file mode enabled than you test results get grouped by testsuite thus than you have them grouped by; Unit tests, Functional tests, Performance tests.

This is why as of this moment I am rewriting the build scripts supplied with the android sdk as to fully get the benefits of being able to run both TDD and BDD in android instrumented fashion in the IDE those ant script changes will than be applied in setting my IDE java/android builder to use the ant script. And due to the fact that I will have a dashboard generated with the docs during the debug/compile target execution containing such things as Checkstyle, PMD, JavaNCSS, class, and jdepend reports it will be somewhat more effective in getting a snapshot view of the project each time I change code.

Than we have the aspect of some areas are not covered well, regression testing and acceptance testing. Regression testing could be enabled by using monkeyrunner as it has  a user/UI recorder. Now, we do have android-guitar framework which runs on to of monkeyrunner which gives us an event model report but it does not support swipes and some other UI interactions. So we have either extend android guitar or monkeyrunner. Actually that is a nop as monkeyrunner accepts plugins that are written in java and thus the plugins you add to extend monkeyrunner could actually also extend android guitar. Thus, that is another piece I have to add to the testing part of the android app build script, ie the ability to execute the monkeyrunner scripts as part of the instrumented testing developer workflow. Also remember monkeyrunner is an automation tool that is integrated with the android framework api which means anything in the instrumented testing process that can be automated is now reachable to be automated. For example, you could turn off the wakeful lock, etc as part of the process of starting the device or emulator in your instrumented testing process.

This is generally why to rescue an android project you have to start-over the 3rd time, at least in applying agile as you need to change the way tools are integrated together in the developer process and the work-flow and of course the culture. Its not can I buy you coffee and you consult for an hour and the project is rescued type of situation. And my thinking is if you want and value the benefits of full agile, not just TDD and BDD but the change in culture which desire upfront feedback(ie transparency), than you have to be willing to put in the time and costs to change it. Are you willing as company or firm willing to hire a developer to change it? think it about another way.

At one point in internet history we were using Gopher and it basically sucked. At time I watched as people(developers) came up with a better way and people started using it and it was extremely beautiful in its simplicity and implementation and execution. That is the joy of solving hard development problems.

how do you Measure Agile?

It is interesting the amount of miss-information out there about agile. I usually get please use agile to rescue a project inquiries once per week. My counter has always been to ask what data they used to analyze and come to the conclusion that they need agile to to rescue the project. Funny thing is no one comes back and gives me the data, true I do not know if that is just firms who do not have money wanting a a magic pill or some other factor.

How do you measure the code quality of your android project? If you do, did you adjust Jdepoend, Classycle, and JavaNCSS to include the bias of android projects not widely using interface patters but using non-MVC anti-patterns? Letme guess your answer is no and you did not even consider that bias right?

The greatest agile tool and greatest developer tool is not IDE, its not the OS, its not the build tool, it is that collection of human cells between our ears. By using that tool we come up with innovative solutions. Both aspect-oriented-programming and dependency-injection came from minds pondering several problems.

But the good news in measuring agile is that if you run cod metrics reports on your project right now you have, assuming that you are not doing agile, a project baseline to compare similar projects that were using agile in their development. By similar projects I mean similar code line counts not re-doing the same project using agile with the same team as that introduces too many biases that you cannot statistically get rid of in your analysis.


Agile Android Dev with a Vengence

So now I am at this step of integrating/tying everything together in one dashboard. The codeqa reports, the javadoc, the unit tests, emma reports, etc.And I still get the heavy impression that design firms do not know how to do agile android development. Everything from hiring those who do not know how to develop java applications on mobile(they are puzzled over my talks of modified singleton patterns for mobile) to repeating errors in hiring in that it worked so well for finding that outside design firm that we now have to re-start the app dev process and clean up the mess that we will rather repeat the process to find someone who is a conformists not willing to rock the boat as opposed to someone who has to change dev culture to implement agile.

Some of these are well-known firms in Chicago, for example one sounds like Voccal Interactive. Some of them are Chicago start-up incubators that should certainly know better by this period in time. You cannot just wave a magic wand and expect that piling up of technical debt to be paid by a one-hour consultation or even a one day one.

Hopefully, by completing my tool and talking about its use I can persuade more firms to use best practices in android agile development rather than pay lip service.