Beiträge von Thrakbad

    Ich hab mal etwas rum probiert. Layout in main.xml:


    Und die Activity dazu


    Da gibts jetz noch das Problem, dass der Content der Tabs über die Tabs unten raus geschrieben wird, wenn der Inhalt zu groß wird. Aber das sollte man mit ein bisschen rum spielen an dem RelativeLayout für den gesamten TabHost und dem FrameLayout für den Inhalt fixen können.


    EDIT: im Layout Editor muss man den Target auf 3.0 setzen, damit er das richtig anzeigt. Es läuft aber dann auch richtig auf der normalen Target-Version.

    Ich würde das in ne SQLite Datenbank speichern und eine Option zum Export als XML anbieten.
    Vorteile:
    - schnellerer Zugriff als XML
    - man muss nicht Alles im RAM vorhalten
    - man kann bei Updates, die die Datenbank verändern, ganz leicht bestehende Daten portieren. Bei XML kriegt man da keine Hilfe vom Framework


    Klasse, die du dir anschaun solltest: SQLiteOpenHelper

    Na das is ja nicht automatisch, sondern manuell ;-)...irgendwie hab ich das mal hingekriegt, aber da musste ich stark mit kämpfen. Hab ich mehrere Stunden an den Layout-Parametern rum getrickst, weil grade bei nem TableLayout is das scheinbar echt tricky. Wenn ich wieder auf der Arbeit bin, schau ich mal nach.

    I haven't tried this yet, but if it works like all the other default Android views, you can simply call webview.onPause(), I have never used the way over method.invoke()

    I'd say it depends on what you do in your onPause() method of the activity containing the webview. You should call webview.onPause() there and basically it should work like that.

    also 128MB braucht mein Galaxy Tab schon nach dem Reboot. Würde stark anzweifeln, dass mit Upgrade die Speicherausnutzung sinkt.
    Er verliert dabei auf jeden Fall die Garantie und kann evtl. sein Gerät damit völlig unbrauchbar machen.

    Da es global definiert ist, wird findViewById aufgerufen, bevor du dein Layout gesetzt hast. Globale Variablen werden initialisiert, bevor der Konstruktor durchgelaufen ist. Logischerweise geht das dann schief. Setz es oben auf null und ruf dann findViewById in der on Create Methode auf.

    Wenn du mit dem SQLiteOpenHelper arbeitest, musst du auch drauf achten, deine App jedes mal, nachdem sich deine Datenbank geändert hat, vorm nächsten Test komplett zu deinstallieren. Sonst legt er die Datenbank nicht neu an und du arbeitest mit den neuen Queries auf der alten Struktur, was natürlich schief geht.

    Geh mal im Eclipse in die Perspective DDMS (die is automatisch da, wenn du adt installiert hast) oder alternativ, geh in den Ordner, wo deine android sdk installiert is und starte \tools\ddms.bat. In beiden Fällen haste links oben ne auswahl von angeschlossenen Geräten und unten nen Logger, der ne Menge Meldungen raus spuckt. Wenn nen Force Close auftritt, dann steht da der Stacktrace in rot drin. Ist im Prinzip ne auflistung von Java-Funktionen, die zu dem Absturz geführt ham.

    Könnte nen Fehler im SQL Statement sein, das kann man ohne Stacktrace ned so genau sagen. In Zukunft brauchste übrigens diese Fehlermeldung nicht als Bild anhängen, da kannste einfach sagen du kriegst nen "Force Close" oder "FC" und jeder weiß, was gemeint is. Das passiert immer, wenn eine Exception durchgeworfen wird und keiner sie auffängt.

    Also es ist möglich, die Bildschirmauflösung abzufragen und die Bilder so manuell anzupassen. Mit den Resource-Qualifiers (z.B. drawable-hdpi) wird das wohl nix, weil die nicht so genau zwischen den Geräten unterscheiden, wie du es hier brauchst.