Archive for July, 2009

OPhone Emulator Video

Posted: July 31, 2009 in Uncategorized

Just a little video of OPhone emulator which is based on Android 1.0:

You only have to rename your Google Android emulator.cfg file, found in /home/.android, the first tiem this emulator is run and after that its not required and can be renamed back to emulator.cfg so you stil have the Google Andorid emulator functionalties on the other Android SDK you have intalled. The web Widget JIL is implmented as a one AndroidApp Player which means sooner or later apps run out of memory if  you have too many  JIL web widgets taking up memory through the JIL Web Widget player.

Advertisements

OPhone SDK/emulator

Posted: July 30, 2009 in Android, Java, Mobile
Tags: ,

Damn-it I like this new UI from China Mobile:

Screenshot-OPhone Emulator (5554)-1

You have to try this UI out. So much  easier to go from screen to screen. Oh it is based on Andoird 1.0, that means you have disable emualtor.cfg from you current SDK to get it to launch and you do that by renaming the file.

2nd Android SDK-OPhone

Posted: July 30, 2009 in Android, Java, Mobile
Tags: , ,

China Mobile has pushed out their OPhone SDK which is based on Android OS with JIL web widgets.

Reblog this post [with Zemanta]

Usually, when developing a java jar or NDK *so shared library you have two projects the main one where you do the apk and the other one where you develop the library. The targets I came up with:

<target name="javalib.compile" depends="clean">
		<javac encoding="ascii" target="1.5" debug="true" extdirs=""
			           destdir="${out-classes}"
			           bootclasspathref="android.target.classpath">
			        <src path="${source-folder}" />
			        <!-- do not need genfolder -->
			        <classpath>
			           <fileset dir="${external-libs-folder}" includes="*.jar"/>
			           <pathelement path="${main-out-classes}"/>
			       </classpath>
			     </javac>
		<!-- We package or jar in the same target -->
		<jar destfile="${dist}/javalib/${projectlib.java.projectname}.jar"
		     basedir="$&#91;out-classes}"/>
	
	</target>
	
	<target name="javalib.move" depends="javalib.compile">
		<!-- run compile javalib -->
		<exec executable="ant" failonerror="true">
				<arg value="-f" />
			    <arg value="${projectlib.java.projectlocation}/android_build.xml" />
				 <arg value="javalib.compile"/>
		</exec>
	    <!-- move javalib to main project-->
		<copy file="${projectlib.java.projectlocation}/dist/javalib/${projectlib.java.projectname}.jar" todir="${basedir}/libs" />
	</target>
	
	<target name="javalib.incremental" depends="javalib.move, compile">
	</target>

This way I can point the IDE java builder to use this javalib.incremental target and thus have both projects incrementally compiled off of one target and thus have the javalib jar as input to my main project. I would imagine that you could set-up the NDK stuff the same way except you would be driving a target that drives an *.mk script to compile the *.so and move it before the main project compile task taking the *.so as input in the libs folder of main project.

Donut Brings 3D fixes!

Posted: July 28, 2009 in Android, Java, Mobile

If you wondering why there are no 3D games for Android pay attnetion to this OpenGL thread onthe android developers list.  Just because we have OEM sign ups for Android devices does not mean we are out-of-the-woods yet as far as being competitive with other mobile platforms. The patch has beeen reviewed.

From what I can gatherthe fixes ae in Donut and may make it to the next SDK releaase, this fall! 3D game OpenGl support fixed, folks!

As you know if you read my posts on Android SDK customization that I customize the Android SDK to supply better ANT scripts upon executing the create project command. Here is what I mean by broke, mobile development is different in that we have more one-person-shops than say in enterprise development. Thus, having default build scripts to  handle most user cases in android development becomes more of a priority for getting developer s to the platform as these developers will  not become Apache ANT experts just to use the platform.

And the Android SDK set-up is such that one cannot easily make changes ot the android_rules.xml file to fix the ANT support becasue that would break other things. Sure, I could  suggest that we intentionally break the build.template in order to get better build scripts in the Android SDk but that fix/enhancement will never get approval not because it gives more stuff to application developers but it is  how android_rules.xml and build.template in the SDK were originally setup as far with other components having dependencies on those files.

The most obvious potential supporter of this movement towards better ANT support for Android Developers  would be Motorola as the current release of MotoDveStudio for Android  shows. I am not sure how to crack that ‘wall’ at this time as I run into too many ‘oh Motorola is so big we do not know where to ask your question’ response from any Motorola employee I ask(You should have seen how long it took to get Moto HQ staff to change from going my old blog to this one, shakes head..sheesh!)

So what does an example user case look like indicating broken ANT support? The continued  every new Android Developer getting Proguard settings in their ANT task wrong, perhaps? The question now appears on the developers lists more than once a week. That is just one example, as the questiosn about ANT have gone up from only one per month when Google started the android Dev lists to several per week.

According to Fadden(Proguard), here is how obfuscation task should look:

<target name="-obfuscate" depends="compile.incremental">
			<!-- In versions prior to 4.4 Peephole optimization was turned off
			     however in 4.4beta is now on and thus we
			     have turn off with the command of
			     -optimizations !code/simplification/cast
			     per Fadden also use
			     -allowaccessmodification -->
<proguard>
			  -libraryjars ${android.jar}: ${external-libs-folder}
			  -injars      ${out-classes-location}
			  -outjars     ${obfuscate-location}/classes.min.jar
			  -keep public class * extends android.app.Activity
			  -optimizations !code/simplification/cast
			  -allowaccessmodification
			</proguard>

		</target>

Notice that there are now two new settings and that is updated per Fadden’s notes from this week. That is just a sample of the areas of ANT support where the Android developers do not want to become ANT experts or build engineer experts but they need to know or have a basic default set of build scripts that is specific to Android development.

If we do not tackle this now, when 9 million Android devices hit the market it will ‘bite’ the whole development community in the ass.

Reblog this post [with Zemanta]
Google Android: T-Mobile G1
Image by marketingfacts via Flickr

I will point you to the real hacker that imlementd Multi-Touch on Android 1.0, Luke Hucthison. Article with the video is here. That being said due to the Multi-Touch patent do not post to Google operated Android lists asking about multi-touch as the Goolge engineers cannot discuss anything involving that patent. If you want to now about Multi-Touch, read Luke’s articles.

Reblog this post [with Zemanta]

Obfuscate using Andorid SDK

Posted: July 27, 2009 in Android, Java, Mobile
Tags:
Image representing Android as depicted in Crun...
Image via CrunchBase

ANT task for obfuscating using Proguard in Android development:

<target name="-obfuscate" depends="compile.incremental">
			<!-- In versin prior to 4.4 Peephole optimization was turned off
			     however in 4.4beta is now on and thus we
			     have turn off with the command of
			     -optimizations !code/simplification/cast -->
<proguard>
			  -libraryjars ${android.jar}: ${external-libs-folder}
			  -injars      ${out-classes-location}
			  -outjars     ${obfuscate-location}/classes.min.jar
			  -keep public class * extends android.app.Activity
			  -optimizations !code/simplification/cast
			</proguard>

		</target>

Notice the extra -optimizations command. That is required to turn off a new proguard feature to make it work.

Reblog this post [with Zemanta]
Alternate logo.
Image via Wikipedia

As you know that the only way you get EMMA code coverage currently is to use an error prone approach of changing stuff to get your application temproarily in an Android  build. I would  rather have less error prone approach. The whole diea is to have some test coverage indicatos hgowever due to the way Andorid evolves we know we need nto strive for full 100% code test coverage.

Thus, here is the bright idea under the tests targets still run apiviz doclet on the normal src code to be included say in javadocs/nontests and than run both the src and tests/src under the taglets collection taglet. Than you can mark all the classes and methods a certain way in javadoc style until they have test classes implemented. It is not a very nice and pretty report, but at least you could read the javadoc to gather what areas of code were not tested yet because the taglets collection taglet is tagging your javadoc tagging of code not yet with a test class or methods in certain graphical manner.

Taglets Collection already has a taglet  for the javadco tag; @testcases and we can make that more graphical by changing the taglets collection stylesheets. So it is a metter  of picking a tag in taglets ot represent code not yet hacing testcases written for. Nice and simple.

Reblog this post [with Zemanta]
Content (from a database), and "presentat...
Image via Wikipedia

Because I develop Android Applications that often use both Java and Webview I have been searching for a template engine that could work equally with java source, html, and  even sql. Something easy as:

package com.${project.company}.${project.name}.domain;
/*$if{project.framework != project.name}*/
import com.${project.company}.${project.framework}.domain.BaseEntity;
/*$end*/
public class ${entity.name} extends BaseEntity {
  /*$for{field : entity.fields}*/
  private ${field.type} ${field.name};

  public ${field.type} get${field.name.capitalize}() {
    return ${field.name};
  }

  public void set${field.name.capitalize}(${field.type} ${field.name}) {
    this.${field.name} = ${field.name};
  }
  /*$end*/
}

or html-wise:

<html>
    <body>
        <!--$if{users != null && users.size > 0}-->
<table border="1">
            <!--$for{user : users}-->
<tr>
<td><!--$output{for.index + 1}-->1<!--$end--></td>
<td><!--$output{user.name}-->james<!--$end--></td>
<td><!--$output{user.coins}-->2.00<!--$end--></td>
</tr>
<!--$end--></table>
<!--$end-->
    </body>
</html>

Notice because the commands are enclosed by comments will work in all IDEs. How to target to automate? Use local.properties as we already assign package name, application name, activity name, and sdk target when we create the project. This could be expanded to say mapview=true, webview=true, and etc in local.properties than your build system would auto-generate at the init target execution generation of those starting class files using the template engine.

The examples shown above are form the template engine called Common Template Engine. Nice ANT task to run right from ANT and very smal syntax and command set to learn unlike either Velocity or Freemarker.

Reblog this post [with Zemanta]