Beiträge von Marco Feltmann

Naja, links und oben schwarz markieren was gezogen werden soll (also vermutlich links gar nix und oben alles)
rechts und unten schwarz markieren was so bleiben soll (also unten die Breite des Icons und rechts die Höhe des Icons - oder gleich die gesamte Höhe)

Eigentlich nicht schwer und beispielsweise auch mit Photoshop umsetzbar.

Ich würde es mal abziehen, den adb killen, es wieder anstecken und noch einmal versuchen.
Irgendwie ist der adb eine Diva, die gern mal den Dienst verweigert...

+hm+ Das sieht übel aus.

Gemäß StackOverflow funktioniert Fragment in Fragment nicht.
Zumindest nicht via XML Layout. Und da fragen sich einige Leute wirklich, warum so wenig für Android entwickelt wird...

Warum das zu so einem Käse führt, wer weiß. 'Behaves undocumented' bedeutet offenbar genau das.

Sehr schöne Idee, sehr gute Umsetzung und Fehler sind mir auch keine aufgefallen.
Sound wäre noch nett.

Alles in Allem find ich das sehr gut gelungen.
Lediglich das Rumzucken von Coldy (also seine Bewegung beim Drag'n'Drop) finde ich verwirrend und bin da ganz matthias' Meinung.

Ich ging in der Tat davon aus, dass sie den sichtbaren Bildschirmbereich 'View' nennen und wusste nicht, dass sie es als 'Camera' bezeichnen.
Denn was ich da sehe ist ja nicht die Kamera, sondern das, was die Kamera sieht.

Anyways, in dem Fall stimmt es natürlich.

Warum sollte man, auch bei der AndEngine, von der Kameraauflösung auf das Display schließen?
Das ist doch, pardon, hirnrissig.

Nutzt du die Support Library?
Vermutlich hast du im XML an Zeile #5 ein Fragment eingetragen. Das wird dann nach android.app.fragment aufgelöst, was auf API 10 zu Problemen führt.

Ich konnte dieses Problem nur umgehen, indem ich das gesamte Layout im Code erstellt habe.
Im konkreten Fall habe ich einen ViewPager mit der id 'pager_container' angelegt. In der onCreateView des Fragments lade ich dann das Layout und packe das View mit der entsprechenden ID als Hauptview, welcher ich dann die weiteren Fragmente unterjubel.

Nur dürfte es dann beim ersten Mal schon nicht laufen...

Ich glaub, ich habs.

Zitat

07-01 21:33:07.315: E/AndroidRuntime(10120): Caused by: java.lang.IllegalArgumentException: Binary XML file line #5: Duplicate id 0x7f090022, tag null, or parent id 0x0 with another fragment for de.so.myteach.PupilDetailMainInfoFragment

Das ist zumindest der einzige Punkt, den du noch anpassen kannst.
Nämlich via

getSupportFragmentManager().beginTransaction().replace(R.id.pupil_detail_container, PupilDetail, PupilDetail.getClass().getCanonicalName()).commit();

Also einfach irgend einen String (ich bevorzuge den Klassennamen) als Tag mitgeben, dann sollte das laufen.

BTW: ein onDestroy() manuell aufrufen ist schon so ziemlich der falscheste Fehler, den man machen kann.

Das ist seltsam, denn die von dir beschriebene Sortierung ist eine 1a Zeichenkettensortierung.
Hast du die Tabelle zu Testzwecken mal weggeschmissen und neu erstellt?

Kann es sein, dass dein Score-Feld ein Textfeld ist?

Dann wäre "2" nämlich größer als "12" und "12" größer als "111"...

In solchen Fällen hasse ich ja die Methodenüberladung von Java. +grummel+

Zitat von tomkicker

Java

db.query(DATABASE_TABLE, new String[] { KEY_ID, KEY_NAME, KEY_SCORE },
				null, null, null, null, KEY_SCORE);

Jetzt muss man erst mal ne halbe Stunde rumüberlegen, ob das die richtige Methode ist...

query (String table, String[] columns, String selection, String[] selectionArgs, String groupBy, String having, String orderBy)

Ja, sieht richtig aus.

Was meinst du mit 'ASC und DESC bring auch nix'?

Nur 'KEY_SCORE' sagt ja erst mal noch nichts aus, da die Richtung fehlt.
KEY_SCORE + " ASC" wäre vielleicht besser.

Den Dreisatz zu Ende denken kann helfen.
(CAMERA_WIDTH? Warum auch immer CAMERA_WIDTH und nicht getWindowManager().getDefaultDisplay().getSize(new PointF())... Von der Kameragröße auf's Display schließen zu lassen halte ich für unklug.)

Linker Rand ist gleich 0 + Spritepixel nach rechts.
Ergo ist rechter Rand gleich Breite - Spritepixel.

Noch einmal: ich sehe für ID 2 und 8 keine Zahlen. Weder die ID noch die Position.
Deshalb kann ich keinerlei Annahmen darüber treffen, ob sie richtig sind oder nicht.
Gemäß der gaußschen Normalverteilung allerdings dürften sie richtig sein.

Ich habe auch keine Ahnung was du da klickst. Vermutlich ist für die beiden einfach der Klick nicht durchgekommen.
In einer Liste musst du schon onItemClickListener überschreiben, um auf einen Tab zu reagieren.
Oder halt onItemLongClickListener, wobei das nur für Kontextmenüs, Debugging oder Ähnliches sinnvoll ist.

Sprich: wenn du jetzt nicht lang genug den Finger drauf hältst passiert gar nüschte. Vermutlich gibt es deshalb auch keine Ausgabe.

Wie dem auch sei. Ich verstehe weder, worauf du hinaus willst noch, inwieweit dir dein 'Debugging' hier helfen können sollte.
Und zum Schluss: Woher willst du wissen, dass deine Sortierung aus der Datenbank korrekt ist? Du gibst keinen Sortierschlüssel in der Abfrage an.

Wenn du jetzt weiter kommst ist das prima.
Viel Erfolg weiterhin! =)

Ach sooo. Daran liegt das.

Tja, ein Timer startet halt auch einen Hintergrundthread. Der darf nicht einfach so an den Buttons rummalen.

Timer timer = new Timer();
	
final int[] indices = zahlen;
final Handler uiHandler = new Handler();
timer.scheduleAtFixedRate(new TimerTask() 
{
  private int i=0;
  public void run() 
  {
    uiHandler.post(new Runnable() 
    {
      public void run() 
      {
        buttons_ausgeben(indices[i++]);
      }
    });
  }
}, 0, 2000);

Irgendwie so halt.
Also musst du das Anpassen der Buttons auf dem UI Thread machen und sonst nirgends.

Lasst es mich so formulieren:
[Blockierte Grafik: https://i.chzbgr.com/maxW500/6379234560/h94F52467/]

Zitat von tomkicker

Folgender Timer müsste mir doch die Methoden buttons_ausgeben(zahlen[0]), buttons_ausgeben(zahlen[1]), usw im Abstand von 2 Sekunden aufrufen oder?

Keine Ahnung.
Eigentlich nicht. Ich zumindest würde nicht davon ausgehen, dass immer dieselbe Instanz von TimerTask gefeuert wird.
i als private static int zu definieren scheint mir sinnvoller – allerdings kann ich mich natürlich auch irren.

Zitat von tomkicker

Allerdings bricht meine App nach dem ersten Aufruf ab... -.-

Da wäre wichtig zu wissen mit welcher Meldung sie abbricht.
Vermutlich ein Scope Problem. Du willst auf zahlen zugreifen, doch da du dich ja in einer neuen (anonymen inneren) Klasse befindest, wird es zahlen nicht geben.

Hier solltest du auf jeden Fall eine finale Variable erstellen, damit du darauf zugreifen kannst. Oder dir eine eigene Subklasse von TimerTask erstellen, der du dann das Array übergeben kannst.

Mal Code für Möglichkeit 1:

Timer timer = new Timer();
	
final int[] indices = zahlen;
timer.scheduleAtFixedRate(new TimerTask() 
{
  private int i=0;
  public void run() 
  {
    buttons_ausgeben(indices[i++]);
  }
}, 0, 2000);

Probier's aus, könnte auch klappen.

Die Idee mit dem AsyncTask finde ich tatsächlich gut.
Allerdings brauchst du da nicht einen AsyncTask für jeden, sondern einer für alle sollte reichen.
Je nachdem, wie man es implementiert...

Den AsyncTask selbst brauchst du nur, um zu warten. Idealerweise um den Sound abzuspielen und so lange nichts zu tun, bis der Sound fertig ist.
In der onPreExecute zeigst du den Button, in der onPostExecute versteckst du ihn wieder.

Und je nach Runde hast rufst du den Task halt einmal, zweimal oder 75 mal hintereinander auf.
Dann musst du dem Task nur noch mitteilen, welchen Button er vermurksen soll und gut ist.

Zumindest fällt mir das spontan ein.

Das klingt jetzt aber nach einem sehr konstruierten Fall ohne wirklich sinnvollen Hintergrund.

Was soll dir das bringen?
Zumal du einen gewaltigen Fehler machst: UI im Hintergrund manipulieren wollen.
Du darfst Interaktionen mit UI Elementen nur im MainThread oder UI Thread machen.
Was du dort tust ist Folgendes:

Du erstellst dir eine Referenz auf deinen UI Thread.
Du erstellst dir eine Runnable, die den Thread schlafen legt, nen Sound abspielt und den Thread noch mal schlafen legt.
Du startest dein Runnable verzögert auf dem UI Thread.

Dieses gesamte Konstrukt könntest du einfach einsparen und die Schleife direkt in der buttons_zeichnen() durchlaufen.
So hast du das Ganze zwar etwas verkompliziert, aber im Endeffekt nix daran geändert.

Für so etwas sind Threads vermutlich der falsche Weg.
Ein Thread sorgt dafür, dass irgendwas getan wird und dein UI nicht blockiert.
Du möchtest aber, dass dein UI blockiert.
Denn solange du die Farbe(n) deines Buttons aufleuchten lässt soll der User ja nicht herumpfuschen können.

Als erster Punkt solltest du auf jeden Fall zuerst die Buttons erstellen und anzeigen, bevor du irgend etwas Anderes tust.
Idealerweise speicherst du dir die Referenz dieser Buttons in einer List.
Im 'Random'-Bereich lässt du dir dann einfach den Button an der Position der Random-Variable ausgeben, färbst ihn ein, wartest ein bisschen, färbst ihn zurück.
(Hast du noch eine weitere Liste mit Integern kannst du dort deine Random-Variable reinpacken. Dann siehst du später auch, ob richtig geraten wurde.)

Allerdings finde ich, dass Threading da ein völlig unsinniger Ansatz ist. Du brauchst es schlicht nicht und andererseits hindert es dich offenbar auch.

Ich sehe keine Ausgaben für die IDs 2 und 8...
Insgesamt sieht da nix durcheinander aus.