Archive for the ‘AndCooper’ Category

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

BrainDead Eclipse 3.4.2

Posted: July 23, 2009 in AndCooper, Android, Java, Mobile

Who had the birght idea that leaving ANT 1.7.0 instead of updating to the proper ANT 1.7.1 bug fix was good idea for the release of Eclipse 3.4.2? Suffice it to say that you cannot properly load resources in taskdef under ANT 1.7/0 hence the updeate release of ANT 1.7.1. Now that  those bugs are cleared by moving to using Eclipse 3.5 can finish the rest of testing and final checks to get AndCooper 0.1 for Android Development  out the door.

T-Mobile G1 Google Android
Image by netzkobold via Flickr

Finishing up hacks and testing those with AndCooper 0.1 The problem with the Android SDK is it  is evolving so we have things that change form release to release and so I have had to ot hacks to get around those changing items such as the value of the target value in default.properties changing syntax and etc.

The whole idea here is that say Google and OHA pulbish a new relase of Android SDk called 2.0 on Firday.  Than I should as a developer be able to take the AndCooper Build Toool and with no changes or avery few adjustments be able to build projects right-away using the AndCooper tool. I as an Android Developer should not hav to wait for the p;roject lead of AndCooper to adjust and ix things, it should alrady work with the new SDK release.

It is a very different approach than say an OEM, say Motorola,  would take on building an Android Application Development ANT-based build tool as my target audience is both beginning Android  Developers and Advanced Andorid Application Developers. It is importna ot get this right as we will see Four SDK releases per year. Through today I expect to be posting some videos of final AndCooper 0.1 testing to apologize for the delays in the 0.1 release.

Reblog this post [with Zemanta]

I am on the laste final stesp of adding VPP(Velocity Template Preprocessing for WebView html preprocessing and etc) and JavaPP(Java Preprocessing to handle same code base different SDK targets) and the final testing. One of the issues has been getting  to work right with non-Eclispe IDEs in the same easy manner.

Why two preprocessors? VPP is known as a template engine preprocessor, for those who are experienced in other mobile platforms like JavaMe it was a 1st generation preprocessing solution both for text preprocessing and java preprocessing Although, we do not use it for Java Preprocessing(interferes with IDE incremental builds and etc) we do ue it for template duties in producing class file templates fof classes we are starting with in a project in addition to the html stuff for webview.  JavaPP is than used a full Java preprocessing tool in that it recognizes the Java preprocessing commands in the comments and processes them base don trggers defined in ant properties file adn thus we can use the same code base with Android SDK 1.5, 1.6, 1.7, 2.0, and etc.

Release of AndCooper 0.1 should be shortly tonight or  Wed morning.

Reblog this post [with Zemanta]

I will be testing AndCooper this weekend for its 0.1 release. Thus, three project; one to test regular java builds, one to test library builds, and one to test webviw app builds. The library one is easy, a project to build an object pool library. The regular java build one is an experiment using a process.org library and OpenGL. For the webivew side wil just use an application help page example.

The using Android SDK to bootstrap seems to work, AndCooper build file gets auto-generate to the project folder when the android create project is executed.

Image representing Android as depicted in Crun...
Image via CrunchBase

One of the problems in developing an Android Application Build system based on ANT is how to get the Android SDK to sort of, oh I do not know, let’s say generate it. I found a way that will have the Android SDK generate the AndCooper build scripts through the android create project command. With 2 little file installs and one small folder isnstall full AndCooper set-up with the Android SDK doing the work of placing it in the right location, SWEET!

Now that is the ultimate in Android SDK customization having it deploy your own customized ANT Build system, no? How? Well, the command android create project command cannot transfer the extra files your build customization desires so we just assume that our developer puts that set of files in a supplied-folder called AndCooper_Extras in their home directory as that is accessible via the ANT ${env.HOME} variable. That means as far as the Android SDK machinery is concerned we only have two files to replace to enable it, neat!

Reblog this post [with Zemanta]
Image representing Knol as depicted in CrunchBase
Image via CrunchBase

Emma Builds of the present SDK and the bleeding edge SDK will be downloadable today from the AndCoper project page by end of today. Because they are only for my distro an article with instructions so that you can build one for your distro will be posted under my profile at the Google Knol site.

For those on Ubuntu 9.0.4 that cannot wait, my change to Qemu, sockets.c, line 32 is:


#  define __USE_GNU 
#  include <netdb.h>

The define must be before the include netdb.h. It was either that or the change makefile for qemu trick outlined here. At this point I am not real sure which might be more correct as I have not touched C in years. if I had to choose, the change above since it somewhat less obtrusive in some aspects rather than the makefile change.

Reblog this post [with Zemanta]

AndCooper Instructions

Posted: July 3, 2009 in AndCooper, Android, Mobile
Tags: ,

I am finalizing the AndCooper Instructions:

andcooper_instructions

and testing for the 0.1 alpha release and thus the release will be over the weekend. It is not the experts in ANY that I am worried about. Its making it use-able for those who are not experts in Apache ANT.

Its the little details such as an set of instructions, having an image an music set of sub-folders in the assets folder that have double use both in Android WebView application development and regular Android Application development.

Reblog this post [with Zemanta]

Android PMD ruleset

Posted: June 30, 2009 in AndCooper, Android, Java, Mobile
Tags: ,
T-Mobile's G1
Image by neo.wave via Flickr

Xavier Le Vourch   had made a post describing how to modify the PMD ruleset to be more Android specific. My AndCooper-modified-pmd with his ruleset enclosed(jar download). For AndCooper 0.2 the mdoified PMD will have some more rules specific to Android. You will refer to the ruleset as andcooper.xml in your pmd ant task and you need the ruleset in the jar hence the modified PMD jar download. Sorry for the delay in gettting this out.

Reblog this post [with Zemanta]


This is what the obfuscation prepaation ANT script code looks like:

<property name="assets-css-obfuscated" value="${assets-folder}/css-obfuscated"></property>
<property name="assets-js-obfuscated" value="${assets-folder}/js-obfuscated"></property>
<property name="assets-js-libs-compressed" value="${assets-folder}/js-libs-compressed"></property>
<property name="project-assets-css-libs" value="${basedir}/project-assets/css-libs"></property>
<property name="project-assets-js-libs-compressed" value="${basedir}/project-assets/js-libs-compressed"></property>
<property name="project-assets-temp-concat" value="${basedir}/project-assets/temp-concat"></property>
 <!--  The assumption is that during testing/dev we want the non obfuscated js/css files to 
 be real but the obfuscated oen sot be empty and reverse that for the 
 production/release. Thus prep step prepares an obfuscated empty file
 concat of the js-libs and the css files.  we assume
 that we plaqce js-libs-compressed libs in the folder
 -->
 <!-- Concat js-libs-compressed into one js-libs-3rdparty file-->
 <concat destfile="${project-assets-temp-concat}/js-compressed-3rdparty.js" force="no">
 <fileset dir="${project-assets-js-libs-compressed}" includes="**/*.js"></fileset>
 </concat>
 <!-- Move js lib file to assets -->
 <copy file="${project-assets-temp-concat}/js-compressed-3rdparty.js" todir="${assets-js-libs-compressed}"></copy>
 <!-- Produce an empty css-obfuscated file and a js-obfuscated file only empty for testing/dev -->
<property name="css-obfuscated-file-name" value="css-obfuscated-file-name.css"></property>
<property name="js-obfuscated-file-name" value="js-obfuscated-file-name.js"></property>
 <concat destfile="${project-assets-temp-concat}/${css-obfuscated-file-name}" force="no">
 <fileset dir="${project-assets-temp-concat}" includes="${css-obfuscated-file-name}"></fileset>
 </concat>
 <copy file="${project-assets-temp-concat}/${css-obfuscated-file-name}" todir="${assets-css-obfuscated}"></copy>
 <concat destfile="${project-assets-temp-concat}/${js-obfuscated-file-name}" force="no">
 <fileset dir="${project-assets-temp-concat}" includes="${js-obfuscated-file-name}"></fileset>
 </concat>
 <copy file="${project-assets-temp-concat}/${js-obfuscated-file-name}" todir="${assets-js-obfuscated}"></copy>
 <delete includeemptydirs="true">
 <fileset dir="${project-assets-temp-concat}"></fileset>
 </delete>

Than during the release.produciton target before the apkbuilder task you make empty css-not-obfuscated.css and js-not-obfuscate.js files and thus your import wil always be:

import css-non-obfuscated.css

import css-bofuscated.css

import js-non-obfuscate.js

import js-0obfuscated.js

import js-compressed-3rdparty.js

Notice that you will always have the import js 3rdparty compressed lib.  Because if you import an empty css or js file nothing happens it will always work right for both testing and production release because of the switching of which one is the empty file. Is not that a cool trick? And you never have to go through the html and change the damn imports every time.  Sure I could have threw together an ANT build script like everyone else but I thought it might be valuable to actually have an Android Build script that supports WebVuiew application development.

Is this trick used in the PhoneGap or QuickConnect or Rhomobile build scripts? Suprisingly, no in fact. This is the quality that needs  to go into a WebView application development book. However, I can not develop the book unless I have side Android App Development contracts. Now, some more details to finish than AndCooper Build Tool 0.1 release.

Reblog this post [with Zemanta]