AndCooper Progress-August

Posted: August 23, 2009 in AndCooper, Android, Java, Mobile
Tags: , ,

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!

Reblog this post [with Zemanta]
Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s