Androide the "gPhone" software stack

There was a lot buzz around when Google launched Android, there mobile platform. A lot of newspapers write a lot of articles about it, but technical insides are really rare. Even on the official android-page it's hard to find a good written architectural overview. Probably the best start to understand how Android works is probably this video from google. If you don't can or want to watch a video there's also, as I think a bit a short, explanation on the google code site.

The architecture view

Let me give you a short overview. Android is basically a layered architecture for mobile phones. At the bottom there's a Linux kernel 2.6 that basically handle the drivers to access the hardware. That's really nothing new there; there are already some phones out there that use Linux as a foundation. The most famous one of the Linux mobile Phones are probably the Nokia Internet Tablet or the OpenMoko.

On the next layer there are c-written libraries that bring some basic stuff to the phone. Although this layer is mainly internet-computer and not phone related (Google PC anyone ;-)). There are libraries to display stuff ("Surface Manger", "Open GL|ES", "SGL", "FreeType"), WebKit to display web pages (the same engine that is used in the iPhone and KDE), a SSL library for secure communication, SQLite to simple store stuff and libc as basic c layer.

Then there's the Android runtime, that’s the layer where a programmer can start building there own application on the top. It consists out of a virtual machine that can execute byte code that’s build out of the "Java Programming Language" and a core API that have a very big similar to sun's java package (in fact Google is using part of Apache Harmony, a open source implementation of the Java class library). Let this be enough for now, we go back to this part later on.



On the application framework is the stuff that makes programming a phone easy with android. There are classes to access resources and creating windows. Some stuff here is still in development, there is no MMS or HSPA support yet.

On the top there are the applications of a phone, they are all written in Java and use exactly the same system, no matter if they are written by Google, the phone company, the network carrier or you.

Java or not to Java

Google always talks and writes about "Java Programming Language" and not Java, why comes that? Well what's running on Dalvik, the virtual machine of android, is not really Java bytcode. You program as every Javaprogram just as usual in Java and compile them to bytecode. After that you need to transform your bytecode with the "dx" tool to a .dex file. What you get is now Dalvik bytecode.

Ok!? Why the hell so complicated? Well there may be a few reasons for that. As you still use Java until just before delivering you App, you can easily use your usual tool chain. Eclipse, JUnit, Cruisecontrol or more exotic stuff - it's all no problem! But why they don't just use Java then, you may ask. Well, for mobile phones you still have not the resources like on a pc. So Dalvik-Bytecode is well optimized for the CPU and hardware you will typically find in a mobile phone. And there's another fact which is no secret: Google don't like to pay license few to Sun. So that's the reason why Google is using the "Java Programming Language" and not "Java". It might be a not too big difference for technical guys, but for the lawyers it definitely is.

Smart decision

After all Android, and therefore also Dalvik looks like a smart idea to me. As Sun tried to run Java with J2ME on every device, Android will never run on today’s low coast phones. You just need some basic CPU power to run it. As J2ME is not really a strong framework, you have a single programming language, but it's up to the vendor which functionality he likes to integrate, every single phone is different. That makes porting J2ME to a real pain. As it looks now, the open handset alliance is putting on some standards on library and functionality that needs to be implemented by every vendor. This will make developing an application for every Android phone easy. As the vendor needs to use the same libraries and framework to develop his own applications it's pretty much "eat your own dogfood" and this will give a little security that Android will be useful.

Android will hopefully be a strong platform until we have enough CPU power on the mobiles to just run some standard operating systems on them. And yes, Dalvik is the better J2ME for me, less compromise and more technical possibilities to the programmer.

Some breaking news: After some rumors, it's public now. Sun Microsystem buys MySQL. Hopefully nothing bad for me as not-coffe-drinker. More on reuters.

Ok, I got it! After a hell lot of work I managed today to get my "Sun Certified Java Programmer". It was just the same like with my lpic, it's really hard if you don't use the topic, you want to certified with,in your every-day-work. SCJP isn't a piece of cake, and after not writing productive Java-Code for more than half a year it was hard to survive in all the Java details they want to know.

Probably the hardest thing was to know if something get a compile- or a runtime error. I think this is also hard to figure out for very-experienced-java-senior-developer™. The other hard thing was to know all the API-Methods. To be honesty you didn't have to learn so many API-Methods, but they test if you you know the Java-Collection-Api quite well. Yeah and that's the point where my missing every-day-use nearly kills me again. And the collection-stuff was also my worst part in the test (got only 60%). And before I forget, you should really know "everthing" about Java 1.5, probably more then the half of my test was somehow related to it.

But on the other end I did quite well in the multithreading-part. Don't get me wrong, it's not easy! But after surviving marines-like "Parallel- und Netzwerkprogrammieren" (the parallelprogramming-course at my school) nothing about java-threads can anymore surprise me.

For preparation I used the "SCJP Sun Certified Programmer for Java 5 Study Guide" from Kathy Sierra and Berth Bates. The book did a quite well job. It's very well written and sometimes it even makes me laugh (not a bad thing for a tech-book). From time to time the description of some topics (specially when you knew them allready) get a bit longish. But the book describes everything you need to know for the exams and the short self test at the end of the chapter helps to find your weakness. Bye the way, the selftests are harder then the exame itself. The book-cd is a bit a crap, the not very nice looking test program (actually it looks nearly as horrible as the original testcenter interface) runs only on windows. Not the way to go for learning a OS-independent language.

And now 10 things I didn't knew about Java, even I thought I knew everything when I left university (or I have allready forgotten since then, I'm getting old):

• In the case statement you don't have to fully reference your enum (you don't need the type)
• In the For-Each Loop you can not define the loop-variable befor the loop.
• You can use covariant return type, but only in Java 5
• The method with var-args is allways chosen last
• You can not widen and autobox arguments in one step
• You can do "if(a = b)" (yes, with only one equals sign!) As long as both types are boolean.
• binarySearch has the most C-like interface you will find in the Java-API.
• If you have a "private final" method you can "override" it in the subclass. (Well, not really override, but because the private method do not exist in the subclass you can redefine it)
• You can instantiate an inner class from the outside with "new Outer().new Inner();" (Ok, this is one I allready knew. But is still the most weird construct in Java and I think if you see this in really life it might mostly refer to a design flaw.)
• For numberobjects with small numbers (usually bellow 127) java compare the number when you do "==", for bigger numbers java use the object reference. (Do Sun-Engineers smoke Java?)

You asking about score?! It was much better than it has to be, but for sure it wasn't a 99% certificate. But for somebody how drinks no coffee...

This make my ROFL: " Beim Blacksheep-Verlag soeben erschienen und von hm-hm 'entdeckt'".



Sorry, couldn't resist to blog this one and didn't found a picture in better quality. There's allready exames preparation time over at switzerland?

[via Prog1-Wiki]

Für alle die noch im Lernendspurt für "Software Engineering 3" sind habe ich noch einen kleinen Lesetipp. Heiko Maass erklärt in seiner Artikelserie "Generics Gala" die ganze Java 1.5 Generics Geschichte nochmals ausführlich. Ich denke dass diese bei Unklarheiten weiterhilft. Vielen Dank auch nochmals an dieser Stelle.

Vergessen sollte man auch den Artikel "J2SE 5.0 in a Nutshell" nicht. Der Artikel erklärt relativ kurz was in Java 1.5 neu eingeführt wurde und ist auf dem Skripte-Server ein wenig versteckt. (Ich glaube nicht das Java 6.0 gross Prüfungsstoff sein wird. Für alle dies trotzdem noch lernen wollen liegen ein paar Folien auf dem Server oder ein wenig detailiertere Infos ebenfalls im javablog unter "Mustang Mäeutik").

Christian, der Geschäftsführer von BSI, sucht 10 Softwareentwickler im Bereich J2EE, Eclipse, SOA. Und das per Brief auf einem Plakat an bester Lage im Zürcher Hauptbahnhof (hier als PDF). Das nenne ich Aufschwung im richtigen Moment ;-)

Einmal mehr habe ich diese Woche eine schmerzhafte Lektion in Java programmieren erhalten. Während ich anfangs Semester noch das Gefühl hatte alle Funktionen in Java zu kennen, entdecke ich in letzter Zeit immer wieder neues. So habe ich erst diese Woche mitbekommen das Java variable Parameterlisten, wie sie auch in Ruby oder C# möglich sind, kennt. Das heisst das als letztes Argument der Parmeterliste "type... name" angegeben werden kann. Das sieht dann so aus:

int summe(int ...summanden) {

  int summe = 0;

  for(int i: summanden)

  summe = summe + i;

  return summe;

}

Der Aufruf der Methode kann dann wie folgt aussehen (mit beliebig vielen int in der Aufrufsliste):

 System.out.println(summe(1,2,3,4,5));

Meiner Meinung nach "Syntactical Sugar" denn es nicht wirklich braucht, da es dafür relativ wenig sinnvolle Anwendungen gibt und der "work-around" mit einem Array nicht viel komplizierter ist.

Wer noch mehr interessantes, gebloggtes über Java sucht wird auf javablog.ch fündig. Dieser Blogtipp kommt von bloggerli und die Quelle des Beispielcodes ist ein Artikel im Java Magazin.

Mit Reflection unter Java kann man viele lustige Dinge anstellen. Versteht zwar keiner, macht aber nichts! Wer's nicht versteht muss es lernen.

Mein heutiges Resultat ist eine generische toString-Methode die sowohl den Klassennahmen als auch alle über Getter ereichbaren Werte ausgibt. Sehr praktisch für Debug-Output.

public String toString(){
	Class c = this.getClass();
	StringBuffer buf = new StringBuffer(c.getName()+ ":\n");
	
	Method m[] = c.getDeclaredMethods();
	for (Method method : m) {
		if(method.getName().startsWith("get") && method.getParameterTypes().length == 0){
			try {
				buf.append("- "+method.getName().substring(3)+": "+method.invoke(this, (Object[])null) +"\n");
			} catch (Exception e) {}
		}
	}
		
	return buf.toString();
}

In unserer Eclipse CDT Semesterarbeit geht es zügig voran. Emanuel schreibt eine Erweiterung für den Abstract Syntax Tree um Kommentare zu speichern. Kommentare sind im AST meist nicht nötig, für Refactorings ist es aber entscheiden das Kommentare nicht einfach auf der Strecke bleiben oder gar verloren gehen.

Um die Kommentare zu Speichern hat Emanuel den Knoten mit der Kommentarinformationen „dekoriert“ und dazu das Decoratorpattern verwendet. Dazu hat er das Interface des entsprechende Knotens implementiert und für die Funktionen des ursprünglichen Knotens einfach einen Wrapper geschrieben der auf die Methoden des „echten“ Knoten zugreift. Dies ist das übliche Vorgehen bei einer solchen Problemstellung. Das kann bei vielen Knoten schnell in einem grossen Programmieraufwand enden. Da wir uns entschieden die Kommentare nur in zwei Knoten zu speichern hielt sich der Aufwand dazu in Grenzen. Trotzdem bemerkten wir auch in diesem Fall dass das Ganze auch sehr fehleranfällig ist. In unserem Dekorator hatte sich trotz kleines Umfanges bereits ein Fehler versteckt, den wir zum Glück beim durchsehen des Codes noch fanden.

Der Vorschlag unseres Professors war nun das Problem generischer mit Reflection zu lösen wie das auch in Ruby oder Smalltalk gehen soll. Eine andere Möglichkeit währe es wohl die Klassen statisch mit einem Script automatisch zu erzeugen. Wir haben letzte Woche nun versucht den Lösungsvorschlag unseres Professors zu implementieren. Dazu verwendeten wir die „dynamic proxies“-Funktionalität von Java wie sie seit Java 1.3 vorhanden ist und unter anderem auch für Java RMI verwendet wird.

Zuerst müssen wir nun eine Factory erstellen welche das Proxy-Objekt erstellt, da dies über einen gewöhnlichen Konstruktor nicht mehr möglich ist. Der Factory übergeben wir den Orginal Knoten der dekoriert werden soll. Das sieht in unserem Beispiel dann so aus:

public static Object invocationFactory(CPPASTNode node) {
	CPPASTCommentedInvocationHandler handler = new CPPASTCommentedInvocationHandler(
				node);

	Class[] interfaces = getAllInterfaces(node);

	Object o = Proxy.newProxyInstance(IASTCommentDecorator.class
			.getClassLoader(), interfaces, handler);
		
	return o;
}

Zuerst wird der Handler erzeugt der die Zugriffe die auf das Proxy-Objekt erfolgen handhabt. Auf die Funktionalität des Handlers gehe ich später in diesem Text ein. Mit der Methode „getAllInterfaces“ werden danach alle Interfaces des Knoten zurückgegeben und mit dem Interface das die Funktionalität zum Speichern von Knoten bereitstellt ergänzt. Danach wird ein Proxy-Objekt („Proxy.newProxyInstance“) für diese Elemente mit diesen Interfaces und dem Handler erstellt.

private static Class[] getAllInterfaces(CPPASTNode node) {
	Class[] interfaces = node.getClass().getInterfaces();
	Class[] allInterfaces = new Class[interfaces.length + 1];

	for (int i = 0; i < interfaces.length; ++i) {
		allInterfaces[i] = interfaces[i];
	}

	allInterfaces[allInterfaces.length - 1] = IASTCommentDecorator.class;
	return allInterfaces;
} 

Der Handler ist dann ein relativ einfaches Konstrukt welches das InvocationHandler-Interface implementiert. Welches einzig und allein die invoke Methode verlangt.

public class CPPASTCommentedInvocationHandler implements InvocationHandler 

Im Konstruktor wird der Orginalknoten gespeichert und ein Objekt der Klasse die das Speichern der Kommentare vornimmt angelegt. Die Speicherfunktionalität hätte auch im Handler selbst implementiert werden können, eine eigene Klasse löst aber die Kopplung und erhöht die Wiederverwendbarkeit des Codes.

In der invoke Methode landen nun alle Aufrufe an das Proxy-Objekt. Zuerst werden nun hier die Methoden equals und acceppt abgefangen da sie sowohl mit dem Knoten als auch mit dem Kommentar-Speicher interagieren. und deshalb direkt im Handler behandelt werden.

public Object invoke(Object proxy, Method method, Object[] args)
		throws Throwable {
	
	if (method.getName().equals("equals") && args.length == 1
			&& args[0].getClass().equals(Object.class)) {

		return equalsMethodeCall(args[0]);
	} else if (method.getName().equals("accept") && args.length == 1
		&& ASTVisitor.class.isInstance(args[0]) ){

		return acceptMethodeCall((ASTVisitor) args[0]);
	} else {
		return standardClassCalls(method, args);
	}
}

In der Methode „standardClassCalls“ werden nun die übrigen Methodenaufrufe an die beiden Klassen „verteilt“. Alle Methoden die vom IASTCommentDecorator ausgehen werden an das Objekt commentExt, welches die Speicherfunktionen für die Kommentare (also das Interface IASTCommentDecorator) implementiert. Alle anderen Methoden wurden ja von den Interface des konkreten Knotens implementiert und werden deshalb auch an diesen weitergeleitet.

private Object standardClassCalls(Method method, Object[] args)
		throws IllegalAccessException, InvocationTargetException {
	if (method.getDeclaringClass().equals(IASTCommentDecorator.class)) {
		return method.invoke(commentExt, args);
	} else {
		return method.invoke(node, args);
	}
}

Die Implementation auf diese Weise ist sehr flexibel und elegant, auch wenn sie ein wenig schwer zu verstehen ist. Leider kann das Proxy-Objekt nur in die entsprechende Interface, und nicht in eine Knotenklasse, gecastet werden. Da in Eclipse CDT, wie vermutlich in den meisten grösseren Projekten, nicht konsequent gegen Interfaces programmiert würde funktioniert dieser Lösungsansatz bei uns leider nicht.

Meine Links auf del.icio.us haben es bereits angekündigt. Emanuel und ich haben mit unserer nächsten Semesterarbeit begonnen. Diesmal versuchen wir für und mit Peter Sommerlad "CDT AST writability for Eclipse" zu implementieren. Nun sind wir bereits in der zweiten Semester- und Projektwoche.

Diese Projekt hat Emanuel und mir definitiv gezeigt das wir noch nicht alles über Java wissen. Der Code ist kompliziert, weist viele Eigenarten auf (die teilweise die c/c++ Vergangenheit der Entwickler nicht verheimlichen können) und bietet auch aus der Javasicht einige Neuheiten. Mit folgendem Code hätte ich zu Beginn dieser Woche noch nichts anfangen könne.

public static IViewPart openDOMASTView(IEditorPart editor){
   ... 
   ( (DOMAST)tempView).setContentProvider( (DOMAST)tempView).new 
ViewContentProvider(((CEditor)editor).getInputFile()));
   ...
}

Ja genau der Code instanziert eine innere Klasse aus einem statischen Kontext. Aber so was lernt man wohl in keiner Vorlesung (oder vergisst es schneller wieder als man es gehört hat).

Inzwischen sehen ich aber bereits wieder Licht. Das Codechaos wird langsam durchschaubar, obwohl beim CDT wohl die Grundregel gilt, dass keine Funktion nur einmal existiert und Codeduplizierung zur Tagesordnung zu gehören scheint. Heute bin ich auch über den ersten Fehler im Code gestolpert und habe einen Patch dafür erstellt. Wie es mit dem Projekt weitergeht wird wohl auf meinem Blog oder in unserem Projekt-Wiki stehen.