Android TDD Build Tool

This is not the tool itself but the Gradle build GUI showing the tool itself.  Because the gradle build lifecycle is tdd based we get that as a foundation and I am just integrating some tools on top of the gradle android plugin such as code analysis tools robolectric, etc.

How much dev time are we saving?  The typical round trip of compiling the parent project, dx-ing, and installing and compiling the instrumented test and than dx-ing it and installing it can be anywhere from a minute for small project to several minutes per a large project and in the TDD process you would  be doing that perhaps a 100 times on typical coding day. That is over 1 to 2 hours in development time savings. That is not counting the savings of not having to fully mock test an android project and thus it is a substantial amount of development time saved.

To those firms in Chicago looking for Android Developers, I am only 43 minutes from downtown Chicago.

Advertisement

Teaching Android

Image via Wikipedia

With Packt Publishing attempting to recruit me as an android 3.0 development book author and an android training opportunity position opening up in downtown Chicago, I once again have the opportunity to think about how android development should be taught in class form and book form.

Its not that there are not stellar resources already out there such as Mark Murphy’s, etc.  Its how do you reach the maximum audience about the power of this new mobile platform through developing code in java/C++ and js/html/css.

First, mobile programming is different. Some of the differences is that its a casual application that does not operate or run-all-the-time. Its security context is around both user authentication within the mobile operator system and the google user system. Its not big screens like the server or desktop.

There are also other differences as well in that not every member of the audience is java programmer as many web programmers are switching to android not just the PhoneGap applications but also the more heavy duty in CPU cycles applications such as games, etc. My respectful disagreement with Markana Inc. was that there is enough basic java patterns in android java programming itself that one could use the android device to teach java.

In android java we use a modified mobile definition of singleton from the javaME area. That theory of why we use it is still valid java programming technique. The android mobile platform uses callbacks. the callback pattern is of course acting as a program pointer, something in java we do not have at the moment. The same pattern and theory are found in complex java systems on the enterprise side.

There are also such things as teaching the development process such as debugging, unit-testing, BDD and TDD, and of course best practices in dealing OEM-device-differentiation(press calls it android fragmentation). Than we have the subject of adding a native library to extend android to be able to use in an application.

Hopefully I get an opportunity to explore these subjects shortly.

AndCooperANT 0.1.1.1 Release

There is now a download of the AndCooperANT Android Java Application build tool. Its still alpha with the most tested area being the build.xml script. Of course if you find errors report them in the issues section.

Some of the docs are still in flux at the moment let me know in an issue/bug report of the instructions are unclear.

The Philosophy of AndCooperANT

If you visit most android developer forums you find android developers from all areas of development. Some are web developers, some are MS.NET developers, some are java developers, some are JavaEE developers, some are CS students, etc.

Among those many groups there is not a common thread of using a continuous integration build server.  With one exception, if you count the IDE as incremental compiler as the continuous integration server. and why not its small enough to run on a laptop with the android emulator and still have room to run a dev environment dash-board using jetty.

Thus, my philosophy is integrate pmd, checkstyle, classycle, jdepend, javaNCSS, doxygen for native c, jGrouseDoc for javadocs of javascript in assets, and cppcheck reports into one small build system package that is easy to set-up and use along with your favorite IDE for android development.

With some ease of usability in that you should only have four or less files to change per project amounting to less than 6 properties to change per project. Maybe even go further over this next week-end and code a groovy installer that auto-installs everything in a new project with no-mess no-fuss.

Not set as default incremental builder as we want developers to feel that they can run that one target to compile and doc the whole project whenever they want or they can set the whole thing up in their IDE as an incremental builder.

Not all polished all at once but I will get rest of the tools integrated this week and a full common look/feel to the reports that are generated so I can use it my own projects and see where rest of the improvements need to be made.  I did find how to do customizable headers and footers using CSS without having to change or insert new html  elements in the html generated in each report.

If you have not downloaded the corrected add-proguard-release.xml that was corrected from the android dev blog Sept 21st post than visit my github account link at the bottom of this blog and click on AndCooperANT and download that file at the project root folder. Of course no one paid attention to my bug submission yet, maybe I needed to have a bug title that stated Sept21st Dev post wrong?

But, oh well..towards weekend two more alpha and usable releases of AndCooperAnt with me starting to upload zipped copies to github for you to download.

Android Java Patterns and DI

Image via Wikipedia

The debate of using Dependency Injection  in Android has always been half-assed in a way. First, some background.

On Mobile initialization is the bottleneck as opposed to Enterprise where the application is started once so we do not care about initialization times. In dependency injection there is an initialization setup penalty.

People have argued that that setup penalty means avoid DI. One counter has been use singletons-by-choice(a former NextStep pattern..yes its one of the coding patterns in iphone dev). However, the use of synchronized in such a pattern means you have the same penalty of initialization that you have if using DI and only occurs for the classes you have designated singleton-by-choice.

Does a singleton-element enum have the same initialization penalty? Its probably greater as we are warned as Android Developers not use enum in our SQLite ORM coding as its very slow.

My thinking is that since Android 2.2 onward has a JIT that we no longer have these concerns and now have a choice of DI, singleton-by-choice, singleton-element enum, and even can implement a real MVC framework. Will the start-times matter for those pre-Android 2.2non-JIT devices?  I do not think those devices will be around that much as a market percentage in the next 12 to 18 months. I think we can use l the patterns rather than quibble and claim oen pattern is the miracle worker as opposed to having all those patterns in one’s toolbox.

The only aspect where the choice becomes important is in testing and unlike several months ago we now have some mock frameworks becoming available for android such as android-mock which evens the playing field as you could use all the above patterns.

Logging the Android Way

In Android Java Applications we use a logging system to record log events including errors, debugging, etc.
Log levels are:

Verbose 2
Debug 3
Info 4
Warn 5
Error 6
Assert 7

The default log level set by the Android OS is 4 and above. Its the reverse for the levels of detail
in that verbose is the most detailed log level you can use. And debug is compield but stripped out
at runtime and obvoously you do not want Verbose triggered in your producition application.

At bare minimum to get debug and verbose to show you have to set it, which you can do via:

$adb setprops log.tag. DEBUG

Quick question, if you do this what log levels show in logcat? The log level you have sset and
everything above that log level shows in logcat. Thus if you want everything to show you set Verbose log level.

Okay so where does it show up? The Android OS by default logs to logcat four ‘log streams’;

Main
Radio
Events
System

Logs of levels Verbose through Assert are sent to the Main Log stream, in other words all application logging.

Thus, how do we prevent verbose and debug from being triggered in the produciton application but have it
triggered in the application we are debugging without changing any code?

You wrap the log calls with isLogable, for example in log wrapper class:

public static void debug(final Class myClass, final String tag,
final String msg) {
if (Log.isLoggable(tag, Log.DEBUG)) {
Log.d(tag, myClass.getSimpleName() + “:” + msg);
}
}

In this case if setprops is not used to set either Verbose or debug than log debug never gets executed
because android OS defaults to INFO log level and above if not set via setprops. if you use log calls
wrapped by isLoggable than you never have to worry about removing log calls to Debug or Verbose
as the isLoggable if statements ensure its not executed if not set to Loggable.

One of the best coding practices for Android Java Application Development is code wrapper classes that
make your code development easier by saving steps. Cdoing a log wrapper class should one of your
first steps in best coding practices.

Tab Highlights Custom

I still have to fix some drawable selectors but its working:

Okay, now for the secret sauce:

        /**
         * grabs tab indicator drawables to fix
         */
        for (int i = 0; i < tabs.getChildCount(); i++) {
            View vv = tabs.getChildAt(i);
            vv.setBackgroundDrawable(getResources().getDrawable(R.drawable.tab_indicator));
          }
        /**
         * grabs tabWidget drawables to fix
         */
        for (int i =0; i < tabWidget.getChildCount(); i++) {
        	View vvv = tabWidget.getChildAt(i);
        	vvv.setBackgroundDrawable(getResources().getDrawable(R.drawable.tab_bottom_left_right));
        }
    }

That sits in my onCreate method. the only bad things is it will break when the APi changes.

Application JavaDoc

There are some javadoc errors that I see when developers attempt to produce javadoc for an Android application project. One, not specifying the android.jar as a classpath parameter and the second is not specifying what Androdi SDK version in th e footer some place:

<target name="javadoc">
	
		<javadoc sourcepathref="javadoc.source" destdir="javadocs" overview="src/overview.html" classpath="${sdk-android-jar}" private="true" windowtitle="${taglets.windowtitle}" additionalparam="">
					<!-- Use a nice documentation title -->
					   <doctitle>
					     AndroidAppANTBuild&lt;/br&gt;
					     API Specification
					   </doctitle>
					     	 <!-- Create a header that contains the taglets logo -->
					     	   <!-- Note the use of the {@docRoot} tag to link to the logo -->
					     	   <header>
					     	     &lt;img
					     	       src="{@docRoot}/resources/logo.png" 
					     	       width="88" height="40" border="0"
					     	     &gt;
					     	   </header>
					<!-- Same for the footer -->
					   <footer>
					     &lt;img 
					       src="{@docRoot}/resources/logo.png" 
					       width="88" height="40"
					     &gt;
					   </footer>
					   <!-- Include a timestamp at the bottom of the docu generated -->
					   <!-- Note the use of ${timestamp} which was created by the -->
					   <!-- <tstamp> task at the start of this target -->
					   <bottom>
					     &lt;p align="right"&gt;
					       &lt;font class="NavBarFont1" size="-1"&gt;
					   	     Android SDK Verion ${sdk.version}&lt;br&gt;
					         ANdroidAppANTBuild&lt;br&gt;
					         API Spec&lt;br&gt;
					         ${TSTAMP} ${DSTAMP}
					       &lt;/font&gt;
					     &lt;/p&gt;
					   </bottom>
			
			</javadoc>
</target>

Remember, there is no separate javadoc for the SDK online so you really can not use a link parameter and thus identifying the SDK version in footer helps.

TouchScreen Testing 101

So you this nice android application but you need  to test the UI using some touch screen touch events in which you the developer supply the x and y coords in you test class. Right now there is not a TouchUtils method for this set of use cases. The method I came up with probably looks like this:

/**
*
* @param test
* @param view
* @param touchX in DIPs
* @param touchY in DIPs
*/
static void touchPoint(InstrumentationTestCase test, View view, float touchX, float touchY, Activity activity ) {

Instrumentation inst = test.getInstrumentation();
float screenDensity;
float screenWidthPx;
float screenHeightPx;
float touchTempX;
float touchTempY;
long downTime = SystemClock.uptimeMillis();
long eventTime = SystemClock.uptimeMillis();

/**
* 1 dip = 1 pixel thus
* dip x density = pixels
*
* density of 1 equals
* 160 dpi 240×320 baseline display or 1.5″x2″
*/
DisplayMetrics dm = new DisplayMetrics();
activity.getWindowManager().getDefaultDisplay().getMetrics(dm);
screenDensity = dm.density;
screenHeightPx = dm.heightPixels;
screenWidthPx = dm.widthPixels;

if (touchX * screenDensity <= screenWidthPx){ touchTempX = touchX * screenDensity; }else{ touchTempX = 1; } if (touchY * screenDensity <= screenHeightPx) { touchTempY = touchY *screenDensity; }else{ touchTempY = 1; } // touch down MotionEvent event = MotionEvent.obtain(downTime, eventTime, MotionEvent.ACTION_DOWN, touchTempX, touchTempY, 0); inst.sendPointerSync(event); inst.waitForIdleSync(); // touch up MotionEvent eventUp = MotionEvent.obtain(downTime, eventTime, MotionEvent.ACTION_UP, touchTempX, touchTempY, 0); inst.sendPointerSync(eventUp); inst.waitForIdleSync(); } [/sourcecode] It should work. notice that it defaults to coords of 1,1 if you the developer goof up on your x and y cordinate inputs as its expected that you input your x and Y coordinates in terms of DIP not pixels so that your unit tests will always work no mater what the screen size.

A trace trick

This is form one he many hard-working Google Android engineers. a trace file is only so big, about 5 megabytes. Thus, while it might be big enough to record traces in one method its nto big enough to contain all traces of a program. So we set a variable to use in the file-name and incremented it:

 // start tracing to "/sdcard/calc.trace"
   Int b = a+1;
   String aString = Integer.toString(b);
    Debug.startMethodTracing(aString);
    // ...
    // stop tracing
    Debug.stopMethodTracing();

Very simple and effective. If you want to get fancy y0u can prefix a prefix like the word trace.