Meine Reise durch die Bits und Bytes
Mittlerweile habe ich eine funktionsfähige “App” gebastelt. Es ist ein Memory geworden, was zwar von der Spiellogik her korrekt arbeitet, aber sich noch etwas ungelenk bedienen lässt. Tja, dann fehlt auch noch ein wenig das “Drum-herum”.
Das ganze rennt bei mir bisher im Emulator mangels realem Testgerät.
Droid Memory Screenshot
Nach längerer Überlegung gebe ich nun ein erstes Alpha Release meines Programms bekannt. (Zu finden in der Code Collection.) Vom produktiven Einsatz würde ich wohl noch absehen, weil die nötige Reife bzw. Stabilität noch nicht vollständig gegeben ist. Zum Anschauen und herumspielen sollte es erst einmal reichen. Eine initiale Datenbank habe ich beigelegt, da das Programm selbst keine eigenen Datenbanken erzeugen kann. Auch ein kleiner Readme-Text liegt bei.
Ich hoffe, dass Programm gefällt, trotz mancher Macke, die vorhanden sein mag.
In den letzten Tagen habe ich mich wieder um mein Programm gekümmert und vor allem versucht an der Performanceschraube zu drehen. Bei regelmäßigen Profiling-Durchläufen fiel mir auf, dass beim Anzeigen von Bildern, die während der Laufzeit skaliert wurden, der Speicherverbrauch sprunghaft anstieg und sich negativ auf die Reaktionsfähigkeit der graphischen Oberfläche auszuwirken schien.
Ich bin dann zu vorskalierten Thumbnails übergegangen, damit dies nicht überhand nimmt. Über das gesamte Wochenende habe ich mich mit diesem Thema befasst, weil es mir keine Ruhe gelassen hat. Mein Vorgehen ist dieses: existiert zu einem Bild noch kein Thumbnail im entsprechenden Ordner, dann wird das Ausgangsbild skaliert und im Thumbnails-Ordner gespeichert, um dann fortlaufend die verkleinerte Variante zu benutzen. So muss nicht andauernd ein Bild für die Vorschau bzw. für die im Programm verwendete JList skaliert bzw. im Speicher vorgehalten werden.
Trotz dessen ist das Programm, wie das WIP anzeigt work in progress – also noch nicht fertig.
Mein (noch unfertiges) Programm
Per Mail erreichte mich eine Fragestellung, wie man in Java mittels Multipart (MIME) z.B. ein Bild hochladen kann. Das eigentliche Abspeichern des übertragenen Bildes erledigt ein PHP-Skript.
Ok, muss man also das PHP-Skript von Java aus ansprechen und die Daten durchreichen, die man sonst in ein Formular eingetragen hätte, dachte ich mir.
Der Ansatz, der mir geschickt wurde, basiert auf jenem, der sich hier findet. Neben dem eigentlichen Bild sollten noch zwei andere Dinge an das PHP-Skript gesendet werden. Dazu brauchte man eine weiter Zeile a la
wr.write (something)
Dass man dann aber ein weiteres wr.flush () verwenden sollte, kam mir nicht in den Sinn. Die Aktion mündete bei mir in einer nicht endenwollenden Versuchsserie. Alle Versuche blieben erfolglos. Heute dämmerte mir, dass es wohl nicht an den übertragenen Daten liegt, sondern eher daran, wie die Übertragung abläuft.
Damit hatte der Code dann so auszusehen:
DataOutputStream raw = new DataOutputStream(socket.getOutputStream()); OutputStreamWriter wr = new OutputStreamWriter(raw); // ... viel Code dazwischen ... // // HTTP Header : POST Anfrage an das PHP-Skript wr.write(header); // Erster Teil der MIME Daten wr.write(command); wr.flush(); // Uebertragung des Bildes raw.write(theData); raw.flush(); // Ein weiterer Teil der MIME-Daten wr.write (command2); wr.flush(); raw.write("senden".getBytes()); raw.flush(); // Letzter Teil der MIME Uebertragung wr.write("\r\n--myBoundary--\r\n"); wr.flush();
Vielleicht werde ich mir das mal bei Gelegenheit in einer Klasse kapseln, falls ich das irgendwann selbst brauchen sollte.
Nach einer etwas längeren „Sendepause“ von mir, melde ich mich nun zurück. In der Zeit, wo es auf dem Blog etwas ruhiger geworden ist, war ich natürlich nicht untätig. Ich habe mich mal wieder an die Arbeiten zu meiner Datenbank-Anwendung in Java gemacht. Schließlich will ich das Programm auch zur Fertigstellung bringen.
Mittlerweile finde ich, dass ich schon einen Screenshot vorzeigen kann, auch wenn ich noch weit von dem Punkt entfernt bin, an dem ich es veröffentliche. (Ich halte mich da an das Motto: „Das Programm ist fertig, wenn es fertig ist“)
Kunstverwaltung 1.0 Screenshot
Mit den (Programmier-)Jahren habe ich beim Schreiben meiner eigenen Programme stets versucht guten und sauberen Code zu erstellen.
Also versucht mich an Dinge wie
zu halten bzw. Tipps zu berücksichtigen. (Bei mir akutell die Verwendung von Prepared Statements anstatt sich SQL-Statements wild zusammen zu stückeln.)
Wenn ich dann so am Programmieren bin, frage ich mich manchmal: ist das Ganze denn guter Code, so wie ich ihn anstrebe oder würden sich einem erfahrenen Programmierer die Fußnägel hochrollen?
Ein professioneller Programmierer bin ich nun mal nicht, dennoch versuche ich beim Schreiben des eigenen Programms auf gewisse Dinge zu achten.
Wer die JList [1] aus dem Swing-Paket [2] von Java kennt, dem wird mitunter aufgefallen sein, dass diese im ersten Moment nur einfachen Text als Listeneintrag zur Verfügung stellt.
Nun, für ein Programm, an dem ich zur Zeit schreibe, wollte ich allerdings sowas wie eine Vorschau haben, die zugleich die Bilder auflistet.
Mittlerweile habe ich mir was zurecht gebastelt, wovon ich denke, dass es der eine oder andere gebrauchen könnte.
Damit die JList Bilder darstellen kann, war es nötig einen eigenen ListCellRenderer [3] sowie ListModel [4] zu erstellen. Erstgenanntes wird gebraucht, um die Bilder in der Liste anzuzeigen, während anderes die Bilddaten für die Liste verwaltet.
JList mit Bildern
Der Quellcode samt einer kleinen Beispielanwendung findet sich wie immer in der Code Collection und ist wie immer Open Source.
[1] JavaDoc JList
[2] Wikipedia Swing
[3] JavaDoc ListCellRenderer
[4] JavaDoc ListModel
Wie angekündigt, sorge ich nun für eine Anleitung, wie man wxWidgets kompiliert und in einem einfachen Programm verwendet.
Vorbereitung:
wxWidgets Version: 2.18.12
MinGW Version: 3.4.5
MSYS Version: 1.0.11
Netbeans Version: 6.8 mit Plugin für C/C++
wxWidgets 2.18.12 bzw. aktuelles Stable Release als tar.gz herunterladen und in einen beliebigen Ordner mit Schreibrechten für den aktuellen User entpacken.
wxWidgets Bibliotheken kompilieren
Der Einfachheit halber sollte man MinGW im Ganzen – vor allem mit gcc und g++ – installiert haben. Daneben benötigt man die MSYS Umgebung. Beides installiert man, um Fehler zu vermeiden unter C: bzw dem aktuellen Laufwerk mit Windows. Es empfielt sich danach die bin-Verzeichnisse von msys und MinGW in die PATH Umgebungsvariable aufzunehmen.
Configure und make:
Man sollte nun nachdem wxWidgets entpackt ist die MSYS eigene Shell msys.bat (welche man im Installationsordner von msys findet) starten. Dort wechselt man nun in das wxWidgets-Verzeichnis.
cd /C/Users/AUser/wxWidgets-2812
In dem jeweiligen Ordner sollte sich eine Datei mit dem Namen configure befinden. Auf der msys-Shell gibt man zum Vorbereiten der Quellen folgendes ein:
./configure --enable-optimise --enable-static --disable-shared --enable-monolithic
Dann erhält man eine im Code optimierte, statische Bibliothek. Wer anderes konfigurieren möchte erhält mittels ./configure --help Infos zu weiteren Optionen. Ist alles ohne Abbrüche über die Bühne gegangen, so beginnt man die Buildvorgang mit einem einfachen make auf der msys-Shell.
Die Bibliotheken:
Die Bibliotheken liegen innerhalb des lib-Ordners des wxWidgets-Verzeichnis und haben hier die Endung auf .a .
Weiter gehts auf der nächsten Seite:
Continue reading ‘wxWidgets für MinGW’
Das vergangene Wochenende habe ich genutzt um den Einstieg in wxWidgets wagen. Dazu war es erst einmal nötig aus den Quellen die Bibliotheken von wxWidgets zu erstellen. Ich persönlich habe dafür den MinGW in Kombination mit MSYS benutzt. Mit Cygwin sollte es aber auch möglich sein. Das Erstellen war an sich kein Problem, allerdings ein einfacheres wxWidgets-Programm kompilieren brachte einige Schwierigkeiten mit sich. Oft konnte der eingebundene Header trotz gegebener Includeverzeichnisse nicht gefunden werden. War dieses Problem gelöst, tauchten plötzlich Probleme beim Kompilieren des Programms – z.B. dass die Definition von strdup nicht auffindbar sei, um einen Ausschnitt aus den über 100 Fehlern zu geben – auf.
Dass ich da noch alle Haare auf dem Kopf und nicht vor Zorn ausgerissen habe, ist ein Wunder. Schließlich habe ich dann einen aller letzten Versuch gestartet, der unter der Bedingung lief, wenn’s jetzt immer noch nicht nach all den Versuchen funktioniert, dann lasse ich es. Das regt mich zwar auch übel auf, weil ich dann gescheitert bin, aber ich kann mir nicht vorwerfen lassen, dass ich es nicht versucht hätte.
Zum Glück ließ sich mit dem letzten Versuch das Programm erstellen. Damit ich mich bei späteren Ansätzen nicht erneut ärgere, habe ich mir vorsorglich eine Anleitung geschrieben, die ich dann noch hier rauf stellen werde.
Wenn ich in C bzw. C++ unterwegs bin, dann meist im Bereich von Konsolenanwendungen – also Programme, die in einem kleinen, schwarzen Fenster mit weiser Schrift ausgeführt werden. Programme mit bunten Buttons und sonstigen grafischen Komponenten sind bei mir bisher Mangelware.
Mir fehlt in dieser Hinsicht ein Einstiegspunkt, vor allem weil es neben den durch (kommerzielle) IDE’s bereitgestellte GUI Toolkits auch viele eigenständige Pakete. Was Windows angeht, bin ich mir unsicher zwischen MFC [1] und WinForms [2]. Schließlich gibt es noch eine freie, für verschiedene Plattformen verfügbare Alternative namens wxWidgets [3].
In Java hatte sich diese Frage mir nie gestellt, da es schließlich entsprechende Bibliotheken in der Standardbibliothek von Java bereits gibt und man daher nicht nach externen Paketen suchen muss. Drei Wahlmöglichkeiten und ich stehe mittendrin. Ich weiß auch nicht, woran ich eine Entscheidung fest machen soll. Es sollte für den Einstieg nicht zu kompliziert sein.
[1] Wikipedia: Microsoft Foundation Classes
[2] Wikipedia: Windows Forms
[3] wxWidgets Projektseite
