Noch so ein "Fuscher-Weg" wäre es, dein 2-Dim. Array in ein 1-Dim. Array zu übertragen. Dieses kannst du dann einem Intent übergeben und dann wieder zurück transformieren in ein 2-Dim. Array. Ist bestimmt nicht die sauberste Lösung, aber es funktioniert 
lg joensen
Hallo,
Das mit den Screenshots wäre sicherlich die einfacherer Alternative... falls du aber doch ein bisschen mehr basteln möchtest habe ich hier mal etwas gefunden:
http://stackoverflow.com/questions/1784786/mathml-and-java .
lg joensen
Also ich habe selber mal probiert die libs zu importieren und bei mir meckert Eclipse sofort? Wo kommen diese also bei dir her? Hast du deinem Projekt irgendwelche external JARs zugefügt worauf du Zugreifen möchtest?
lg joensen
Zu dem wäre es interessant zu wissen, um was für eine App es sich Handelt? Gerade wenn sie z.B auf die Hardware (Kamera etc) zugreift kann das unter umständen zu Problemen führen bei unterschiedlichen Geräten. Ein weiterer Punkt ist der, das du bei der Entwicklung der App ja eine minSDKVersion und eine maxSDKVersion festlegen kannst. Wie hast du dort die Werte gewählt?
Auch was das Layout einer App angeht treten häufig Probleme auf besonders im Bezug auf die Größe, da die Bildschirmauflösung von Gerät zu Gerät unterschiedlich sein kann...
Das waren nur mal ein paar Gründe wieso weshalb warum...
PS: Und wenn alles nichts Hilft, dann lad dein Freund doch einfach mal zu dir nach Hause ein und veranstalte mit ihm eine kleine Debug-Party
lg joensen
Hallo,
eine weiter Möglichkeit dein "Wunsch-String" zu casten wäre diese:
String s="334,33"
float f= Float.valueOf(s);PS: Keine Ahnung welche Methode effizienter ist grad 
lg joensen
Danke Titus für deine Antwort.
Mit der ständig neuen Berechnung von
N_SLICE1 * N_FLIP
hab ich auch schon dran gedacht und geändert:
final int w1=N_SLICE1 * N_FLIP / 2;
final int w2=N_SLICE1 * N_FLIP;Diese nutze ich dann in den loops... hat aber nicht wirklich was gebracht leider.
Zudem habe ich die ständigen Aufrufe von getPruning und setPruning nun vermieden indem ich sie per Hand quasi "inline" programmiert habe (war das ne arbeit... 
).
Das hat auch schon etwas gebracht. Ohne Optimierung dauerte die Generierung der Tabellen 560 sekunden (nur beim ersten mal). Mittlerweile bin ich durch die oben genannten
Optimierungen bei 418 sekunden. Als noch Android 2.2 auf meinem SGS rannte dauerte es allerding nur zwischen 60-90 sekunden und das ohne die genannten Optimierungen...
Und bezüglich deiner Frage was die Schleife machen soll: Sie soll ledeglich die einzelnen Array-Elemente mit -1 initialisieren mehr nicht.
Solche Apps gibt es in unterschiedlichen Formen. Ich habe dies als Bachelorarbeit gemacht in Verbindung mit einem Lego-Mindstorms Aufbau. Mein SGS liest mit der Kamera den Würfel ein und berechnet die Lösung und steht dabei ständig via Bluetooth in Verbindung mit dem Lego-Mindstorms-Roboter, welcher die Züge letztendlich dann ausführt.
Die App kann aber auch im stand-alone Betrieb benutzt werden. Beim Start wird halt geschaut ob eine Bluetooth Verbindung zu den Targets hergestellt werden kann, und wenn das nicht der Fall is kann man trotzdem den Würfel scannen und dann halt per hand die Lösung am Würfel anwenden.
hier mal ein Plakat was ich damals für das Kolloq angefertigt habe.
[Blockierte Grafik: http://img204.imageshack.us/img204/3171/kolloqposterverlustfrei.jpg]
Uploaded with ImageShack.us
lg joensen
Hallo alle zusammen,
Ich habe folgendes Problem. Habe mein SGS von 2.2 auf 2.3.3 geupdated. An sich läuft das auch echt gut. Nur mein Programm ist an einer Stelle im Code erheblich langsamer geworden und ich würde gerne wissen warum?
Zunächst zu meinem Programm. Es ist ein Rubiks Cube Solver der mit Hilfe der integr. Kamera den Würfel einliest und die Farben automatisch erkennt und dem entsprechend eine Lösung berechnet. Die Berechnung einer Lösung basiert auf dem Two-Phase Algorithmus (siehe dazu http://kociemba.org/cube.htm ). Hierbei werden zu Anfang bestimmte Move- und Pruning tables generiert und genau da liegt das Problem. Da sind zwar grob gesagt sehr rechenaufwendige Operationen und Loops drin aber das war bei der Version 2.2 ja nicht anders. Und am meisten macht den 2.3.3 zu schaffen getter und setter Methoden welche in den Loops sehr häufig aufgerufen werden.
Um es anhand von Code vll etwas deutlich zu machen hier ein kleiner Ausschnitt:
// ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
// Pruning table for the flip of the edges and the position (not permutation) of the UD-slice edges in phase1
// The pruning table entries give a lower estimation for the number of moves to reach the H-subgroup.
static byte[] Slice_Flip_Prun = new byte[N_SLICE1 * N_FLIP / 2];
static {
for (int i = 0; i < N_SLICE1 * N_FLIP / 2; i++)
Slice_Flip_Prun[i] = -1;
int depth = 0;
setPruning(Slice_Flip_Prun, 0, (byte) 0);
int done = 1;
int newSlice=0;
int newFlip=0;
while (done != N_SLICE1 * N_FLIP) {
for (int i = 0; i < N_SLICE1 * N_FLIP; i++) {
int flip = i / N_SLICE1, slice = i % N_SLICE1;
if (getPruning(Slice_Flip_Prun, i) == depth) {
for (int j = 0; j < 18; j++) {
newSlice = FRtoBR_Move[slice * 24][j] / 24;
newFlip = flipMove[flip][j];
if (getPruning(Slice_Flip_Prun, N_SLICE1 * newFlip + newSlice) == 0x0f) {
setPruning(Slice_Flip_Prun, N_SLICE1 * newFlip + newSlice, (byte) (depth + 1));
done++;
}
}
}
}
depth++;
}
Log.d("CoordCube","(#4) Slice_Flip_Prun");
// ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
// Set pruning value in table. Two values are stored in one byte.
static void setPruning(byte[] table, int index, byte value) {
if ((index & 1) == 0)
table[index / 2] &= 0xf0 | value;
else
table[index / 2] &= 0x0f | (value << 4);
}
// ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
// Extract pruning value
static byte getPruning(byte[] table, int index) {
if ((index & 1) == 0)
return (byte) (table[index / 2] & 0x0f);
else
return (byte) ((table[index / 2] & 0xf0) >>> 4);
}Dies ist der Ausschnitt und genau da ist mein 2.3.3 fast 10 mal langsamer als 2.2. Weiß vielleicht jemand warum das so ist? Und wie ich das beheben kann?
Ich finde es nämlich recht komisch, da Gingerbread ja hochgelobt wird vonwegen es sei noch schneller und neuer optimierter GarbageCollector und so weiter...
Vielen Dank und lg joensen
Hallo,
Du hast die Möglichkeit die Bildschirmauflösung zu ermitteln:
Display display = getWindowManager().getDefaultDisplay();
int screenHeight = display.getHeight();
int screenWidth = display.getWidth();Danach kannst du dann entsprechend eine Abfrage machen und die entsprechnde Layout.xml wählen:
//Beispiel
if(screenHeight==y && screenWidth== x){
setContentView(R.layout.layout_1);
}else if(...){
setContentView(R.layout.layout_2);
}
//.... usw.Hoffe das hilft dir.
lg joensen
Hallo,
ich denke du meinst so etwas wie Kantendetektion? Ich habe so etwas auch schonmal gemacht, allerdings bei einem Rubiks Cube solver.
Ein bekanntes Verfahren wäre der Canny-Algorithmus (besteht aus mehreren Verarbeitungsschritten bzw. Algorithmen). -> http://de.wikipedia.org/wiki/Canny-Algorithmus .
Der Ablauf ist im groben etwa so:
- Farbbild in Grauwertbild übertragen
- Grauwertbild glätten mit Falt-Matrix welche die Normalverteilung annähert (beseitigt Bildrauschen usw.)
- Mit den sog. Sobeloperatoren die Gradientenbilder ermitteln in X- und Y Richtung (Du erhältst zwei Bilder)
- Gradientenbild X und Y zusammenführen.
Hoffe das bringt dich weiter. Sonst einfach anschreiben.
lg joensen
Hallo,
Ich glaube dein Problem ist, dass du ledeglich ein Objekt "Size" der Klasse Rect() erzeugst, dieses allerdings nirgends setzt bzw. definierst.
Daher kann bei size.width() und size.heigth() nix gescheites herauskommen.
Vielleicht müsstest du vorher die Größe von size setzen mit:
size.set(left, top, right, bottom);Nachdem setzen müsstest du auch die entsprechnden Werte für die Höhe und Breite bekommen.
Hoffe ich konnte dir helfen.
lg joensen