Beiträge von UweApps

    Hi Phil, schau doch noch mal nach...


    bei mir kommt so was nicht - da kommt nur eine Abblendung am unteren Ende aber es bounced nicht wirklich...


    Gruß
    Uwe

    Die Fehlermeldung deutet auf Zeile 28 - das wäre, wenn dein Code die richtigen Zeilennummern zeigt, das Objekt "test".


    Hast du in der letzten Zeit an den IDs in deinen Layouts was verändert/ergänzt?


    Bitte einmal zur Sicherheit die Manifest-Datei speichern (ein Leerzeichen zufügen, damit auch bestimmt gespeichert wird) und nochmal probieren.

    Hallo Marco,


    kannst du mal gucken, was bei dem Laufzeitfehler genau rauskommt?


    Mich interessieren die Fehlermeldungen - bitte erst einmal den LogCat löschen und dann die App neu starten, dann ist nicht so viel altes Zeug dabei.


    Du kannst die Einträge im LogCat markieren und dann mit dem Disketten-Symbol exportieren. ;)

    Leider ist das Speichern der Preferences nur über diesen @{%@&-Editor möglich. Und den Editor bekommst du über den Umweg mit dem getSharedPreferences(NAME, MODE).


    Von den SharedPreferences kannst du mehrere haben, die jeweils einen NAME bekommen (sie werden als Dateien gespeichert - wenn noch nix da ist, wird neu angelegt).


    Außerdem können die Preferences auch wirklich geshared werden, dazu gibt's den MODE (0 = MODE_PRIVATE, MODE_WORLD_READABLE, MODE_WORLD_WRITEABLE, MODE_MULTI_PROCESS)


    Das Beispiel zeigt nur einen Eintrag mit putInt(...), es gibt aber für den Editor eine ganze Menge an put-Methoden.


    Der Editor hat aber auch den Vorteil, dass du erst mal alle Einstellungen eintragen kannst und am Ende wird alles auf einmal gespeichert.


    Wenn dir zwischendurch das Handy wegen Saftmangel ausfällt, ist der alte Zustand der Prefs auf jeden Fall erhalten (und damit hoffentlich konsistent).

    nein, es wird von den get-Methoden der Preferences immer der Wert zurückgegeben, der vorher (hoffentlich) gespeichert war.


    Das kann auch (wenn man das vorher einträgt) durchaus eine -1 sein. Hängt halt von deinem Anwendungsfall ab. Die get-Methoden müssen ein Ergebnis liefern, zur Kennzeichnung, dass kein Eintrag vorhanden war, gibt's halt einen Notfall-Parameter...


    Die -1 gebe ich mit, weil ich in meiner Anwendung (im Beispiel waren es Bildschirm-Koordinaten) diese Zahl garantiert ungülitig ist und ich dann weiß, dass ich erst mal meine Daten einrichten sollte.


    Wenn deine Anwendung aber alle int-Zahlen (spez. um den 0-Punkt) braucht, dann kannst du auch Integer.MIN_VALUE nehmen - es ist kaum anzunehmen, dass du den Wert -2147483648 in deiner Anwendung brauchst... O:-)

    Oh - da hatte ich einen Fehler im anderen Beitrag drin - hab ihn gerade korrigiert.


    Es geht natürlich hier um int und nicht um boolean... :-[


    Java
    int myPostionX = settings.getInt("positionX", -1);


    Du kannst unterschiedliche Datentypen in die settings eintragen, es geht sogar derselbe Name, wenn sich der Datentyp unterscheidet...


    Bei getInt muss eine Variable mitgegeben werden, um ein Kennzeichen zu haben, dass die Variable nicht vorhanden war (bei String etc. kommt null).

    Du suchst die SharedPreferences...


    Für eine eindeutige ID gibt es zwar TelephonyManager#getDeviceId() aber das braucht Rechte, die man nicht wirklich braucht und eventuell Benutzer abschreckt.


    Aber wenn du eine eindeutige ID brauchst, dann frag ich mal zurück, wo du sie brauchst. Wenn du z.B. eine High-Score-Liste auf einem Server speichern willst, dann kannst du doch vom Server beim ersten Zugriff (myID=-1) eine ID zurückgeben und dann hat deine App eine eindeutige ID für die nächsten Zugriffe (gespeichert in den SharedPreferences)...

    Du kannst deine SeekBar gerne in ein eigenes LinearLayout (o.ä.) für das weight einpacken, dann kannst du besser mit den Breiten/Höhen spielen und die Elemente darunter werden nicht abgedeckt. Außerdem kannst du dann noch etwas daneben packen...


    Die LayoutParams mag ich auch nicht so gerne, ich packe die Einstellungen lieber in die XML-Layouts rein oder mach mir einen Style dafür (wenn öfter vorkommt).

    Hast du viele Projekte im Workspace offen? Dann solltest du besser mal einige schließen, denn beim Speichern schaut sich Eclipse auch noch mal überall um, ob es vielleicht noch ein paar Error-Marken setzen könnte. Und dabei könnten sich die vielen laufenden Compiler mal gegenseitig im Weg stehen...


    Ansonsten probiere es doch mal mit einer separaten Eclipse-Installation - dann kannst du dir auch die neueste Version dafür gönnen...

    Das wundert mich, dass der layout_weight-Parameter stört - vielleicht solltest du den besser dem umgebenden Element verpassen und hier für die Höhe einfach FILL_PARENT nutzen...


    Anderer Vorschlag: du hast in deinem ersten Quelltext die Breite nachträglich gesetzt - du kannst das doch auch gleich beim new mitmachen:


    Java
    LayoutParams seekbarlayout = new LayoutParams(LayoutParams.WRAP_CONTENT, LayoutParams.WRAP_CONTENT, 1.0f);


    Info für die Java-Neulinge: (float) 1.0 == 1.0f

    Hast du dein Eclipse von Ubuntu? Dann könnte es sein, dass bei der Installation der ganzen Erweiterungen vielleicht irgendwelche Teile in Verzeichnissen mit eingeschränkten Zugriffsrechten gelandet sind. Schau dich auch mal in deinem workspace-Verzeichnis nach anderen Besitzern und Zurgriffsrechten um - und schau dir auch die versteckten Verzeichnisse an...


    Ich hab mein Eclipse im normalen User-Verzeichnis installiert (runterladen, entpacken, dort "eclipse" starten, Android draufspielen) und nicht die Eclipse-Version von Ubuntu benutzt.


    Aber ich habe ein ähnliches Problem und auch eine Lösung, die hier als Ergänzung gut hinpasst:
    Bei meinem Eclipse unter Ubuntu 11.10 muss ich beim Starten der AVD drauf achten, dass der LogCat sichtbar ist - ansonsten scheint Eclipse sich an den Logs zu verschlucken und hängt sich komplett auf und muss abgeschossen werden.

    Du solltest dir bei den Events vielleicht merken, was vorher passiert war (lastEvent) oder wie der aktuelle Zustand ist.


    Du kannst zusätzlich auch MotionEvent.ACTION_MOVE auswerten und in dem Fall die Markierung entfernen und die (nachfolgende) ACTION_UP ausfallen lassen.


    Du kannst aber auch z.B. mit v.getTop() den oberen Abstand zum Parent bestimmen (wenn der parent scrollt) und bei Änderung des Wertes entsprechend reagieren...

    Die XML-Drawables sind eigentlich nur Grafik-Befehle, die in XML verpackt werden: Linien, Kästen, Farbverläufe - aber insgesamt doch sehr leistungsfähig.


    Einfache grafische Sachen kann man gut damit machen, Button, EditText etc. nutzen so was mit State Lists kombiniert, um die unterschiedlichen Zustände (Focus) darzustellen.

    Genaue Pixel-Angaben sind zwar immer sehr verlockend, aber wenn man nicht nur für sich selber programmiert, dann sollte man die schnell wieder vergessen (siehe Dimensions).


    Wenn du mehrere Elemente gleichmäßig verteilen willst, dann ist layout_weight der Parameter, den du suchst - wahrscheinlich in Kombination mit layout_width="wrap_content".


    Ich bin nicht sicher, ob das Padding im Button Einfluss auf den Umbruch hat - das Padding ist nämlich eigentlich innerhalb der layout_widht/height. Und ein Button ist auch nur ein TextView mit einem Drawable als Hintergrund, also kein besonders kompliziertes Element.


    Aber Pixel ist eine Einstellung, von der (aus hier offensichtlichen Gründen) in der Android-Doku abgeraten wird. ;)

    Hallo Kogoro,


    wo wir schon mal dabei sind - kannst du mal den Link in deiner Signatur prüfen? :* - NACHTRAG: stimmt, jetzt ist der Tutorial-Link raus.


    Ich wollte da gerade mal neugierig reinschauen und da gibt's nichts... - NACHTRAG: ok - dann konzentrieren wir uns hier mal auf die Tutorials.


    LG Uwe