Im Falle von Android-Programmierung ist es auf jeden Fall vorteilhaft Eclipse zu nutzen. Dafür gibt es nämlich extra ein Android-Plugin, was einem viele Vorteile bietet und so einiges vereinfacht.
Siehe dazu die Android-Dokumentation, die ist, was dieses Thema angeht, sehr ausführlich.
Hmmm,
versuch mal anstatt
meinEditText.getLayoutParams().width = textfeldbreite;eher folgendes:
LayoutParams params = meinEditText.getLayoutParams();
params.width = textfeldbreite;
meinEditText.setLayoutParams(params);Ich könnte darauf wetten, dass die Funktion setLayoutParams(..) sich um alles nötige kümmert. Möglicherweise ist das invalidate() dann überhaupt nicht mehr nötig.
Keine Ahnung, ob ich dein Problem überhaupt richtig verstehe.
Aber fehlt da nicht einfach ein "import deinPaketName.R;" ?
Ok, update:
Mittels Bitmap.createScaledBitmap(..) habe ich mir zuerst ein skaliertes Drawable erstellt und das dann als Hintergrund verwendet. Das Ergebnis war sehr enttäuschend, denn selbst mit Breite und Länge auf 10 Pixel gesetzt (das Bild war schon garnicht mehr zu erkennen), war das Scrollen immer noch sehr träge.
Allerdings habe ich nun eine Lösung gefunden. Ich verzichte komplett auf setBackgroundDrawable. Stattdessen habe ich dem Layout meiner ListView (im obigen Beispiel nicht vorhanden) als rootelement einen FrameLayout hinzugefügt und als childs eben die ListView sowie eine ImageView, die beide mittels match_parent den gesamten Raum einnehmen.
Dann noch die ListView mittels setCacheColorHint(0) transparent gestaltet und mittels imageView.setDrawingCacheEnabled(true) das Cachen des Images eingeschaltet.
Nun klappt es wunderbar, wobei man sich natürlich fragt, wieso setBackground kein solches Caching ermöglicht!?
Hi,
erstmal danke für deine Antwort!
Erste Vorschlag wäre, den Hintergrund auf die List-Elemente zu verteilen...
Hmm, ich wüsste nicht, wie das gehen soll!? Ich müsste das Bild ja dann in entsprechende Teile aufteilen und jedem List-Element einen dieser Teile zuordnen. Beim scrollen ergäbe sich dann jedoch das Problem, dass die Anordnung komplett geändert werden müsste, sobald ein Item den sichtbaren Bereich verlässt und ein neues diesen erreicht. Das klingt irgendwie nach erheblichem Aufwand. Oder habe ich dich falsch verstanden?
Es stellt sich also die Frage, wie aufwändig deine Drawables sind und ob du dem System durch irgendwelche Anpassungen am Layout unter die Arme greifen kannst.
Die Drawables selber werden in meiner Anwendung vom Benutzer ausgewählt, ich habe also keinen Einfluss auf diese. Eine programmiertechnische Anpassung der Drawables im Vorraus, also bevor sie als Hintergrund gesetzt werden, wäre allerdings eine Option. Nur wie mache ich das? Also wie erstelle ich aus einem Drawable (sagen wir 1 MB png file mit Auflösung 1000x1000) ein anderes Drawable mit besseren Eigenschaften (z.B. 100KB mit Auflösung 200x200). Werde das mal versuchen herauszufinden.
Welche Anpassungen am Layout meinst du? Habe mal eine eigene Klasse, die Drawable implementiert, gebastelt und die Aufrufe von draw(Canvas) gezählt. Es scheint in der Tat so zu sein, dass genau hier der Flaschenhals liegt. Allerdings kam ich mit ein wenig Rumspielerei schnell zu dem Schluss, dass es keinen Sinn macht die Anzahl der Aufrufe von draw(Canvas) in irgendeiner Weise zu beeinflussen. Schon als ich einfach jeden zweiten Aufruf wegließ, war die optische Ausgabe quasi ruiniert (flackern). Und die Performance war zwar etwas besser, aber immernoch total unzufriedenstellend.
Hi,
ich denke hier liegt das Problem:
meinEditText.invalidate();Soweit ich weiß, kann nur der Haupt-Thread ein invalidate aufrufen. Somit kannst du das in deinem onSeekBarChangeListener nicht machen.
Eine mögliche Lösung könnte irgendwie so aussehen, dass du einen Handler erstellst, der das textfeld invalidatetd. Du musst dann nur noch den Handler informieren
Frei aus dem Kopf in etwa:
final EditText meinEditText = ...;
final Handler handler = new Handler(new Handler.Callback() {
public boolean handleMessage(Message msg) {
if (msg.what == 1234) meinEditText.invalidate();
}
});Und dann in deinem OnSeekBarChangeListener():
handler.sendEmptyMessage(1234);1234 am besten natürlich durch eine definierte Konstante ersetzen, bzw. wenn der Handler auch zukünftig garnichts anderes machen soll, kannst du die Abfrage natürlich ganz weglassen.
Gruß
Edit: Paar mal editiert, beim nächsten mal denk ich erst nach, bevor ich auf Absenden drücke 
Hi,
ich suche nun schon eine gefühlte Ewigkeit, kann aber keine Antwort finden.
Ich setze mit setBackgroundDrawable(Drawable) ein Bild als Hintergrund meiner ListView. Im Prinzip klappt das ganze auch, aber die ListView wird dadurch irgendwie extrem lahm. Soll heißen: Das Scrollen läuft einfach nicht mehr flüssig.
Habe das ganze mal in einem einfachen Beispiel zusammengefasst, wo das Problem auftritt:
package chiro.test;
import android.app.Activity;
import android.graphics.drawable.Drawable;
import android.os.Bundle;
import android.view.View;
import android.widget.AdapterView;
import android.widget.AdapterView.OnItemClickListener;
import android.widget.ArrayAdapter;
import android.widget.ListView;
public class ListViewBackgroundActivity extends Activity {
/** Called when the activity is first created. */
@Override
public void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
final ListView listView = new ListView(this);
final Drawable drawable = getResources().getDrawable(R.drawable.sample);
setContentView(listView);
String[] strings = new String[100];
for (int i = 0; i < strings.length; i++) strings[i] = Integer.toString(i);
listView.setAdapter(new ArrayAdapter<String>(this, android.R.layout.simple_list_item_1, strings));
listView.setBackgroundDrawable(drawable);
listView.setCacheColorHint(0);
listView.setOnItemClickListener(new OnItemClickListener() {
public void onItemClick(AdapterView<?> arg0, View arg1, int arg2,
long arg3) {
if (listView.getBackground() == null) listView.setBackgroundDrawable(drawable);
else listView.setBackgroundDrawable(null);
}
});
}
}Das Verhalten ist eindeutig. Bei geladenem Hintergrund-Bild scrollt die ListView überhaupt nicht flüssig. Entferne ich den Hintergrund (im Beispiel-Code einfach durch Clicken auf die ListView), funktioniert scrollen wieder einwandfrei und total flüssig.
Aber woran liegt das? Wird das Drawable evtl. wiederholt gezeichnet, obwohl es sich eigentlich nicht verändert? Und wird es dabei vielleicht immer erst skaliert?
Habe auch mal ein ScaleDrawable Objekt genommen, half aber auch nicht.
Hoffe jemand kann helfen.
Danke schonmal!
Ob das jetzt im Zusammenhang mit Android irgendwelche Nachteile hat, weiß ich nicht. Ich denke, es sollte durchaus möglich sein.
Allerdings widerspricht diese Vorgehensweise sicherlich dem Prinzip der hohen Kohäsion. Jedes Modul sollte möglichst genau eine Funktionalität haben, das erhöht einfach die "Qualität" des Codes.
Soll heißen: Schreibst du eine große Activity, die je nachdem, welches Layout gerade geladen ist, eine unterschiedliche Funktionalität besitzt, dann ist deine Activity sehr bald schlecht lesbar, schlecht wartbar und dadurch schließlich fehleranfällig. Ein Fehler ist dann auch einfach viel schwerer zu lokalisieren.
Mag sein, dass es In gewissen Situationen, durchaus einen Sinn haben kann, so vorzugehen.
Also durch den genannten Thread bin ich auf folgende Funktion gestoßen: Environment.getExternalStorageDirectory(). Diese liefert mir ein File-Objekt auf /mnt/sdcard, was zumindest schon mal ein Anfang ist, aber mir halt nicht reicht
CodeString path = "/mnt/sdcard" + i;
HWarum hängst du hinter sdcard noch eine Zahl?
Mfg Titus
Vielleicht hatte ich mich nicht klar genug ausgedrückt. Ich habe zwei Geräte.
Mein Handy enthält den einen Ordner /mnt/sdcard, womit ich auf die Speicherkarte zugreifen kann.
Mein Tablet enthält zwei Ordner, nämlich /mnt/sdcard (interner Speicher von 16GB) und den Ordner /mnt/sdcard2 (externe Speicherkarte).
Daher hänge ich hier noch die Zahl an, gestartet bei 2, dann 3, usw. um herauszufinden, wieviele Speicher es gibt. (/mnt/sdcard prüfe ich extra)
Hallo,
ich möchte gerne ermitteln, wie viele externe Speicher ein Gerät besitzt, sowie die zugehörigen Pfade. (also z.B. /mnt/sdcard, /mnt/sdcard2)
Momentan prüfe ich einfach, ob das entsprechende Verzeichnis vorhanden ist, ungefähr so (ausm Gedächtnis):
boolean loop = true;
int i = 2;
while (loop) {
String path = "/mnt/sdcard" + i;
File file = new File(path);
if (file.exists()) DANN TUE IRGENDWAS, z.B. in ne Liste schreiben, zähler erhöhen, ...
else loop = false;
i++;
}"/mnt/sdcard" muss ich natürlich noch extra überprüfen. (Blöd, dass es nicht /mnt/sdcard1 ist ;))
Im Prinzip funktioniert das Ganze auch so, wie es soll (zumindest auf meinen Geräten). Ich würde mir aber eine schönere Lösung wünschen.
So nun meine Fragen:
1. Ist der Pfad vom externen Speicher immer "/mnt/sdcardX"? Oder kann man sich darauf nicht verlassen?
2. Gibt es vielleicht eine Funktion, die mir direkt sagt, wie viele externe Speicher es gibt?
3. Gibt es vielleicht eine Funktion, die mir direkt die Pfade "/mnt/sdcard, /mnt/sdcard2, .." liefert?
Ansonsten bin ich natürlich für sämtliche Vorschläge offen.