Tigraine

Daniel Hoelbling-Inzko talks about programming

Making a whole libgdx screne2d group touchable

When placing a Group with child-controls inside a libgdx stage is is apparently impossible for the whole group to get hit-detection (click-events and touch events), instead only the children in the container will fire touch and click events.

This is something I was struggling with quite some time until I looked at the libgdx source code and found this in Actor.java:

public Actor hit (float x, float y, boolean touchable) {
    if (touchable && this.touchable != Touchable.enabled) return null;
    return x >= 0 && x < width && y >= 0 && y < height ? this : null;
}

That's how hit-detection is done in libgdx and that's also the reason why no click-events inside the groups bounds where detected. Not so much the code above, because that one works fine. But if you look at the code for scene2d.ui.Group you notice that it is overriding the hit-detection to delegate all calls to it's children, never checking for itself.

So the simple solution here was to just subclass the Group and instead of calling super.hit I brought back the hit-detection from Actor.

Hope this helps.

Filed under libgdx, java, inputs

Installing Eclipse on Mac OSX

Most Mac applications come bundled as a .app package that you simply have to drag&drop into your Applications for them to show up in Launchpad and Alfred. Or, if an application is a bit more complex you usually get a .dmg file that then installs like any normal MSI package you are used to from windows.

Not Eclipse for OSX. The Eclipse project maintainers do provide a OSX binary, but it doesn't look like most OSX .app packages in that the extracted binaries are a folder that then contains a .app.

If you only copy over the .app file you'll not be able to start Eclipse as it's just a starter script and the real Eclipse is living in the extracted Zip. I used to just start eclipse wherever I unpacked it, but apparently the right way to install it is to simply copy the whole extracted eclipse folder over to your Applications. Even though the .app is not in /Applications directly OSX picks it up and it shows up in Launchpad.

Filed under programmierung, java

Never assume! Stack iterators in Java

I spent almost 2 hours of debugging Java code yesterday due to one assumption that proved fatally wrong: I assumed a Stack, by definition a LIFO data structure would iterate over it’s elements from the top of the stack to the bottom.

So inserting 1, 2, 3 the resulting order when iterating through the stack should be 3, 2, 1.

Well, at least that’s what .NET does. Java is different. Look at the following Java code:

Stack<Integer> stack = new Stack<Integer>();
stack.push(1);
stack.push(2);
stack.push(3);

for(Integer i : stack) { System.out.println(i); }

And this C#:

var stack = new Stack<int>();
stack.Push(1);
stack.Push(2);
stack.Push(3);

foreach (var i in stack) {     Console.WriteLine(i); }

Well, they look exactly the same, but Java will return 1,2,3 while C# will honor the Stack’s special semantics and return 3,2,1. Great stuff isn’t it?

The workaround was quite simple, yet it had cost me 2 hours of my life trying to hunt a bug in my code, never thinking the bug could lie in a simple foreach iteration through the stack..

Lesson learned: Never assume you know anything about data structure semantics unless you have checked that your assumptions are indeed true. Implementations differ and sometimes this will bite you.

Oh and did I mention that the way Java does it is simply wrong?

Filed under net, programmierung, java

C# Talk

Now and then I delve through some Java tutorials or Java applications for my studies. And everytime I do so I immediately lack the getter/setter language features of C#.

To make myself clear (to non-C# Developers). Java has either Public or Private properties, but no way to add validation Logic etc to those. It is usually considered bad coding technique to expose instance variables outside of the class so almost everything has to be accessed through functions. So to expose a integer variable called State you would have to create something similar to this:

get_set_Java 

It works and once you're used to it you will create setter/getter methods in your sleep. But, when pulling up your IntelliSense (ok, you don't have that in Java, but you know what I mean) on that class you will be somewhat overwhelmed by get/set functions :).

So, how did C# handle this? They borrowed a bit from Delphi and C# and created properties with get/set blocks (nothing new). So our code from above would look like:

get_set_C

The great thing: Intellisense gets easier, you have something clearly marked as property not as function (that's used to access a property). Usability for your API has just increased :).

But, despite the awesomeness of this function (already in the .NET Framework since 1.0) in .NET 3.5 they managed to improve this feature a bit. How? Imagine all those cases where you don't have any validator logic on your properties, you just want a simple public field in your class. In older Frameworks you'd have to create get/set Blocks for this Field although you don't want any logic there (exposing Instance-Variables is stupid no matter how you do it).

So, 3.5 Introduced this:

get_set_35

Great, we came down to 1 line of code, and what happened? .NET creates the private instance-variable automatically and handles the simple get/set stuff for us. When we decide we need validation or something in the get/set blocks we can just come back and expand those blocks without having to change any code outside the class (it was a get/set property all the time)

Interessanter Ansatz f&uuml;r ein Server-Protokoll

Ich glaube mir ist aus Versehen was interessantes gelungen.

Im Rechnernetze Kurs an der Uni war von uns gefragt ein eigenes Protokoll für einen Socket Server unter Java zu entwerfen.

Im Grunde wollten man wohl ein relativ simples HTTP ähnliches Protokoll mit GET, POST und LIST von uns. Ich musste aber natürlich über das Ziel hinwegballern.

Rausgekommen ist ein IMAP ähnlicher Socket-Server der nicht nur für jedes Socket einen Thread öffnet sondern auch für jeden Command einen weiteren startet um nie zu blockieren. Und auch wenn das jetzt ziemlich brutal klingt, der tiefere Sinn dahinter war der dass man dadurch Befehle aneinanderreihen kann und das im Server sehr simpel über Thread.join() gelöst wird.

Spezielles zum Konzept und der Paket Syntax gibts unter more.

Java Source Code of Packet Spec

Sämtliche Befehle werden mit einem Token prefixed (wie in IMAP) und dieser Token wird vom ClientHandler (der eigene Thread für jeden Client) in einer Hashtable als Key angelegt während der zu launchende Thread (CommandExecution) die Value ist. Existiert der Key bereits in der Hashtable so wird der alte Thread durch den gerade neuen ersetzt und der neue macht Thread.join() auf den alten. Dadurch wird der neue erst ausgeführt wenn der alte Befehl abgearbeitet ist, also dessen run() Methode durch ist. Der Token diehnt auch dazu dass der Client die Response vom Server zuordnen kann (wie in IMAP).

Was auf jeden Fall noch verändert werden muss bevor man damit irgendwas bauen kann ist dass alles auf Threadpools umgebaut werden muss (Das andauernde Threads starten frisst enorm Ressourcen). Außerdem ist der Server momentan sehr verwundbar gegen DoS Attacken.

Ich werde versuchen bis nächste Woche mal den Java Code soweit aufzubereiten dass ich ihn ohne mir Spott und Hohn einzuhandeln hier unter der GPL herzeigen kann.

I hate Java

Gut dass ich mir sicher sein kann das das nicht wirklich viele Leute lesen, sonst müsste ich wohl einen Flame-War allein wegen der Überschrift fürchten, ganz zu schweigen von dem was noch kommt.

Aber zurück zum Thema. Gute Vorsätze fürs Semester und so wollte heute erstmalig umgesetzt werden und ich hab mich an die Rechnernetze Aufgabe rangemacht. Die Sache fing simpel an, Eclipse runterladen und installieren, und los gehts. Zwei vorgefertigte Klassen implementieren und jeweils eine Read und Write Methode erstellen die die Klasse auf die Festplatte als Datei schreiben würde.

Bisher eigentlich ganz simpel, und eigentlich sollte es auch so bleiben dachte ich. Löblicherweise wurde sogar ein Link zu einem DataStream Tutorial gegeben und nach einigem herumgesuche hab ich es sogar geschafft (unter Zuhilfenahme der Javadoc) ein halbwegs funktionierendes Programm zusammenzuzimmern.

Nun, warum hasse ich also Java? Ein 30 Zeilen Programm hat mich fast 2 Stunden Arbeit gekostet. Herumprobieren mit dem Code, herumspielen mit der IDE, Debugger testen (Guter Tipp: Exception.printStackTrace() ist dein bester Freund!) Und das beste: Ich bin nicht fertig und habe noch 3 Punkte am Aufgabenblatt vor mir.

Denn: Nachdem der erste Teil der Aufgabe simpel war (Ein Objekt das nicht Serializable ist auf die Platte zu schreiben) scheitere ich wohl an der zweiten Aufgabenstellung. Nämlich ein Collection Objekt in eine File zu schreiben.

An und für sich auch simpel, ich habe nur keinerlei Lust den gesamten Stream.writeUTF Mist den ich schon für das einzelne Objekt geschriebne habe nochmal in der Collection Klasse erneut zu schreiben mit irgendwelchen armen Count variablen etc. Eklige Sache.

Nun, eigentlich kann Java garnichts dafür, unter .NET wäre die Sache ähnlich verzwickt, nur dass ich mich da mit der Sprache soviel sicherer fühle dass das ganze bis zu dem aktuellen Punkt wohl nur 10 Minuten gedauert hätte.

Übrigens, sagte ich schon dass ich das neue Eclipse ziemlich gut finde? Vor allem das Word-Hopping :). Mit CRTL+Pfeiltaste kommt man innerhalb eines Wortes anhand des Camel Casings weiter. Also bis zum nächsten großgeschriebenen Wort (genial wenn alle Variablen z.B. strInputParam2 etc heißen)

Filed under coding, java, java, rechnernetze, studium

My Photography business

Projects

dynamic css for .NET

Archives

more