Beiträge von UweApps

    nein - andersrum... ;)


    Den StringBuffer nimmst du, um die ch[] aufzusammeln - du musst ihn also außerhalb deklarieren.


    Hier mal ein Ausschnitt aus meinem Handler:

    Naja - es gibt (zumindest in anderen Sprachen) statische Klassen, auch wenn das bei Java in der Definition der Hauptklasse nicht eingetragen wird.


    Das typische Beispiel ist Math - du wirst wohl kaum ein Mathematik-Objekt bauen wollen / können, sondern immer die Funktionen direkt mit Math.func() aufrufen.


    Aber das nur so am Rande. *liebguck*

    oh - da hast du ein Problem von Java, das ich dir im Detail gerne aufschlüsseln kann, ist aber nicht so einfach. Ich versuche es mal...


    Wenn du eine eigene Klassendatei anlegst mit dem Namen Tab und dort den Code reinpackst, dann geht es auch ohne static in der class Definition.
    Das macht auch Sinn, denn dann kannst du deiner Klasse Tab auch noch weitere Variablen und Funktionen dazu packen und Objekte davon bauen.
    Die static-Variable ist dann eine sog. Klassenvariable und nur einmal vorhanden (die ganzen KONSTANTEN in Android sind solche).


    Wenn Tab aber eine Klasse in einer anderen Klasse ist, dann muss static auch in der Klassendefinition stehen.
    Warum?
    static bedeutet, dass deine Variable IfaTab immer verfügbar ist, egal ob von der Klasse ein Objekt existiert oder nicht.
    Das geht bei inneren Klassen aber nur, wenn die innere Klasse selber auch immer vorhanden (static) ist.


    Dies ist eines der dunklen Kapitel der Speicherverwaltung, die leider mehr nach der technischen Umsetzung und nicht so sehr nach dem normalen Userverständnis funktionieren.

    Das geht auf jeden Fall besser mit einem StringBuffer.


    Die wichtigen Methoden sind myStringBuffer.append(chars), myStringBuffer.toString() und myStringBuffer = new StringBuffer() (dann ist er wieder leer).


    Achja - characters() wird auch für RETURN, LEERZEICHEN, TAB und sonstiges, was zwischen den Tags ist, aber keine Bedeutung hat, aufgerufen.
    Du musst also gucken, ob dein Ergebnis nach toString() überhaupt brauchbare Zeichen enthält.
    Dem Parser ist das egal - könnte ja sein, dass du das gebrauchst, darum liefert er dir alles...

    Das ist Standardverhalten von XML-Parsern, im Extremfall kann ein characters-Element ja auch mal einige Megabyte enthalten, darum wird öfters zwischendurch neu angesetzt.


    Du musst immer damit rechnen, dass characters() kleine Abschnitte bastelt (z.B. bei Sonderzeichen).


    Einfach deinen StringBuffer oder ähnliches weiter auffüllen und bei einem Tag-Ende übernehmen und leeren.

    Hallo Patrick,


    vielen Dank dafür - ich hab gleich die Gelegenheit genutzt und dieses Thema als erledigt markiert - sehr schön!!!


    Und dabei hab ich bemerkt, dass das Thema wieder auf "unerledigt" geht, wenn man noch einen Beitrag dazu schreibt.
    Muss man halt dran denken, die "erledigt"-Markierung wieder zu setzen...


    Viele Grüße
    Uwe

    Die Downloads können ja u.U. weiterlaufen, aber du solltest dann nicht mehr auf View-Elemente zugreifen.


    Wenn du den Download in einen Service ausgelagert hast, bist du unabhängig von der Laufzeit deiner Activity - aber dann solltest du unbedingt gucken, ob der View vielleicht null ist.


    Eine andere Möglichkeit wäre, im onPause dem Download Bescheid zu sagen, dass er nach dem Laden NICHT auf den View zugreifen soll - dann sind die Daten da und können in onResume dann angezeigt werden.


    Damit würdest du dem geschilderten Benutzerverhalten entgegenkommen: "hmm - lädt noch - mal kurz was anderes gucken, dann ist es bestimmt da".

    Kommt drauf an - nicht umsonst liefert Android alle möglichen Parameter, je nach Anwendung braucht mal diese und mal jene.


    Beispiel: ein hochauflösendes Smartphone-Display (die Konkurrenz arbeitet mit 326 ppi auf 3,5 Zoll und hat 960 × 640 Pixel) hat mehr Pixel als ein billiges Tablet mit DIN-A-4-Fläche. Wenn du schöne Bilder hast, dann lohnt sich die reale Pixel-Auflösung.


    Aber versuch mal, Schrift in der Größe zu lesen - wenn es also auf Details ankommt, dann musst du in so einem Fall alles doppelt so groß machen, damit man was sehen kann...


    Es ist deine Entscheidung und hängt ganz von deinem Anwendungsfall ab.


    Aber denke auch an ältere Leute wie mich, die beim Lesen kleiner Schriften Probleme haben. :*

    Hallo Androiden,


    in der letzten Zeit ist das Forum ja sehr belebt und viele Fragen und gute Lösungen tauchen auf. Nur manchmal verliere ich den Überblick wo ein Problem noch offen ist..


    Dazu hab ich einen Vorschlag: wenn ihr meint, dass ein Problem gelöst ist, dann könnt ihr am Ende des Theads (ganz unten rechts) ein paar Sternchen vergeben, je nachdem, wie wichtig und gut die Lösung ist.


    Und wenn jemand Langeweile hat, kann er/sie auch gerne mal ein altes Problem lösen - besonders wenn die Zugriffszahl auf einem Beitrag sehr hoch ist, was auf großes Interesse schließen läßt.


    Die Diskussion ist eröffnet!


    Viele Grüße
    Uwe

    In der Android-Doku wird folgendes zu den Mindestgrößen der verschiedenen vorgefertigten Bildschirmgrößen genannt:

    • xlarge screens are at least 960dp x 720dp
    • large screens are at least 640dp x 480dp
    • normal screens are at least 470dp x 320dp
    • small screens are at least 426dp x 320dp


    Du braucht wahrscheinlich die Angaben, die dir DisplayMetrics liefert, oder??


    Mit den Parametern und ein bisschen rumrechnen hast du dann die Bedingungen für dein if und kannst deine Activities starten.

    Was ist die Grenze zwischen Tablet und Handy? Die Frage ist wohl eher, wo DU deine Grenze setzt.


    Ich denke mal, wenn in X- oder in Y-Richtung mindestens 700 Pixel sind, dann hast du wahrscheinlich ein Tablet.
    Aber dann rechne auch damit, dass es hochauflösende Displays bei Handys geben kann, dann sind die DPI auch wichtig für die Auswertung.


    Vielleicht entscheidest du dich auch für mehr als zwei Varianten - hängt von deiner Anwendung ab.

    ListView ist für Anfänger nicht wirklich einfach - nach vielen Fragen im Forum hab ich nun mal ein Tutorial dazu gemacht. Ich gehe dabei auch auf einige andere Punkte ein, die bei Anfängern gerne mal Probleme bereiten.


    Zunächst mal die grobe Übersicht:
    ListView ist ein vertikal scrollendes Widget, das von einem Adapter die Listeneinträge aufbauen läßt und diese dann anzeigt. Dabei werden nur so viele Einträge erzeugt, bis der Bildschirm voll ist (und noch ein bisschen weiter).
    Wenn der Benutzer dann scrollt, werden vom ListView die benötigten Einträge vom Adapter nachgeladen (das habt ihr bestimmt schon bei einigen Apps bemerkt).


    Es gibt zwar einige spezialisierte Adapter (z.B. ArrayAdapter, CursorAdapter), aber ich nutze hier den BaseAdapter, da sieht man besser, was intern passiert.


    Die Daten verpacke ich in eine Klasse Datensatz, mehrere Datensätze kommen in eine ArrayList<Datensatz>. Diese ArrayList nutzt dann der BaseAdapter mit einem Layout und erzeugt die List-Einträge.


    Nun geht's los:


    Zunächst brauchen wir eine Datenstruktur für die Informationen, die in einem Listeneintrag eingebaut werden ("Datensatz").

    Java
    private class Datensatz {
    	public String name;  // besser setter und getter-Methoden schreiben, stört hier aber...
    	public String datum; // die Umwandlung von Datum lasse ich weg - das ist ein anderes (großes) Problem
    	public Datensatz(String name, String datum) {
    		this.name = name;
    		this.datum = datum;
    	}
    }


    Die Datensätze kommen in eine ArrayList, diese benutzt dann der Adapter, um die einzelnen Views zu erzeugen. Die Variable datensaetze gilt für die ganze Activity:


    Damit ein Datensatz in der Liste als View-Element eingebaut werden kann, brauchst du ein Layout. Ich hab hier mal ein Beispiel mit ein paar nützlichen Formatierungen (speichern in Projekt/res/layout/mylistitemlayout.xml):


    Nun kommt der Adapter, der dem ListView die einzelnen ListItems auf Anfrage liefert. Der Adapter muss auch ein getCount liefern, damit ListView weiß, wann Schluss ist. Außerdem braucht man meistens auch einen OnItemClickListener (dann dürfen die Items aber selber keine OnClickListener implementieren!). Meine Activity heißt übrigens MyListActivity - musst du wahrscheinlich anpassen.


    Jetzt brauchen wir noch ein Layout für die MyListActivity:


    So, nun der krönende Abschluss in MyListActivity: Layout laden, Daten aufbauen, ListView mit dem Adapter verbinden:


    Jetzt hab ich hoffentlich alles zusammen - leider muss man sich das aus verschiedenen Quellen zusammen sammeln und Anfänger haben da manchmal zu viele lose Enden in der Hand. Aber hiermit solltest du klar kommen - Erweiterungsmöglichkeiten sind vor allem in Datensatz und bindView sinnvoll, je nach Quelle der Daten ist initDatensaetze auch einfach anzupassen.


    Fehler und Verbesserungen sind willkommen. :D

    ok - weil ihr so lieb fragt, hier mal als Beispiel ein Listener, den ich für mehrere Spinner-Felder verwenden möchte.


    Mein Projekt enthält auch die Klassen Feld (Parameter z.B. für ein Spinner mit Beschriftung, Feldname und Optionen als ArrayList) und Datensatz (enthält die Daten des Formulars und eine get-Methode).



    Aufgerufen wird das Ding folgendermaßen:

    Java
    mySpinner.setOnItemSelectedListener(new SelectOnItemSelectedListener(myFeld, myDatensatz));


    Für das OnCreateOptionsMenu musst du dann mal selber gucken, was die Doku hergibt und was du selber anpassen möchtest.