Android Application Build Using Gradle

Who says you cannot use Groovy Gradle as an Android Application Build script?:

EMMA Instructions

AS you may have figured out by now thee are missing pieces to the EMMA instructions that developers have posted to the Android mailing lists. I will be publishing my own set of instructions soon. In the mean time, the file coverage_targets.xml in android-repo/development/testrunner has to be changed ot include the android application you are copying to the samples directory.

TDD Hardships on Andorid

You would think that implementing Agile-TDD at the build system level for Android Application Development would b the hard part. Not that is not challenging. The hard part seems to get companies and firms to believe that if its implemented right and executed that you have white box QA testing using  this build system framework without the full costs of full blown QA department. Other mobile platforms such as J2ME in which we do not have a full emulator at the OS level and higher which results in  major differences between the J2ME emulator and what appears on the device in several crucial areas. With Android he can be accepted that 95% to 98% of functions/features on the emulator work as advertised exactly the same way on the device because the emulator not only emulates java but the full connection and integration with the device OS and we have device hardware profiles. This means that similar to the iPhone emulator that with the right build/testing system the power is put back in the one developer hands again significantly reducing cots.

I see not only Android OEMs such as Motorola but other firms developing Android applications view my linkedin profile daily. It is not much to throw a small contract my way so that I can finish this Agile-TDD build system development. Am I asking too much for a small Android development gig/contract? I mean due to this use of Agile-TTD rates can be in terms of $50 to $80 per hour due to the time savings in the developmental process. If you are a firm take the last highest cost Android Application development project that was completed. Now, imagine only paying 50% to 75% of that costs.

AndCooper Progress-August

In past lives I have used DSL scripting languages to decrease complexities of builds. If this was a groovy/grails project your woudl set-up a projectName.environment.groovy script that would hold a static list of environment settings and use that to configure the build and use a environmentTarget flag to choose between whether  you had the debug, testing, or production build environment. You could  get away with that in a groovy/grails project because the one viewing and using the build system should know some groovy, that is not  the case with the AndCoooper build system where we do not want the user of the system to resort to having to know such things.

But, using DSL could decrease the amount of build script lines from somewhere around 2500 to something more manageable and flexible.Let me show you an example from  AndCooper ANT version:

this is the release target

<target name="release" depends="dex, package-resources">
        <apkbuilder
                outfolder="${out-folder}"
                basename="${ant.project.name}"
                signed="false"
                verbose="false">
            <file path="${intermediate-dex}" />
            <sourcefolder path="${source-folder}" />
            <jarfolder path="${external-libs-folder}" />
            <nativefolder path="${native-libs-folder}" />
        </apkbuilder>
        <echo>All generated packages need to be signed with jarsigner before they are published.</echo>
    </target>

this is the debug target

<target name="debug" depends="dex, package-resources">
        <apkbuilder
                outfolder="${out-folder}"
                basename="${ant.project.name}"
                signed="true"
                verbose="false">
            <file path="${intermediate-dex}" />
            <sourcefolder path="${source-folder}" />
            <jarfolder path="${external-libs-folder}" />
            <nativefolder path="${native-libs-folder}" />
        </apkbuilder>
    </target>

If I was using a DSL language as the build script language, such as groovy, I could just over ride the compile target with new a behaviour and thus not have to fully retype a new full release target and rename it as debug. What I could do instead is based on the setting of the envriomentTag of debug, testing, or production change the behaviours of the targets during the set up phase of said targets using:

init.doFirst {
	logger.info(Logging.LIFECYCLE, 'INITIALIZING Gradle Project')

	// check if a profile property is set :
	if (!hasProperty('targetEnvironment')) {
		targetEnvironment = DEFAULT_TARGET_ENV
	}
	if (targetEnvironment == debug) {
        //over ride targets with new behaviours here
        }
	logger.info(Logging.LIFECYCLE, 'target environment is: ' + targetEnvironment)
}

What I could  do is keep the environmentTag setting of debug, testing, production concept and actually use something like Gradle. With Gradle one could set 3 external program run settings in yoru IDE for debug, testing, and production as most modern IDE’s have it set up so that that the location of the project folder can be passed as a parameter  to allow such launching as Gradle when launched takes that parameter and launches the default build.gradle file in the project folder.

Than why not extend further as this is the IDE launch parameters(Eclipse):

-f -p ${workspace_loc}${container_path} -b ${resource_name} ${string_prompt}

which would give be the same as at the command line in project directory:

gradle targetName -p enivronmentTag=debug

we extend that to be:

gradle targetName -p enivronmetnTag=debug -p machineSerialNumber=5567

what does that give us? Hold on to your seat or hat, a full virtual device lab without paying no third party for that honour! Hold on I am not done yet! EMMA support will probably not include being able to run EclEMMA plugin in Eclipse for another 8 months.

gradle targetName -p environmentTag=emma

and combine that with setting ANDROID-PRODUCTION_OUT as system variable than read that in in build.gradle to set the source emulator location and thsu we can laucnh the source emulator to execute the EMMA tests.

Yes, Google developing certain Android Application such as Latitude was kind of pissing me off. Let us make it an equal playing filed a little bit. I cannot attack the Google marketing power but I can certainly out engineer Google in one specific area!

EMMA Progress

I think I made some progress in  the proper EMMA set-up so that I can get Android development to have them EMMA enabled:

Thus, I am creating a sample project and a  Google Knol to detail the steps.

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.

MotodevStudio for Android on Linux

The Linux version of MotoDev Studio for Android is out. Screenshot

:

Customizing MotoDEVStudio

One of my complaints has been that the underlying platform. Eclipse 3.4, uses ANT 1.0 which has a major bug. Unzip this into your plugins folder and take out the ANT 1.0 plugin folder in your MotoDEvVStudio for Android install. Now when you do soem tasks like declare the task library for JDepend it will be able to pick up the configuration file whereas with ANT 1.7 it was not due to a bug.

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.

How To Start Android Emulator using ANT

To start the Android Emulator and proceed to the next ant task, this should work:

<target name="start.emulator">
<parallel>
			<daemons>
				<exec executable="${emulator}">
					<arg value="-avd"/>
					<arg value="${my-avd}"/>
			    </exec>
			</daemons>
		</parallel>

	</target>

It should work. Now this is the emulator in the released SDK as when you build the sdk/emulator from source its creating
its own AVD and configuration file entry to use that avd. But for just the released SDK/emulator it should work.